Google PCA Design and plan a cloud solution architecture Practice Question

A financial services company is designing a Google Cloud landing zone. Regulators require that production workloads be isolated from non-production workloads, that each business unit control its own billing and quotas, and that a central team enforce network and security policies across everything. The company wants to minimize the number of projects it must manage manually. Which structure should the architect propose?

⚠ Common exam trap

The trap here is treating billing separation as achievable through labels, when a billing account must be linked to a project or be inherited from a parent, and labels are only metadata.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

A folder per business unit, with production and non-production subfolders under each, projects created inside those subfolders, and organization policies plus shared VPC set at the folder level.

The recommended Google Cloud resource hierarchy nests environment subfolders inside business-unit folders, because organization policies, IAM, and Shared VPC settings attached at a folder are inherited by every project beneath it, including projects created later. This satisfies workload isolation, delegated billing and quota ownership per unit, and centralized policy enforcement while keeping manual per-project work to a minimum as the estate grows.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
A flat set of projects directly under the organization node, with a distinct service account per project and firewall rules copied into each project's VPC.
Why it's wrong here
A flat hierarchy gives no place to attach inherited policies, so every new project needs manual firewall and IAM configuration, which contradicts the minimize-management goal. Copying firewall rules per project also drifts over time and cannot enforce a uniform security baseline. This design scales poorly and weakens the central enforcement requirement.
✓
A folder per business unit, with production and non-production subfolders under each, projects created inside those subfolders, and organization policies plus shared VPC set at the folder level.
Why this is correct
Folder-per-business-unit with environment subfolders gives each unit its own projects and billing accounts while letting a central team attach organization policies and Shared VPC host configuration at the folder level, so those controls inherit to every current and future project. This is the recommended resource hierarchy pattern and avoids per-project manual policy assignment as the company grows.
✗
One project per environment (production, staging, development) under the organization node, with folders used only for IAM groups.
Why it's wrong here
A single production project shared by all business units breaks the requirement that each unit control its own billing and quotas, and it concentrates blast radius. Folders cannot hold IAM groups; they contain projects and other folders, and IAM policies are attached to them. This layout fails both isolation and delegated-control requirements.
✗
Two folders, one for production and one for non-production, with all business unit projects placed in the matching folder and billing separated by project labels.
Why it's wrong here
Environment-first folders satisfy isolation but give business units no delegated boundary of their own, so per-unit quota and billing control must be configured project by project. Labels are metadata for reporting and cannot back a billing account, so the billing requirement is unmet. This layout also forces the central team to touch every unit's projects directly.

Go deeper

Google PCA Design and plan a cloud solution architecture Practice Question

Why each option matters

Option-by-option breakdown

Related to this question