GCP resource hierarchy — org, folders, projects and IAM inheritance

Google Cloud Platform organises resources in a four-level hierarchy: organisation, folders, projects, and individual resources. Like Azure’s management group structure, each level is a scope at which IAM policies and organisation policies can be applied and inherited downward. Unlike Azure, GCP’s hierarchy is tied to a Google Workspace or Cloud Identity domain at the organisation level, making domain ownership the prerequisite for the root governance scope rather than an Azure AD tenant.

IAM policies in GCP use an additive model: a policy applied at the organisation level adds permissions to all resources below it, and policies at lower scopes can only add more permissions, never restrict what was granted above. This additive-only inheritance is fundamentally different from AWS and Azure, where deny policies at higher scopes override allow policies at lower scopes. In GCP, the only mechanism for restricting access granted at a higher scope is organisation policies, which constrain resource configuration rather than IAM permissions.

Projects are the foundational unit of GCP resource management: every GCP resource belongs to exactly one project, APIs are enabled per project, and billing is tracked per project. This project-centric model means that environment isolation in GCP is achieved by using separate projects for production and development rather than separate resource groups within the same project. Understanding this distinction is critical because the recommended GCP landing zone pattern uses dozens of projects where Azure might use a handful of resource groups.

Analogy🏏Cricket

🏏 Think of it like cricket: In Test cricket, the ICC publishes playing conditions — governing over rates, DRS quotas, pitch inspection protocols, and player conduct — that both captains sign before the first session, whether the match is at Lord’s, the MCG, or Eden Gardens. Just as the playing conditions give umpires a single authoritative standard so every ruling references the same document rather than personal judgement, the Well-Architected Framework gives architects a shared evaluation language so every workload is measured against the same six pillars rather than each engineer’s intuition. Just as a team posting a slow over rate incurs penalties regardless of their score, a workload with Security or Reliability gaps carries structural risk regardless of how quickly it shipped. Just as every specialist role — opener, keeper, tail — has defined performance expectations against which selectors evaluate each player, every workload component is evaluated against pillar-specific best-practice questions. This reveals why the framework must precede any advanced architectural decision: a shared, evidence-based standard transforms subjective trade-offs into structured, auditable risk assessments that hold across teams, accounts, and regions.