Resource hierarchy & org policy

Org → folders → projects, and inherited guardrails.

GCP security starts with the resource hierarchy, because that tree is what IAM allow policies and organization policies flow down. Get the shape right and guardrails apply everywhere by inheritance; get it wrong and you are re-applying controls project by project and missing some.

Organization → Folders → Projects → resources

The organization is the root, folders group projects by team or environment, and projects are the unit of isolation and billing. An IAM binding at a folder is inherited by every project beneath it; an organization policy constraint set at the org applies to all of it unless deliberately relaxed lower down. The project is your primary blast-radius boundary — prod, staging, and shared services belong in separate projects so a compromise in one cannot reach another.

Organization (acme.com)
 ├─ Folder: security         → org policies + log sink live here
 │   ├─ Project: logging      (locked log buckets, aggregated sink)
 │   └─ Project: scc-tooling   (Security Command Center)
 ├─ Folder: production        → stricter org policies inherited by all prod
 │   ├─ Project: payments-prod
 │   └─ Project: web-prod
 └─ Folder: sandbox           → looser policies, no prod data
 
# Org policy set on the "production" folder is inherited by every project in it:
gcloud resource-manager org-policies enable-enforce \
  constraints/compute.requireShieldedVm --folder=FOLDER_ID

Organization policies are configuration guardrails

Organization policies are distinct from IAM: IAM decides who-can-do-what, org policy decides what-configuration-is-allowed-at-all. Constraints like disabling service-account key creation, requiring OS Login, blocking external IPs on VMs, and restricting resource sharing to your own domain cap the whole hierarchy below where they are set — and even a project Owner cannot cross them. They are the preventive backbone of a landing zone.