Multi-Account Governance — GCP Professional Cloud Architect (PCA)
Hierarchy Level Sets the Policy Blast Radius
Architecture requirement: enforce a restriction with the smallest blast radius that satisfies the stated scope. Competing choices: organization, folder, project. The deciding constraint is the explicit scope of governance in the scenario. Org-level constraints apply universally — appropriate for audit log mandates or service-disable policies that must hold everywhere. Folder-level constraints scope to a business unit or environment tier. Project-level constraints isolate a single team's exception. Binding at the wrong level either over-restricts unrelated teams or silently under-enforces the stated policy.
What This Pattern Tests
The exam tests which governance tool operates at which scope. Organization-wide guardrails prevent accounts from exceeding boundaries. Account-level policies grant specific permissions within those boundaries. Cross-account access needs explicit trust relationships. Compliance monitoring needs centralized aggregation.
Decision Axis
Governance scope (org-wide vs. account-specific vs. cross-account) determines the control mechanism.
Associated Traps
More Top Traps on This Exam
Decision Rules
Whether to attach the gcp.resourceLocations Organization Policy constraint at the Prod folder level (where it inherits to all current and future child projects automatically) versus at the level of each existing individual project (where new projects added later are uncovered until manually configured).
Whether to structure billing accounts as one shared org-level account with Billing Account Viewer granted broadly to all finance contacts, versus creating separate per-BU billing accounts explicitly linked to each division's projects and scoping Billing Account Viewer to each BU's own billing account.
At which hierarchy level to apply the gcs.resourceLocations Organization Policy constraint so that the data-residency restriction covers all current and future projects under the Prod folder without requiring per-project remediation.
Whether to enforce PCI-DSS CDE isolation at the folder level (org policy constraints + dedicated billing account) or at the individual project level (project-scoped constraints + cost labels) — determining which scope guarantees policy inheritance for all current and future CDE projects and satisfies the audit separation requirement.
At which resource hierarchy level should the gcs.restrictLocations org policy constraint be applied so that both existing and future child projects in the Prod folder are covered without per-project remediation?
Whether to apply the constraints/gcp.resourceLocations Organization Policy constraint at the Prod folder scope versus at individual project scope — folder-level application inherits downward to all current and future child projects at creation time, while project-level application is static and silently fails to cover projects not yet created.
Domain Coverage
Difficulty Breakdown