Google PCA: Organization Design, IAM and Cloud Governance — Study Guide

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Part of the Google Professional Cloud Architect — Study Guide. Practice with verified answers in the Google exam hub, or take timed practice tests on ExamRoll.io.

Overview

Organization design, IAM, and governance establish the foundation on which all Google Cloud architectures run. Good designs create clear administrative boundaries, minimize blast radius, enable least privilege, control cost, and scale operationally across many teams and environments. Governance should emphasize guardrails over gates: automate defaults that are secure, measurable, and reversible, while delegating day-to-day control to the teams closest to the workload.

Resource Hierarchy and Identity Foundations

Google Cloud resources form a strict tree: Organization → Folders → Projects → Resources (for example, Compute Engine instances, buckets). IAM policies and Organization Policy constraints inherit down the tree.

Key design principles:

• Use a single Organization to centralize governance. Create top-level Folders for major administrative boundaries (for example, business units, regions, or regulated vs. non-regulated).
• Within each boundary, create environment Folders (prod, nonprod) to apply differentiated policies. Keep projects workload-scoped and ephemeral where possible to reduce blast radius and ease chargeback.
• Inheritance: allow grants accumulate (union of allow bindings from ancestors and the node). IAM Deny policies, if used, take precedence and can block access even if an allow exists. Avoid placing broad roles high in the tree; the blast radius is large and difficult to unwind.

Identity sources:

• Cloud Identity is the workforce identity plane. Integrate with your enterprise IdP (SAML/OIDC) to centralize authentication and lifecycle (joiners, movers, leavers). Use Google Cloud Directory Sync for attribute and group synchronization if required.
• Groups are the primary IAM subjects. Group-based access enables scalable changes and auditable ownership. Use a group-of-groups pattern (for example, net-admins, sec-admins, app-team-A) and restrict who can manage group membership.
• Service accounts represent workloads. Prefer service account impersonation with short-lived credentials over stored keys. Avoid user-managed service account keys; treat them as exceptions with tight approvals and rotation.
• Workload identity patterns:
  • GKE Workload Identity binds Kubernetes service accounts to Google service accounts; eliminates node-wide credentials.
  • Workload Identity Federation enables external identities (on-prem, other clouds, GitHub Actions) to obtain short-lived Google access without keys. Use pool/provider scoping and attribute conditions to constrain access.

Common failure modes and mitigations:

• Granting primitive roles (Owner/Editor/Viewer) at Folder or Organization level leads to pervasive over-privilege. Use only in tightly scoped break-glass projects.
• Group sprawl with unclear ownership undermines least privilege. Enforce naming, purpose tags, and owner metadata on groups.
• Orphaned service accounts and stale bindings accumulate risk. Schedule recurring access reviews and use IAM Recommender to reduce unused permissions.

IAM Models, Roles, and Access Operations

Roles and bindings:

• Predefined roles are curated for specific services and should be the default choice.
• Custom roles fill gaps when predefined roles are too coarse. Build from the minimal set of permissions observed as necessary; version and test them.
• Basic roles (Viewer/Editor/Owner) are legacy and overly broad. Avoid at Organization and Folder scopes. Do not use Owner for daily operations; reserve for platform break-glass with strong compensating controls.
• Conditional role bindings (IAM Conditions) constrain when and where a binding applies using attributes such as resource.name, resource.matchTag, request.time, or request.auth.audiences. Use conditions for time-bounded access, tag-scoped access to prod, or location-restricted actions.

Least privilege and privilege elevation:

• Separate “read,” “operate,” and “administer” duties. For example, network, security, and app teams get distinct roles on distinct scopes.
• Use just-in-time elevation with Access Approval workflows or ticket-driven automation to bind time-limited roles via conditions.

Deny policies and hazards:

• IAM Deny can centrally block risky permissions (for example, resourcemanager.projects.delete). Deny overrides allow and applies to the entire subtree. Validate thoroughly; misconfigured denies can lock out automation or break deployments.

Auditability and reviews:

• Enable Admin Activity logs at Organization; they are retained for 400 days by default. For sensitive services, enable Data Access logs and route them to BigQuery for long-term retention and auditing.
• Implement periodic access reviews: enumerate bindings with Cloud Asset Inventory, compare to ownership registries, remove unused roles suggested by IAM Recommender, and verify exceptions expiry.

Useful example (time-bounded, tag-scoped binding):

• gcloud projects add-iam-policy-binding PROJECT_ID –member=“group:prod-ops@example.com” –role=“roles/compute.instanceAdmin.v1” –condition=‘title=ProdOnlyTemp,expression=resource.matchTag(“organizations/1234567890/env”,“prod”) && request.time < timestamp(“2026-01-01T00:00:00Z”)’

Financial Governance and Organization Policy Guardrails

Billing architecture:

• Centralize one or more billing accounts under Finance ownership. Use multiple billing accounts only when legally or operationally required (for example, separate entities or reseller models).
• Link projects to billing accounts via automation; do not allow manual linking outside of approved workflows.

Chargeback and cost visibility:

• Use labels and cost allocation tags consistently. Labels are free-form metadata for filtering and reporting; tags are hierarchical and usable in IAM Conditions and policies. Enable cost allocation for selected tags to appear in billing exports.
• Export billing data to BigQuery for analytics; build dashboards per owner, cost center, and environment. Require each project to have an accountable owner and budget.

Budgets and anomaly detection:

• Create budgets with alerts at Folder and project levels. Add programmatic reactions (for example, notify on-call, open tickets, or disable new quota increases) to curb runaway spend.
• Use Quotas and commitments (CUDs) aligned to expected usage; monitor utilization.

Organization Policy constraints (secure-by-default):

• Enforce guardrails at Organization or Folder level and relax only where justified. Common constraints:
  • constraints/iam.disableServiceAccountKeyCreation = true
  • constraints/compute.requireOsLogin = true
  • constraints/compute.trustedImageProjects restricting VM images
  • constraints/sql.restrictPublicIp = true
  • constraints/storage.uniformBucketLevelAccess = true
  • constraints/compute.disableSerialPortAccess = true
• Use VPC Service Controls to reduce data exfiltration risk for supported services across sensitive perimeters.

Policy exception handling:

• Exceptions must be requestable, approved, time-bound, and auditable. Prefer IAM Conditions to scope exceptions by tag/time. Periodically reconcile exceptions and auto-expire them via policy-as-code pipelines.

Example Organization Policy (YAML) to disable service account keys:

• name: organizations/1234567890/policies/iam.disableServiceAccountKeyCreation spec: rules:
  • enforce: true Then apply: gcloud org-policies set-policy policy.yaml

Landing Zones, Shared Services, Automation, and Operating Models

Landing zone:

• Provide a pre-hardened baseline: Organization Policies, logging sinks, CMEK strategy, Shared VPCs, private DNS, Cloud NAT, Private Service Connect, audit and security projects, and restricted image catalogs.
• Separate host projects per environment for Shared VPC. Network admins control host projects; application teams deploy in service projects attached to the correct host.

Project factory:

• Automate project creation with infrastructure-as-code. Stamp out projects with:
  • Correct Folder placement and billing link
  • Pre-bound groups and roles
  • Default service accounts disabled or restricted
  • Logging sinks to central projects and retention buckets
  • Predefined budgets, labels, and tags
• Use Terraform modules or Cloud Config Controller to codify the factory. Enforce policy validation in CI before applying changes.

Shared services and isolation:

• Centralize identity, networking, CI/CD, artifact registries, and security tooling in dedicated projects. Isolate environments by Folder and VPC; block lateral movement with firewall policies, separate service perimeters, and distinct Cloud KMS keyrings per environment.
• Use Private Service Connect and producer projects to publish shared services to consumers without exposing public endpoints.

Audit logging and governance automation:

• Route Admin Activity and Data Access logs to an audit project. Configure log buckets with CMEK and retention policies aligned to compliance.
• Use Cloud Asset Inventory feeds to Pub/Sub plus Cloud Functions/Cloud Run to detect drift (for example, public buckets) and auto-remediate or open tickets.
• Policy-as-code stack:
  • Org Policies and IAM as code stored in a repo
  • Config Validator/Policy Controller for KRM resources
  • Pre-deployment policy checks in CI/CD
  • Scheduled reconciler jobs to re-apply the desired state

Resource naming and tags:

• Enforce short, readable naming patterns that encode environment, app, region, and sequence (for example, appA-prd-usw2-web-01). Reserve tags for governance (env=prod, pii=true, owner=team-x). Validate presence of required labels/tags at project creation.

Multi-team operations and delegated administration:

• Establish platform, security, and network teams with clearly defined scopes and roles. Delegate project-level administration to application teams within their Folder boundary. Provide self-service within guardrails via catalogs and templates.
• Balance autonomy vs. risk by pushing decisions that have low blast radius to teams and centralizing decisions that impact many projects or shared infrastructure.

Practical Problem Scenario

Contoso Retail plans to onboard eight product teams to Google Cloud within three months. Each team needs prod and nonprod environments, isolated networking, centralized security logging, and cost accountability. The platform team must prevent service account key sprawl, restrict VM images, and enable time-bound elevated access for incident response.

Approach:

1. Establish the hierarchy and folders

• Create top-level Folders for departments and nested Folders for prod and nonprod. Rationale: clear administrative boundaries allow targeted guardrails and budgets while enabling delegated administration to product teams without granting org-wide powers.

2. Deploy a landing zone with Shared VPC

• Create host projects for prod and nonprod networks managed by the network team. Attach team service projects via Shared VPC. Rationale: centralizes routing, NAT, and firewall policy while isolating workloads by project; prevents ad hoc networking that leads to sprawl and inconsistent security.

3. Implement organization policy guardrails

• Enforce constraints: disable service account key creation, require OS Login, restrict public IPs for Cloud SQL, restrict VM images to trusted projects, and enable uniform bucket-level access. Rationale: secure-by-default reduces high-frequency misconfigurations; exceptions can be time-bound where necessary.

4. Stand up identity and groups

• Integrate Cloud Identity with the enterprise IdP; create groups for each team’s dev, ops, and admin personas and platform-level groups for network-admins and sec-admins. Rationale: group-based IAM scales and aligns with separation of duties; lifecycle follows HR events.

5. Define IAM with least privilege and conditional elevation

• Bind predefined roles to groups at Folder or project scope; enable incident-response elevation via conditional bindings limited to prod-tagged resources and expiring after 24 hours. Rationale: least privilege for day-to-day, with safe, auditable escalation when needed.

6. Build a project factory pipeline

• Use Terraform modules to create projects with required labels/tags (env, owner, cost-center), link billing, attach to the correct Shared VPC, create logging sinks to a central audit project, and set budgets. Rationale: consistent, compliant provisioning at scale eliminates manual drift and speeds onboarding.

7. Centralize audit logging and access reviews

• Route Admin Activity and Data Access logs to BigQuery with CMEK; schedule monthly queries to enumerate IAM bindings and compare to group ownership and last-access data from IAM Recommender. Rationale: durable audit trail and continuous right-sizing of access reduce risk and cost.

8. Cost governance and alerts

• Enable cost allocation tags and labels, export billing data to BigQuery, and set per-Folder and per-project budgets with notifications to finance and team leads. Rationale: transparent chargeback drives accountability; early alerts curb runaway spend.

9. Workload identity and keyless automation

• For GKE, enable Workload Identity; for external CI (GitHub), set up Workload Identity Federation scoped to specific repositories with conditions. Rationale: eliminates long-lived keys and constrains usage to intended workloads.

10. Exception process and automation

• Implement a request workflow that creates conditional IAM bindings or temporary policy relaxations with automatic expiry via CI. Rationale: empowers teams without sacrificing control; every exception is time-bound and auditable.

Technical outcomes:

• Teams self-serve new projects in under 15 minutes with compliant defaults.
• No user-managed service account keys are allowed; incident-response elevation is time-bound and tag-scoped.
• Costs roll up by team and environment, with automated budgets and anomaly alerts.
• Audit logs and access reviews continuously validate that permissions and policies match intent.

All domains · Compute →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Google →