Enforce EU-Only Regions for Compute Engine Instances

Google Cloud Organization Policy & Compliance
Answer Correct answer: D — Apply an Organization Policy constraint to deny Compute Engine creation outside the EU and migrate existing non-compliant instances to approved regions.

You work for a global company. Due to compliance requirements, certain Compute Engine instances that reside within specific projects must be located exclusively in cloud regions within the European Union (EU). You need to ensure that existing non-compliant workloads are remediated and prevent future Compute Engine instances from being launched in restricted regions. What should you do?

  1. Use a third-party configuration management tool to monitor the location of Compute Engine instances. Automatically delete or migrate non-compliant instances, including existing deployments.
  2. Deploy a Security Command Center source to detect Compute Engine instances created outside the EU. Use a custom remediation function to automatically relocate the instances, run the function once a day.
  3. Use organization policy constraints in Resource Manager to enforce allowed regions for Compute Engine instance creation within specific projects.
  4. Set an organization policy that denies the creation of Compute Engine instances outside the EU. Apply the policy to the appropriate projects. Identify existing non-compliant instances and migrate the instances to compliant EU regions. Correct Answer

Community Votes

D
100%

100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

Tests geographic restriction enforcement via Organization Policy; the common trap is choosing third-party tools or manual detection over native IAM/Policy controls.

This question tests how to enforce geographic data residency requirements for Compute Engine workloads using native Google Cloud controls. The page establishes that Organization Policy constraints provide the definitive method to restrict instance creation to specific EU regions while guiding administrators on remediating legacy deployments.

Candidates often select third-party configuration management or Security Command Center alerts, overlooking that Organization Policy Constraints natively block non-compliant API calls at the resource level.

Community Discussion (4 comments)

Pime13 👍 1 Selected: D
https://cloud.google.com/resource-manager/docs/organization-policy/defining-locations-supported-services#compute-engine For example, an instance template is a global resource, but you might specify regional or zonal disks in an instance template. Those disks are subject to the resource locations constraints, so, in your instance template, you must specify disks in regions and zones that your org policy permits.
Zek 👍 1 Selected: D
https://cloud.google.com/resource-manager/docs/organization-policy/defining-locations-supported-services
MoAk 👍 1 Selected: D
https://cloud.google.com/resource-manager/docs/organization-policy/defining-locations-supported-services
yokoyan 👍 3 Selected: D
I think it's D.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

Organization Policy constraints in Resource Manager are designed specifically to govern resource creation across projects. By applying the constraints/compute.restrictAllowedZones (or equivalent region constraint) in ALLOW mode to target projects, you automatically deny any Compute Engine launch attempts outside the specified EU regions. This satisfies the prevention requirement, while identifying and migrating existing non-compliant VMs fulfills the remediation mandate outlined in the scenario.

Why the Other Options Are Wrong

Option A relies on external tooling and destructive actions rather than native access controls. Option B uses Security Command Center for detection only, introducing latency and requiring custom code instead of declarative policy enforcement. Option C correctly identifies the control mechanism but lacks the explicit remediation step required by the prompt, making D the more complete and operationally accurate choice.

Community Comment Notes

Multiple learners confirmed the selection by referencing official Google Cloud documentation on defining supported locations for Compute Engine. As noted by several users, the documentation explicitly validates using Organization Policy constraints to lock down regional deployments, reinforcing why the native control beats manual or third-party alternatives.

Official Reference

Exam Strategy

Always map compliance scenarios to Google Cloud's native governance tools first; Organization Policies are the standard answer for enforcing structural, regional, or naming restrictions across projects before considering manual processes or third-party integrations.

Frequently Asked Questions

Why not use Security Command Center to detect non-compliant VMs?

SCC detects and alerts but cannot natively enforce or block new resource creation; Organization Policies provide declarative, real-time enforcement at the API layer.

Can Organization Policy automatically migrate existing VMs?

No, it only prevents future creations. Existing workloads must be identified and migrated manually or via automation scripts after the policy is enforced.

Related Analysis

← Back to PCSE Study Guide