You are on the data governance team and are implementing security requirements to deploy resources. You need to ensure that resources are limited to only the europe-west3 region. You want to follow…

Question

Options

• ASet the constraints/gcp.resourceLocations organization policy constraint to in:europe-west3-locations.
• BDeploy resources with Terraform and implement a variable validation rule to ensure that the region is set to the europe-west3 region for all resources.
• CSet the constraints/gcp.resourceLocations organization policy constraint to in:eu-locations.
• DCreate a Cloud Function to monitor all resources created and automatically destroy the ones created outside the europe-west3 region.

• A
  77% (37)
• B
  6% (3)
• C
  13% (6)
• D
  4% (2)

Explanation

Option A is correct because constraints/gcp.resourceLocations is the Google-recommended Organization Policy constraint specifically designed to enforce where resources can be deployed, and in:europe-west3-locations targets exactly that single region - this is a preventative control enforced at the org/folder/project level before any resource is created.

Why the distractors are wrong:

• B (Terraform validation): This only controls deployments done through that specific Terraform configuration - someone deploying via Console, gcloud CLI, or another tool bypasses it entirely, making it an incomplete governance control.
• C (in:eu-locations): This uses a broader location group that includes all EU regions, not just europe-west3 - it would allow resources in europe-west1, europe-west4, etc., violating the requirement.
• D (Cloud Function monitoring): This is a detective and reactive control - resources are created first and destroyed after the fact. It's operationally risky (brief exposure window, potential data residency violation) and is not Google's recommended approach when a preventative policy exists.

Memory tip: Think "Policy over Process" - when Google asks about enforcing location or security constraints at scale, Organization Policy constraints are always the recommended answer over custom automation or per-tool validation, because they apply universally across all deployment methods.

No community discussion yet for this question.