Cloud Digital Leader How Google Cloud Resources Are Managed 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 with tags: define a tag 'exempt' and attach it to exempted projects; set the policy condition to apply unless the resource has the tag.

  Why this is correct

  Organization policies support conditional enforcement through tags. By defining a tag key such as 'exempt' and attaching it to the projects that should be excluded, you can write a policy condition (e.g., resource.matchTag("exempt", "true")) that prevents the constraint from applying to those tagged resources. This allows you to enforce a global policy against large VM instances while selectively exempting specific projects without moving them in the hierarchy, preserving existing IAM and folder structure with minimal administrative overhead.

• ✗

  Use IAM conditions with a custom role to deny creation of large instances.

  Why it's wrong here

  IAM conditions are designed to restrict the effective permissions of a principal on existing resources, not to enforce organizational constraints like instance size limits at resource creation time. A custom role could technically be conditioned to deny the compute.instances.create permission for certain machine types, but this requires complex logic and does not scale across projects, since you would need to bind the role to every relevant principal. Moreover, IAM Deny policies are separate from organization policy constraints and are not the intended mechanism for enforcing resource-shape rules; organization policies provide a deterministic, project-wide guardrail.

• ✗

  Create a folder for exempted projects and apply a allow policy to that folder.

  Why it's wrong here

  Moving the exempted projects into a separate folder to apply a permissive policy is structurally invasive and changes the resource hierarchy, which can break existing folder-level IAM roles, audit logs, and organizational boundaries. Additionally, organization policy constraints work as inherited deny-lists; a folder-level 'allow' policy does not automatically override a higher-level constraint unless carefully configured with tags or per-project overrides, and it cannot be done by simply 'applying an allow policy' to the folder. This approach increases management complexity and risks unintended effects, making it inferior to a tag-based conditional exemption.

• ✗

  Apply a custom organization policy at the folder level without tags, and add exceptions in each project individually.

  Why it's wrong here

  Applying a custom organization policy at the folder level and then manually configuring exceptions in each project defeats the purpose of centralized governance. You would have to edit every project's policy individually, which is error-prone, difficult to audit, and creates a maintenance burden as projects are added or removed. Organization policies are inherited hierarchically; to exempt a project, you must either override at the project level (if overrides are permitted) or use a conditional tag, but the former is not scalable and often results in inconsistent policy states across the organization.

Go deeper

Related to this question