Resource Hierarchy and Organization Policies

What it is

The resource hierarchy is the tree of organization, folders, projects and resources. Both IAM allow policies and organization policies are attached to nodes in this tree and flow down to everything below.

A good hierarchy lets you secure hundreds of projects with a few policies set on folders, instead of configuring each project.

How it works

Designing folders and projects

Manage this at scale with infrastructure as code, for example Terraform modules that create projects with standard labels, budgets, APIs and IAM. Cloud Asset Inventory searches and exports every resource and policy across the organization.

Inheritance of IAM

The effective allow policy on a resource is the union of its own policy and every ancestor's. A grant on a folder applies to every project in it, and a child cannot remove a parent's grant.

Moving a project to another folder changes its inherited policies at once, so check what it gains and loses first.

Organization policies

Organization policies set what configurations are allowed, whatever IAM permits. Each policy sets a constraint on a node.

name: folders/123456789/policies/gcp.resourceLocations
spec:
  rules:
  - values:
      allowedValues:
      - in:eu-locations

gcloud org-policies set-policy eu-only.yaml

Inheritance of organization policies

By default a node inherits its parent's policy. A child can replace it, or for list constraints merge with it, if the person has the Organization Policy Administrator role. Changes apply to new actions; most constraints do not alter resources that already exist.

Roll out safely with dry run policies, which log what would be denied without blocking. Tags plus conditional organization policies let one folder hold projects with different rules.

Custom organization policies

When no predefined constraint fits, write a custom constraint with a CEL condition on fields of a supported resource type.

name: organizations/123456789/customConstraints/custom.disableGkeAutoUpgrade
resourceTypes:
- container.googleapis.com/NodePool
methodTypes:
- CREATE
- UPDATE
condition: "resource.management.autoUpgrade == false"
actionType: DENY
displayName: Block GKE node pools without auto upgrade

gcloud org-policies set-custom-constraint custom-gke.yaml

After creating the constraint, enforce it with a normal policy on the organization, a folder or a project. Custom constraints are preventive: they block the non-compliant create or update request.

A worked example

A company is moving 200 projects to Google Cloud under strict EU residency rules. The engineer creates prod and nonprod folders under a business unit folder, and sets gcp.resourceLocations to in:eu-locations, domain restricted sharing and key creation blocking at the organization.

A dry-run custom constraint on the prod folder blocking GKE node pools without auto upgrade logs violations for two weeks before enforcement. Projects are created by a Terraform pipeline, so every new project inherits all of it.

How the exam asks about this

• "Ensure no IAM role can ever be granted to a Gmail account or another company's users." Domain restricted sharing with iam.allowedPolicyMemberDomains.
• "All resources in the analytics folder must stay in Europe." gcp.resourceLocations set on that folder.
• "Block GKE node pools that have auto upgrade turned off, and no predefined constraint exists." A custom organization policy constraint, tested in dry run first.