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.

• ✗

  Create separate billing accounts for each environment

  Why it's wrong here

  Billing accounts are designed for cost aggregation and payment, not for resource hierarchy or identity management. Multiple projects across different environments can share a single billing account, and attaching projects to a billing account does not propagate IAM permissions or make policies apply to those projects. Therefore, creating separate billing accounts per environment would fragment cost visibility without giving you any way to manage IAM policies across projects.

• ✗

  Use organization policies at the project level

  Why it's wrong here

  Organization policies at the project level cannot enforce IAM rules uniformly across multiple projects within the same environment, because such policies are scoped to a single project and do not inherit across unrelated projects. This fails the requirement to apply policies affecting all projects in a given environment. The option is tempting because organisation policies are designed to set baseline constraints across an entire resource hierarchy, and would be correct if the goal were to enforce a blanket rule on every project under a single organisation node, rather than grouping projects by environment.

• ✓

  Apply IAM policies at the folder level

  Why this is correct

  Folders are hierarchical nodes in the resource hierarchy, and any IAM policy attached to a folder is inherited by all projects and resources within that folder. This lets you bind environment-wide roles, such as DevTeam or Viewer, once rather than repeating them on each project, giving consistent access across every project in the environment. It is the correct pattern because it uses native inheritance rather than per-project duplication.

• ✗

  Use labels to group projects by environment

  Why it's wrong here

  Labels are key-value metadata used for resource filtering, cost allocation, and reporting, and they do not create any parent-child relationship between projects. IAM policies cannot be attached to a label or inherited by projects that share a label, so labeling projects by environment is purely informational. It is useful for visibility and billing breakdowns, but it cannot enforce access control uniformly across the projects in an environment.

• ✓

  Create folders for each environment (dev, test, prod) and place projects in the appropriate folder

  Why this is correct

  Creating a folder for each environment and placing the corresponding projects under it establishes a logical grouping in the resource hierarchy. Once the folder exists, you can attach IAM policies and organization policy constraints to that folder, and every project beneath it automatically inherits those policies. This is the recommended way to organize many projects because it gives you a clear scope for policy administration, cost grouping, and per-environment guardrails.

Go deeper

Related to this question