Google ACE Practice Question: Your organization policy at the root level sets…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Create a separate GCP organization for the business unit and configure its own resource location policy.

  Why it's wrong here

  Creating a separate organization for one business unit is an extreme architectural change that would break centralized billing, IAM, and audit logging across the enterprise. Since organization policies are inherited hierarchically and can be overridden at the folder level with inheritFromParent:false, the same outcome—allowing europe-west1 only for that business unit—can be achieved without splitting the org. A separate org would also require a separate billing account and separate VPC shared networking, introducing operational overhead and governance blind spots.

• ✓

  Set a `gcp.resourceLocations` policy on the business unit's folder with `inheritFromParent: false`, allowing `us-central1`, `us-east1`, and `europe-west1`.

  Why this is correct

  Setting a folder-level policy with inheritFromParent:false replaces the inherited root policy entirely for that folder, so the business unit's projects can explicitly allow us-central1, us-east1, and europe-west1 without changing the restriction for other business units. This is the native org-policy mechanism for granting location exceptions, because the folder becomes the effective enforcement point for its descendants. The root policy remains in place as the default for all other resources, maintaining a secure baseline.

• ✗

  Add a `europe-west1` exception to the root org policy using the `exceptions` field.

  Why it's wrong here

  The gcp.resourceLocations constraint does not support an 'exceptions' field; organization policies are defined as a list of allowed values on a resource, not as a parent policy with carve-outs. To allow europe-west1 for a specific subtree, you must set a new policy on the business unit's folder with inheritFromParent:false and include the union of the root policy's regions plus europe-west1. Adding a field that doesn't exist would be invalid and would not affect enforcement.

• ✗

  Remove the `gcp.resourceLocations` org policy from the root and apply it to each business unit's folder individually.

  Why it's wrong here

  Removing the gcp.resourceLocations policy from the root org node eliminates the default restriction that applies to all current and future projects and folders; any resource created before a folder policy is applied would be unconstrained. You would then have to manually replicate the policy on every business unit folder and remember to apply it to each newly created folder, which is error-prone and difficult to audit. The robust pattern is to keep the restrictive root policy as a baseline and allow only carefully scoped folder-level overrides, so governance is never accidentally skipped.

Go deeper

Related to this question