Google ACE Setting Up a Cloud Solution Environment 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 folders for dev, staging, and prod under the organization, then place projects in each folder

  Why this is correct

  Folders in the Google Cloud resource hierarchy allow you to organize projects under the organization node, and you can apply IAM policies and organization policies at the folder level, which are inherited by all projects within. This gives you a natural separation between dev, staging, and prod while enabling consistent controls, e.g., different approval workflows or network configurations. Placing projects in environment-specific folders is the standard best practice for multi-environment governance.

• ✗

  Use labels on projects to denote environment, but keep all in one folder

  Why it's wrong here

  Labels are key-value metadata for billing/cost allocation and resource organization, but they do not have a native IAM or policy inheritance capability. Relying on labels to denote environment does not prevent cross-environment access or make it easy to enforce different security controls. You would have to script label-based checks, and accidental mislabeling could lead to policy confusion. Also, keeping all projects in one folder means you cannot scope folder-level policies per environment.

• ✗

  Create separate projects for each environment without folders

  Why it's wrong here

  Creating separate projects for each environment without folders is better than a single project, but you lose the ability to attach common policies at a common parent. Since all projects would sit directly under the organization, any organization policy or IAM binding that should apply only to prod would require explicit per-project configuration. Without folders, there is no single place to set "deny" policies for dev or staging, increasing the chance of misconfiguration and drift. Folders add the needed hierarchy for inherited, environment-scoped governance.

• ✗

  Create a single project and use separate VPC networks per environment

  Why it's wrong here

  A single project with separate VPC networks per environment does not provide true administrative isolation: IAM roles in that project are shared, so a dev engineer with Project IAM permissions might interfere with production networking or billing. Also, key services like Cloud KMS keys, quotas, and billing are project-wide, meaning one environment's resource usage can affect another. Shared project also makes audit logging and cost attribution harder. Best practice is to use separate projects per environment, with folders above them for policy clarity.

Go deeper

Related to this question