Your enterprise organization manages multiple environments across staging and production folders in Google Cloud. To prevent data exfiltration and enforce infrastructure standards across all development teams, your DevOps team must implement a Policy-as-Code guardrail with the following requirements: Restrict creation and updates of cloud resources to enforce specific configuration attributes. Provide human-readable violation messages when unauthorized API calls are blocked. Ensure the guardrail definition is registered at the organization level and can be enforced or overridden hierarchically. How should you define and enforce this guardrail using Google Cloud Organization Policy custom constraints?

Define a custom constraint YAML file specifying `resourceTypes`, `methodTypes`, a CEL `condition`, and `actionType`. Register it using `gcloud org-policies set-custom-constraint`, then create a policy YAML referencing the constraint and apply it using `gcloud org-policies set-policy`.: ### What Custom Organization Policy Constraints Are **Custom organization policy constraints** allow organization administrators to define granular, programmatic guardrails based on specific resource attributes and fields. Unlike legacy managed constraints that have predefined, fixed behaviors, custom constraints use **Common Expression Language (CEL)** expressions to evaluate REST resource payloads during operations. ### How It Meets the Requirements - **Granular restriction**: The custom constraint YAML file defines the target REST resource type (under `resourceTypes`), supported operations such as `CREATE` or `UPDATE` (under `methodTypes`), a CEL expression (under `condition`), and an action (`ALLOW` or `DENY` under `actionType`). - **Actionable feedback**: The `description` and `displayName` fields within the constraint definition are returned as descriptive error messages when an API call is blocked by policy evaluation. - **Two-phase deployment model**: The workflow explicitly separates constraint registration from policy enforcement: 1. Register the custom constraint definition across the organization via `gcloud org-policies set-custom-constraint`. 2. Enforce the policy containing boolean enforcement rules on the desired resource hierarchy node (organization, folder, or project) via `gcloud org-policies set-policy`. ### Key Capabilities - **Fine-grained field evaluation**: Leverages CEL to inspect nested resource attributes before requests are committed. - **Hierarchical inheritance**: Custom policies automatically inherit down the resource hierarchy to all descendant folders and projects unless explicitly overridden. - **Safe testing and simulation**: Supports dry-run specifications and Policy Simulator integration prior to live enforcement. ### Why This Is Optimal This approach uses the native **Google Cloud Organization Policy Service**, providing preventive, control-plane enforcement directly at the Cloud Resource Manager layer without needing third-party admission controllers or post-deployment remediation loops.

Custom Organization Policy Constraint Definition Enforcement | Professional Cloud DevOps Engineer

Custom Organization Policy Constraint Definition Enforcement

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

Your enterprise organization manages multiple environments across staging and production folders in Google Cloud. To prevent data exfiltration and enforce infrastructure standards across all development teams, your DevOps team must implement a Policy-as-Code guardrail with the following requirements:

Restrict creation and updates of cloud resources to enforce specific configuration attributes.
Provide human-readable violation messages when unauthorized API calls are blocked.
Ensure the guardrail definition is registered at the organization level and can be enforced or overridden hierarchically.

How should you define and enforce this guardrail using Google Cloud Organization Policy custom constraints?

Create an IAM Deny Policy YAML defining CEL conditions and supported REST methods, then bind it to the target folders using gcloud iam deny-policies create.

Define an IAM Condition on project-level role bindings that evaluates resource.config CEL expressions, and enforce it using gcloud projects set-iam-policy.

Define a custom constraint YAML file specifying resourceTypes, methodTypes, a CEL condition, and actionType. Register it using gcloud org-policies set-custom-constraint, then create a policy YAML referencing the constraint and apply it using gcloud org-policies set-policy.

Configure a single Organization Policy YAML containing both the CEL constraint logic and project bindings, then deploy it directly using gcloud org-policies set-policy.

Professional Cloud DevOps Engineer

Custom Organization Policy Constraint Definition Enforcement

Related questions