A security engineer is designing an organization policy rollout across an enterprise Google Cloud resource hierarchy consisting of top-level folders for Production, Development, and Public-Facing Web. The rollout must satisfy two primary requirements: Public access prevention must be enforced across all Cloud Storage buckets across the entire organization by default, while allowing an exception for a single project inside the Public-Facing Web folder hosting a public static website. A newly authored custom organization policy constraint targeting resource updates must be enforced without causing service update deadlocks on existing non-compliant resources. Which strategy should the security engineer implement to achieve these requirements?

Enforce the storage.publicAccessPrevention constraint at the organization root, disable enforcement on the specific static website project, and use Policy Simulator to identify and remediate non-compliant resources before enforcing the custom update constraint.: ### What the Solution Is This strategy leverages **Google Cloud Organization Policy inheritance rules** alongside **pre-enforcement compliance validation** using Policy Simulator to deploy both managed and custom constraints safely at scale. ### How It Meets Requirement 1 (Hierarchy and Inheritance) - Enforcing the managed constraint `storage.publicAccessPrevention` at the **organization root** sets a universal security baseline that automatically inherits down through all folders and descendant projects. - Because organization policies allow descendant nodes to override inherited rules, administrators can explicitly set the constraint to **disabled** at the specific project hosting the public static website, granting the necessary exception without weakening protections elsewhere. ### How It Meets Requirement 2 (Custom Constraint Deadlock Prevention) - Organization policies do not apply retroactively to existing resources, but modifying an existing non-compliant resource can trigger validation errors. - If an existing environment violates multiple restricted fields simultaneously, an `UPDATE` operation attempting to fix one field will fail because another restricted field remains non-compliant, causing an **update deadlock**. - Evaluating existing workloads with **Policy Simulator** allows administrators to discover non-compliant configurations and remediate them *prior* to policy enforcement, avoiding operational deadlocks. ### Key Advantages - **Granular exception management:** Isolates public website risk to a single explicitly overridden project container. - **Inheritance by default:** Automatically secures any newly created folders or projects under the organization root. - **Zero operational disruption:** Prevents production update deadlocks on live resources during policy rollouts.

Org Policy Inheritance Custom Constraints | Professional Cloud Security Engineer

Org Policy Inheritance Custom Constraints

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.

A security engineer is designing an organization policy rollout across an enterprise Google Cloud resource hierarchy consisting of top-level folders for Production, Development, and Public-Facing Web. The rollout must satisfy two primary requirements:

Public access prevention must be enforced across all Cloud Storage buckets across the entire organization by default, while allowing an exception for a single project inside the Public-Facing Web folder hosting a public static website.
A newly authored custom organization policy constraint targeting resource updates must be enforced without causing service update deadlocks on existing non-compliant resources.

Which strategy should the security engineer implement to achieve these requirements?

Apply storage.publicAccessPrevention at the organization root, create an IAM Deny policy condition to exempt the website project, and disable the custom constraint permanently whenever deadlocks occur.

Apply storage.publicAccessPrevention at the Production and Development folder levels only, and restrict the custom constraint strictly to CREATE operations while omitting UPDATE operations.

Enforce the storage.publicAccessPrevention constraint at the organization root, disable enforcement on the specific static website project, and use Policy Simulator to identify and remediate non-compliant resources before enforcing the custom update constraint.

Enforce storage.publicAccessPrevention on each individual bucket metadata setting, and configure the custom constraint with an automatic retroactive remediation flag at the organization root.

Professional Cloud Security Engineer

Org Policy Inheritance Custom Constraints

Related questions