Google ACE Setting Up a Cloud Solution Environment Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Apply an organization policy with constraint gcp.resourceLocations to allow only us-central1 and europe-west1.

  Why this is correct

  The gcp.resourceLocations organization policy constraint is a list constraint that defines the exact set of Google Cloud locations where new resources, including Compute Engine instances, may be created. Setting it to allow only us-central1 and europe-west1 at the organization or folder level makes non-compliance impossible at creation time, since the API call itself is rejected. This is a preventive, centralized governance mechanism that is inheritable across projects, making it the correct solution for enforcing geographic restrictions.

• ✗

  Use VPC Service Controls to restrict access to Compute Engine API from other regions.

  Why it's wrong here

  VPC Service Controls works by establishing security perimeters around Google Cloud services, so API requests from outside the perimeter are blocked, but it does not influence the physical location where a Compute Engine instance is provisioned. The service is designed to mitigate data exfiltration—for example, preventing authorized users from calling Compute Engine APIs to copy data out of the perimeter—not to deny resource creation in a particular region. Consequently, it cannot enforce that instances are launched only in the allowed zones.

• ✗

  Use labels to tag instances and run a script to delete non-compliant ones.

  Why it's wrong here

  Labeling instances and running a cleanup script is a reactive detection-and-remediation approach, not a preventive control: it allows non-compliant instances to be created and run until the script discovers and deletes them. This leaves a window where unapproved resources exist, contributing to cost, compliance risk, and operational overhead, and the script itself is a custom, breakable component outside Google Cloud's policy engine. A true governance solution must reject the creation request at the API layer, not merely remediate after the fact.

• ✗

  Create an IAM policy denying the compute.instances.create permission in all other regions.

  Why it's wrong here

  IAM policies cannot enforce location-based restrictions on the compute.instances.create permission because that permission is a global API permission with no inherent regional scope, and IAM conditions do not support a resource-location attribute for creation requests. While IAM conditions can check parameters like resource tags or service identity, they have no built-in condition key that captures the destination region of a new Compute Engine instance. Therefore, denying compute.instances.create in all other regions is impossible with IAM; you could deny it globally, but that would block all instance creation everywhere.

Go deeper

Related to this question