Resource Hierarchy
Hierarchy
Everything you create in GCP lives somewhere in one tree:
- Organization - the root, tied to your Cloud Identity / Workspace domain. Company-wide policy lives here.
- Folders - optional grouping (departments, teams, environments). Folders can nest.
- Projects - the unit of everything practical: billing linkage, API enablement, quotas, most IAM. Every resource belongs to exactly one project. A project is also a trust boundary - services within the same project share the same default level of trust.
- Resources - VMs, buckets, clusters, ... the leaves.
The organization resource
The org is the root node, tied 1:1 to a Google Workspace or Cloud Identity account.
You don't create an organization by hand. When a user with a Google Workspace or Cloud Identity account creates their first Google Cloud project, an organization resource is automatically provisioned for them, and Google Cloud announces its availability to the account's super admins.
Two roles drive org setup and lifecycle, and are generally held by different users or groups:
| Role | Responsibilities |
|---|---|
| Workspace / Cloud Identity super admin | Assign the Organization Admin role to some users; be the point of contact for recovery issues; control the lifecycle of the account and org resource. (Sits above the hierarchy - see Cloud Identity.) |
| Organization Admin | Define IAM policies; determine the structure of the resource hierarchy; delegate critical components (networking, billing, hierarchy) through IAM roles - useful for auditing. |
By design the Organization Admin role does NOT include folder creation (or many other actions). To get those permissions the Org Admin must grant themselves an additional role (e.g. Folder Creator). The two setup roles are deliberately split.
Folders as sub-organizations
Folders are a grouping mechanism and an isolation boundary between projects - think of them as sub-organizations. Use them to model different legal entities, departments, and teams, nested as deep as you need (Dept -> Team -> Product).
- Delegate administration - grant a department head full ownership of every resource in their folder, without touching the rest of the org.
- Limit access by folder - users in one department can only access and create resources within their folder.
Policies
Two things flow DOWN this tree and explain most exam questions about it:
- IAM policies - a role granted at a level is inherited by everything below it. The effective policy at a node = union of its own policy and all ancestors'.
- Organization policies - constraints (e.g. "no external IPs") set high, enforced below.
A child allow policy cannot REVOKE access granted by a parent. If someone is Editor at the folder level, no project-level allow policy can take that away - you must change the grant where it was made. This is the #1 hierarchy trap question. (The exception is an IAM deny policy, which is evaluated before allow policies and can block access regardless of an inherited grant.)
How a deny policy trumps an inherited grant
Alice is a storage admin. Someone granted her roles/storage.admin way up at the
Organization level, and thanks to inheritance that grant quietly flows all the way down to
every bucket in project prod. Read, write, delete - she can do it all.
One day a security admin decides nobody should be able to delete objects in prod, not even
admins. Rewriting Alice's org-level grant is off the table (a child policy can't revoke it),
so they attach a deny policy to the prod project: deny storage.objects.delete for
Alice. Next time Alice tries to delete a file, IAM:
- Checks deny policies first, sees the rule, and stops right there - request blocked.
- Never even consults her
storage.admingrant up the tree; the deny already settled it.
So Alice keeps listing and reading objects (nothing denies those), but the delete button is effectively dead for her - even though, on paper, she still holds an admin role above.
Quotas, API enablement, and billing linkage are all per-project.
Resource Manager roles at each level
Each level has its own Resource Manager roles that mirror one another. Because policies are inherited top to bottom, a role granted high up applies to everything beneath it.
The Project Creator role can be granted at the organization level, where it is then inherited by every project below - one grant that lets a user create projects anywhere in the org.
Organization Restrictions
A separate guardrail that works from the outside: Organization Restrictions prevent data exfiltration through phishing or insider attacks by ensuring that managed devices in your organization can reach resources only in authorized Google Cloud organizations, not any other org an employee might try to sign into.
It takes two administrators working together:
- Google Cloud administrator - administers Google Cloud.
- Egress proxy administrator - configures the customer-managed egress proxy.
The egress proxy adds an organization-restriction header to every request leaving a managed device. Google Cloud inspects that header on all incoming requests and allows or denies each one based on the organization being accessed.
Typical uses:
- Restrict employees to resources in your Google Cloud organization only.
- Allow employees to read from Cloud Storage but still confine them to your organization.
- Allow a vendor organization in addition to your own.
Organization Restrictions rely on a customer-managed egress proxy stamping the header, so they only cover requests from managed devices routed through that proxy. This is a perimeter control against exfiltration - it does not replace IAM or organization policies, it works alongside them.