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.

• ✗

  Use Organization Policy to restrict allowed regions

  Why it's wrong here

  Organization policies in Google Cloud are enforced hierarchically at the organization, folder, or project level, not per user or group. The `gcp.resourceLocations` constraint sets allowed regions for all resources and all principals in that scope, which is too broad for a requirement limited to developers. Applying such a policy would restrict everyone in the Google Cloud resource hierarchy, not just the developer group, and would violate the least-privilege principle.

• ✗

  Create a custom role with permission restricted to us-central1

  Why it's wrong here

  Custom roles in IAM are collections of permissions that define what actions a principal can perform, but they do not carry any regional context. The `compute.instances.create` permission is a binary allow for creating instances anywhere in the project; a role definition alone cannot be scoped to a specific region. To enforce the region restriction, you must attach an IAM condition to the role binding, such as `resource.location == 'us-central1'`, which is a separate mechanism from the role definition.

• ✓

  Grant the Compute Instance Admin role with an IAM condition on resource.location

  Why this is correct

  Granting the Compute Instance Admin role with an IAM condition on `resource.location` restricts instance creation to only the `us-central1` region by evaluating the resource’s location attribute at request time. This satisfies the constraint that developers cannot create instances outside that specific region, using a native IAM condition rather than a separate organisational policy.

• ✗

  Create a separate project for each region

  Why it's wrong here

  Creating a separate project per region is an organizational design choice, not an IAM mechanism, and it does not inherently restrict a developer's ability to create instances in other projects unless additional IAM bindings are omitted. Even with separate projects, a developer could be granted permissions in multiple projects, and managing cross-project permissions would be cumbersome and error-prone. This approach lacks the granularity and direct enforcement of an IAM condition on a specific resource attribute like `resource.location`.

Go deeper

Related to this question