Cloud Digital Leader Google Cloud Security 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.

• ✗

  Cloud Audit Logs

  Why it's wrong here

  Cloud Audit Logs are an observability and auditing mechanism that records actions performed in Google Cloud, such as who created a resource, when, and from where. They are entirely passive: they capture a trail of events for security and compliance review, but they do not evaluate or block any request based on region. Because audit logs cannot enforce restrictions or reject a resource creation request in a disallowed location, they do not satisfy a workload running in a required geographic area.

• ✓

  Organization policy with location restriction

  Why this is correct

  The organization policy constraint `gcp.resourceLocations` is the correct mechanism because it actively enforces geographic compliance at resource creation time. By defining an allowlist of permitted locations at the organization, folder, or project level, Google Cloud blocks any attempt to create a resource outside those regions. This is a centralized, context-aware enforcement that works across supported services, making it the native, authoritative way to guarantee workloads run only in mandated locations.

• ✗

  VPC Service Controls

  Why it's wrong here

  VPC Service Controls create security perimeters that regulate data movement to and from supported Google Cloud services, primarily to prevent exfiltration of sensitive data. They do not restrict where resources are physically or virtually created; a resource can still be provisioned in any region permitted by other policies. While perimeters can be configured for specific regions, that is an artifact of resource location rather than a boundary that enforces location compliance, so VPC SC alone cannot ensure a workload runs solely in approved locations.

• ✗

  IAM conditions with resource location

  Why it's wrong here

  IAM conditions allow fine-grained access control based on attributes like `resource.location`, so you can limit a principal's permissions to act on resources that already exist in certain regions. However, they are not a global enforcement mechanism for resource placement: they must be attached to specific roles and principals, and they are only supported for a limited set of services and operations. For create operations, the condition may not be evaluated consistently, and it doesn't prevent other authorized principals or automated services from creating resources in disallowed regions. Thus, IAM conditions cannot provide a reliable, org-wide restriction on where workloads are deployed.

Go deeper

Related to this question