Resource Hierarchy and Organization Policies

What it is

Google Cloud resources live in a resource hierarchy: an organization node at the top, optional folders, projects, and the resources inside projects. Organization policies are guardrails set on this hierarchy, for example "no external IP addresses on VMs" or "resources only in EU locations". IAM controls who can act; organization policies control what may be configured, whoever does it.

How it works

The levels

Creating the hierarchy

# create a folder under the organization
gcloud resource-manager folders create --display-name="Production" --organization=ORGANIZATION_ID

# create a project inside that folder
gcloud projects create shop-prod-1234 --folder=FOLDER_ID

# move an existing project into a folder
gcloud beta projects move shop-dev-1234 --folder=FOLDER_ID

Creating folders needs the Folder Creator role; creating projects in the organization needs Project Creator (roles/resourcemanager.projectCreator).

Inheritance

IAM allow policies are inherited downward and added together: a role granted on a folder applies to every project in it, and you cannot remove an inherited permission lower down by granting less. Organization policies are also inherited, but a lower level can be set to merge with, replace or inherit the parent's policy, where the constraint allows it.

Organization policies

An organization policy applies a constraint to a resource node. Two kinds:

Policies are written as YAML and applied with the gcloud org-policies commands:

gcloud org-policies set-policy policy.yaml
gcloud org-policies describe gcp.resourceLocations --project=shop-prod-1234

You need the Organization Policy Administrator role (roles/orgpolicy.policyAdmin), granted at the organization, to manage these policies. Organization policies are not retroactive: existing resources that break a new policy are not deleted.

Standalone organizations

A company can have more than one organization, for example to keep a subsidiary separate. Each organization is tied to its own Cloud Identity or Workspace domain, and policies do not cross between organizations. Setting one up means verifying a domain in Cloud Identity, then creating projects so the organization node appears.

A worked scenario

A company wants separate production and development environments, development data only in the EU, and no external IPs on production VMs. The engineer creates Production and Development folders, puts projects under each, sets gcp.resourceLocations on the Development folder to EU locations, and sets compute.vmExternalIpAccess on the Production folder to deny all. A team's IAM role on its folder covers every project in it.

How the exam asks about this

• "Apply a rule to every project in a department." Set it on the department's folder.
• "Restrict the regions where resources can be created." The resource locations organization policy.
• "Only allow IAM members from our own domain." Domain restricted sharing (iam.allowedPolicyMemberDomains).
• "A role granted on the folder still applies even though it was removed in the project." An inherited allow policy grant cannot be removed lower down.