GCP PCA — The Resource Hierarchy and the Landing Zone — where a thing lives decides what it may be

The PCA exam asks where a thing should live before it asks what the thing should be.

The map is drawn before the city is built, and every building afterward obeys a line nobody remembers drawing.

The PCA exam asks where a thing should live before it asks what the thing should be.

§IFrame: what this exam actually tests

Three cert fires into the Cloud rotation, and this is the first Google one. Before any content, the shape of the exam, because the shape changes how to study for it.

Published guidance puts the Professional Cloud Architect exam at 50 to 60 questions in 120 minutes. Four case studies are published in advance: EHR Healthcare, Mountkirk Games, Helicopter Racing League, and TerramEarth. A large share of the questions attach to those case studies, and the case text is available on a split screen during the exam.

That last detail changes the study plan. The case studies are not a surprise. Read all four before the exam, draw the architecture each one implies, and know which Google services each company's constraints rule out. A candidate who walks in having already designed for Mountkirk Games is answering from a diagram; a candidate who reads it cold is spending exam minutes on comprehension.

The exam has six sections. Third-party guides report their weightings at roughly: designing and planning architecture 24%, managing and provisioning infrastructure 15%, designing for security and compliance 18%, analyzing and optimizing processes 18%, managing implementation 11%, ensuring reliability 14%. Google does not publish those percentages as officially as AWS publishes its domain weights, so treat the numbers as a study-effort guide rather than a contract.

The reason to start at the resource hierarchy is that it is the one topic that shows up inside all six sections. A question about data residency is a hierarchy question. A question about which team can create a VM in which region is a hierarchy question. A question about who pays for the GKE cluster is a hierarchy question.

§IIThe hierarchy: four levels and one rule

Google Cloud's tree has four levels, top to bottom.

Organization. The root node, tied to a Cloud Identity or Google Workspace domain. Without one, projects float free with no common owner and no place to attach organization-wide policy. Creating the Organization is the first act of a landing zone.

Folders. Optional grouping nodes, nestable. Folders exist so that policy can attach to something between "everything" and "one project." A common shape is a folder per environment, or per business unit, or per environment inside per business unit.

Projects. The unit that matters most in daily work. A project is the boundary for billing, for APIs enabled, for quota, and for most resource naming. Every resource lives in exactly one project.

Resources. VMs, buckets, clusters, datasets.

The rule that governs all of it: privileges propagate down. An IAM role granted at the folder level applies to every project underneath. The effective policy on a resource is the union of the policy set directly on it and every policy inherited from its ancestors.

Coin the consequence, because the exam tests it repeatedly: inheritance is additive, so a grant made high is a grant you will not see when reading low. A user with roles/compute.admin at the organization node is a compute admin in a project whose IAM page lists no compute admins at all. Debugging "who can delete this VM" means walking up the tree, not reading one page.

There is one asymmetry worth memorizing exactly, because it is the single most-tested subtlety in this area. IAM allow-policies only accumulate downward and cannot be reduced at a lower level. Organization Policy constraints, by contrast, can be overridden at a lower node when the constraint permits it. The Bootcamp PCA notes state both halves plainly: privileges always propagate down, and the effective policy is a union, but Organization Policies such as a region restriction can be overwritten at lower levels.

IAM Deny policies are the exception on the IAM side, and they were added precisely because "additive only" left administrators with no way to carve an exception out of a broad grant.

§IIIOrg Policy versus IAM: the two-question split

The cleanest mnemonic in this whole area comes straight out of the Bootcamp notes and is worth writing on the inside of the eyelids.

Org Policy governs WHAT. IAM governs WHO.

IAM answers: which identity may perform which action on which resource. Its unit is the binding, which joins members to a role, optionally with a condition.

Org Policy answers: which configurations are permissible anywhere in this branch of the tree, regardless of who is asking. Its unit is the constraint. A project owner with every IAM permission Google offers still cannot create a VM in asia-southeast1 if a gcp.resourceLocations constraint on the parent folder forbids it.

That independence is the point. IAM alone cannot express "nobody, including me, may make a Cloud Storage bucket public," because IAM's vocabulary is about actors. The constraint storage.publicAccessPrevention expresses it about the configuration.

The constraints worth knowing by name for the exam:

• gcp.resourceLocations — restricts where resources may be created. The data-residency answer.
• storage.publicAccessPrevention — forbids public buckets outright.
• compute.vmExternalIpAccess — denies external IPs on VMs, forcing traffic through Cloud NAT and a controlled egress path.
• iam.disableServiceAccountKeyCreation — kills the downloadable JSON key, which is the most common long-lived-credential leak in a Google environment.
• iam.allowedPolicyMemberDomains — restricts IAM bindings to identities in named domains, which stops an engineer granting access to a personal Gmail account.
• compute.requireShieldedVm — the Bootcamp notes call Shielded VM the best practice, and this constraint is how it stops being optional.

Constraints come in two flavors. Boolean constraints are enforced or not. List constraints take allow or deny lists of values. Both support inheritance from the parent and an explicit override where the constraint's own definition permits it.

Exam trap. Org Policy is evaluated at resource-creation and configuration time. It is not a runtime firewall and it does not retroactively delete resources that predate it. Applying compute.vmExternalIpAccess to a folder does not strip the external IP off the VM that has had one since March. Answer choices that promise retroactive remediation are wrong; the correct answer pairs the constraint with a detection-and-remediation path.

§IVShared VPC: one network, many projects

The second half of a landing zone is where the network lives, and Google's answer is structurally different from the AWS one.

In Shared VPC, one project is designated the host project and owns the VPC network, its subnets, its routes, and its firewall rules. Other projects are attached as service projects, and their resources — VMs, GKE nodes, Cloud SQL instances via private service access — attach to subnets in the host project's network.

The separation is the reason to do it. Network engineers hold network-admin roles in the host project. Application teams hold compute roles in their own service projects and can build VMs, but cannot change a route, cannot open a firewall rule, and cannot create a subnet. One network, centrally governed, consumed by many teams.

Two roles carry the model:

• roles/compute.xpnAdmin — the Shared VPC Admin, granted at the organization or folder level, who attaches service projects to a host.
• roles/compute.networkUser — granted on the host project or, better, on a specific subnet, to the identities in a service project that may attach workloads there.

Granting networkUser on a single subnet rather than the whole host project is the least-privilege answer, and it is the one the exam rewards.

Shared VPC versus VPC Peering. These get confused, and the distinction is clean once stated. Shared VPC shares one network across projects in the same organization, with centralized administration. VPC Peering connects two separate networks, works across organizations, and each side keeps its own administration. Peering is also non-transitive: A peered to B and B peered to C does not give A a path to C. That non-transitivity is a recurring exam answer, usually as the reason a hub-and-spoke design needs Network Connectivity Center or a router appliance rather than a mesh of peerings.

Firewall scope is worth one line, because the Bootcamp notes flag it: classic firewall rules are defined at the project level, while firewall policies can attach at organization, folder, or project level and therefore inherit like other hierarchy-attached governance.

§VWorked Example: a landing zone for a regulated workload

Take a company running a healthcare workload that must keep data in the EU, plus a games backend with no residency constraint, and design the tree.

Organization example.com, backed by Cloud Identity. Super Admin exists, is not used for daily work, and is protected with hardware keys. Org Admin is the daily-driver role. The Bootcamp notes draw this line explicitly and add the asymmetry that matters: a Super Admin can grant Org Admin, and an Org Admin can only grant IAM roles.

Folders: shared-services, regulated, general.

Under regulated, projects ehr-prod and ehr-nonprod. Under general, games-prod and games-nonprod. Under shared-services, net-host (the Shared VPC host), logging, and security.

Org Policy placement:

• On regulated: gcp.resourceLocations allowing only EU regions. Every project underneath inherits the residency rule, and a new project created in that folder next year inherits it without anyone remembering to apply it. That is the argument for policy-at-folder over policy-at-project in one sentence.
• On the organization node: iam.disableServiceAccountKeyCreation, storage.publicAccessPrevention, iam.allowedPolicyMemberDomains restricted to the corporate domain.
• On general: an override relaxing compute.vmExternalIpAccess for a specific load-testing project, if and only if the constraint permits an override at that level. This is the "lower level can overwrite Org policy" case the notes name, and it is the reason to know which constraints allow it.

IAM placement: group-based, never user-based. [email protected] gets roles/compute.instanceAdmin on ehr-nonprod only. [email protected] gets roles/compute.networkAdmin on net-host. Roles attach to groups, groups attach to people through Cloud Identity, and offboarding a person becomes one group removal rather than an audit of every project.

The Ultimate PCA guide's Chapter 11 example is worth studying for the conditional binding it demonstrates: a roles/storage.objectViewer grant carrying a rule of the form request.time < timestamp(...). That is IAM Conditions, and it is Google's answer to time-bound elevated access. Where the exam presents a contractor who needs read access for one quarter, the conditional binding is the answer and a calendar reminder is not.

Billing: one billing account at the organization, all projects linked to it, labels such as env:prod and cost-center:ehr applied to resources for attribution. The notes are careful about a distinction the exam uses: labels are key-value pairs for organization and billing and have no operational effect, while network tags apply to network resources and do have effect, since firewall rules can select on them. Confusing the two is a standard distractor.

§VICross-Vendor Reach: how this maps to the AWS SAP arc

The 08-02 lesson built the AWS multi-account landing zone. The two clouds solve the same problem with different primitives, and holding both makes each clearer.

The important non-symmetry: an SCP is a deny boundary that filters the permissions an IAM policy can grant, so on AWS the effective permission is the intersection of SCP and IAM. On Google Cloud, IAM and Org Policy are two independent systems asking different questions, and a request must satisfy both. The AWS model is subtraction. The Google model is a pair of gates.

Second non-symmetry: the AWS account is a harder billing and blast-radius boundary than the Google project, and Google's project is cheaper to create and destroy. Designs that would use one AWS account per team frequently use several Google projects per team.

§VIIPractice Questions

§VIIIClosing

Today's Ops lesson built a client that decides when a remote dependency is not worth calling. Today's Dev lesson built a descriptor that decides whether a value may be assigned. Both are checks that sit in the path of an operation and refuse it before harm lands.

Organization Policy is the same shape at cloud scale. The constraint sits in the path of every resource creation in its branch, holds no opinion about who is asking, and answers one question: is this configuration permitted here. IAM is the second gate, asking the other question.

Read the four published case studies before the next PCA session. For each one, write down where in a folder tree its workloads belong and which constraint its compliance paragraph implies. The exam rewards the candidate who already has that mapping.