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.

• ✓

  At the organization node

  Why this is correct

  The organization node is the root of the Google Cloud resource hierarchy, and an IAM policy attached there is automatically inherited by every folder and project below it, including resources that will be created in the future. This ensures uniform permission enforcement across the entire organization without needing to replicate the policy on each folder or project. It is Google Cloud's recommended pattern for establishing baseline roles that should apply to all resources, providing a single authoritative binding that simplifies audit and governance.

• ✗

  At the project level for each project

  Why it's wrong here

  Applying IAM policies directly to each project is inefficient because every project requires a separate binding, and there is no inheritance or propagation between projects. Any new project added later would be left without the policy unless administrators remember to configure it manually, leading to drift and inconsistent security posture. This approach only works for project-specific grants and is not a scalable mechanism for enforcing a global baseline across an organization.

• ✗

  Using tags on individual resources

  Why it's wrong here

  Tags are key-value metadata attached to resources or projects, and they do not grant permissions on their own. While tags can be referenced inside IAM condition expressions to make a role binding conditional—for instance, allowing access only when a certain tag is present—they are not an IAM policy construct and cannot be used to assign permissions globally across projects. Therefore, tags are a supporting mechanism for fine-grained conditional access, not a substitute for an organization-level IAM policy binding.

• ✗

  At the folder level for each environment

  Why it's wrong here

  Assigning an IAM policy at the environment folder level limits its inheritance to only the projects directly within that folder's subtree. Each environment folder (e.g., dev, staging, prod) would require a separate binding, and any project placed outside these folders—or in a newly created environment folder—would fall outside the policy, causing inconsistent enforcement across the organization. Folder-level policies are appropriate for environment-specific delegation, but they cannot serve as a single organization-wide control point.

Go deeper

Related to this question