GCP Resource Hierarchy Explained: Organisation, Folders, Projects and Resources
What is the GCP resource hierarchy?
The GCP resource hierarchy is a four-level tree that organises everything in Google Cloud: Organisation, Folders, Projects, and Resources. Every IAM permission you grant and every Organisation Policy you set travels down through this tree automatically — from the top of your company’s setup to every individual service you run.
This matters because the hierarchy determines who has access to what, what configurations are permitted, and how governance applies across your entire environment. Get it right from the start and managing dozens or hundreds of projects becomes straightforward. Get it wrong and broad, hard-to-remove permissions end up in places you never intended.
This page explains what each level is, how IAM and policy inheritance work through the tree, how to structure a hierarchy that scales, and the common mistakes that catch beginners off guard.
GCP resource hierarchy in simple terms
Think of GCP as a company building
The Organisation is the building itself — everything inside belongs to the company. Folders are the floors: you might have a Production floor and a Development floor. Each room on a floor is a Project, with its own budget, its own tools, and its own list of who is allowed in. The furniture and equipment inside each room are Resources: the actual VMs, databases, and storage buckets you create and use.
A rule posted on the building’s notice board applies to every floor, every room, and every piece of equipment — automatically. You cannot post a counter-rule on one room’s door that cancels out the notice board. The notice board always wins.
That is exactly how IAM inheritance works in GCP. Permissions granted at a higher level flow down to everything below, and lower levels cannot undo them.
How the GCP resource hierarchy works
The hierarchy is a tree of parent-child relationships. Each level wraps the one below it:
Organisation — the root node for your entire GCP environment. Set policies here and they apply to every folder, project, and resource below, without exception.
Folders — an optional grouping layer between the Organisation and your projects. Use them to represent environments (Production, Non-Production) or business units. Policies on a folder apply to every project inside it.
Projects — where your actual work lives. Every resource you create must belong to a GCP project, which controls billing, enabled APIs, access, and quotas.
Resources — the individual GCP services you create and use: Compute Engine VMs, Cloud Storage buckets, Cloud SQL databases, Pub/Sub topics, and service accounts.
When you attach an IAM policy to any node in this tree, that policy is inherited by every node below it. A policy on a folder applies to every project inside it. A policy on the Organisation applies to every folder, project, and resource in the company — including ones created tomorrow.
Master keys and room keys
A master key opens every door in a building. A room key opens one room. Granting access at the Organisation level is giving someone a master key. Granting access at the project level hands them a key to one room only. You can give someone additional keys to other rooms, but you cannot take back what the master key already opens by changing a single room’s lock.
Inheritance is additive, not reversible
If someone has the Owner role at the Organisation level, there is nothing
you can configure on a specific project to block their access to it. The only way to
remove that access is to go back to the Organisation level and remove the binding there.
Granting Owner or Editor at the Organisation or folder level
gives that access to every project and resource in the subtree below, including projects
you create next month. Always follow the
principle of least privilege:
grant the narrowest role at the narrowest scope that gets the job done.
The four levels of the GCP resource hierarchy
Organisation (acme.com) ├── Folder (Production) │ ├── Project (acme-api-prod) │ │ ├── Resource (Compute Engine VM) │ │ └── Resource (Cloud SQL database) │ └── Project (acme-web-prod) │ └── Resource (Cloud Storage bucket) └── Folder (Non-Production) ├── Project (acme-api-dev) └── Project (acme-web-dev)
Organisation
The Organisation node is the root of your entire GCP environment. It is created automatically when you set up Google Workspace or Cloud Identity for a domain. Every project and folder your company creates lives beneath this node.
Policies set at the Organisation level apply to every folder, project, and resource in your company without exception. This is where company-wide rules belong: enforced audit logging, restrictions on which regions are allowed, or a prohibition on public Cloud Storage buckets.
Practical example: You want to ensure no one in the company can create resources outside Europe. Set an Organisation Policy at the Organisation level restricting resource locations to EU regions. Every project in the company is covered automatically, with no per-project configuration needed.
If you signed up with a personal Gmail account, you will not have an Organisation node. Your projects sit at the top of the tree directly. This is fine for personal learning, but means you cannot set company-wide policies, see consolidated billing across projects, or use folders. For any team or business setup, use Google Workspace or Cloud Identity.
You do not manually add projects to an Organisation. When the Organisation exists, any project created by accounts in that domain is automatically placed underneath it.
Folders
Folders are an optional grouping layer between the Organisation and your projects. Use them to represent whatever structure makes sense for your company: environments, business units, product teams, or geographic divisions.
The most common and most useful starting point for most teams is two top-level folders: Production and Non-Production. This single split lets you apply stricter policies to live systems while giving developers broader freedom in non-production environments.
Practical example: You want developers to have Editor
access to all dev environments but zero access to production. Grant
roles/editor on the Non-Production folder. Developers can work freely and
are completely locked out of Production by default — because Production is a sibling
folder, not a parent.
Folders can nest up to 10 levels deep, but two or three levels are much easier to reason about. If you find yourself drawing a folder tree that needs a legend, it is already too deep.
Folders do not contain resources directly. Folders contain projects. Resources live inside projects, not inside folders. You cannot deploy a VM or a database to a folder.
Projects
Projects are where your actual work lives. Every resource in GCP — every VM, storage bucket, database, Pub/Sub topic, and service account — must belong to exactly one project. A GCP project controls which billing account pays for the resources inside it, which APIs are enabled, who has access, and what quotas apply.
Projects are the boundary you interact with every day. When you run a gcloud command, enable a service, or grant someone access, you are almost always working at the project level. Most IAM grants for individual contributors belong here.
Practical example: Your payments team works in
acme-payments-prod. You grant the team lead roles/editor on
that project. They have full access to resources there, but nothing in
acme-web-prod or any other project unless explicitly granted.
A project is not a network, a virtual machine, or a server. It is a logical container. Resources live inside it, but the project itself is the set of rules around them: billing, access, APIs, and quotas.
Resources
Resources are the actual GCP services you create and use: Compute Engine VMs, Cloud Storage buckets, BigQuery datasets, Cloud SQL databases, Pub/Sub topics, service accounts, and so on. Every resource belongs to exactly one project.
Some resource types support IAM policies at the resource level, letting you grant access more narrowly than the project. A Cloud Storage bucket can have its own IAM policy that gives one service account access to that specific bucket without granting access to anything else in the project.
Practical example: A data pipeline service account needs read access to one specific Cloud Storage bucket. Rather than granting a project-wide storage role, set the binding directly on that bucket. The service account has exactly the access it needs — nothing more.
Even when a resource has its own IAM policy, the project-level, folder-level, and Organisation-level policies above it still apply. Resource-level IAM adds permissions. It does not replace or cancel what was already granted higher up.
IAM inheritance in GCP
IAM in GCP works through bindings: a principal (user, group, or service account) is bound to a role on a resource. That binding can be placed at any level of the hierarchy, and it flows downward from wherever it is set.
How inherited bindings work in practice
Suppose your structure is:
acme.com (Organisation) → Production (Folder) → acme-api-prod (Project) → Cloud SQL database (Resource).
You grant a user roles/viewer on the Production folder. This means:
- They have
Vieweraccess to every project inside Production. - They have
Vieweraccess to every resource inside those projects. - Any new project added to Production gives them access automatically, with no extra steps needed.
If you also grant them roles/storage.objectAdmin on one specific project,
their effective permissions on storage resources in that project become Viewer (inherited
from the folder) plus Storage Object Admin (granted directly). The two bindings stack.
IAM permissions are always additive.
A member’s effective permissions on any resource are the union of all IAM bindings that apply at every level above it. Access is always additive. There is no “deny” that overrides a “grant” coming from a higher level. The only way to reduce someone’s access is to remove the binding at the level where it was originally granted.
Org-level, folder-level, and project-level grants
Grant access at the level that matches the scope of the work:
Organisation level: reserved for security and platform engineering teams who need visibility or control across everything. Think security auditors, billing administrators, or central platform teams. Use this sparingly.
Folder level: useful for environment-wide grants. Developers with full access to the Non-Production folder can build freely without touching anything in Production. A security team can have read access to everything in Production without seeing Non-Production at all.
Project level: the right level for most day-to-day access. Team members get the appropriate role on the project they work in, and nothing else.
Resource level: for genuinely fine-grained control. Use this to give one service account access to a specific Cloud Storage bucket without touching anything else in the project. See how IAM policies are structured to understand how bindings, roles, and principals fit together.
Grant access to Google Groups rather than individual users wherever possible. When someone joins or leaves a team, you update the group membership, not a dozen IAM policies across a dozen projects. See how identities and service accounts differ to understand when to use each type of principal.
IAM Conditions for time-limited access
If an on-call engineer needs temporary access to a production project, use IAM Conditions to attach a time-based constraint to the binding. It expires automatically after the incident window. No manual cleanup required and no risk of the grant being forgotten and left in place permanently.
Organisation Policies vs IAM
Both IAM and Organisation Policies inherit through the hierarchy, but they answer completely different questions.
IAM and Organisation Policies solve different problems
IAM controls who can do what. It answers: “Is this person allowed
to perform this action?” A user with Storage Object Creator can upload
objects to a Cloud Storage bucket. A user without that role cannot.
Organisation Policies control what can be configured or deployed at all. They answer: “Is this kind of configuration allowed here?” A policy constraint that prohibits public Cloud Storage buckets means no bucket in that scope can ever be made public, regardless of who is trying or what IAM permissions they hold.
In practice, you use both together. IAM ensures only your security team can manage policy constraints. The constraints themselves ensure that even a user with broad IAM permissions cannot create a misconfigured resource.
A developer has roles/storage.admin on a project, which normally lets
them make buckets public. An Organisation Policy constraint
storage.publicAccessPrevention set on the parent folder blocks this
entirely. The IAM role says “you can do this.” The Organisation Policy says “this
is not allowed here.” The Organisation Policy wins.
Organisation Policies also inherit downward and can only be made more restrictive at lower levels, not less restrictive (unless you explicitly set an exception). This makes them powerful for compliance: set a constraint at the Organisation level and every project in the company is covered automatically, including projects created tomorrow.
When to use folders in GCP
Folders are optional, but for most teams they are worth setting up early. Here are the main cases where folders genuinely help.
Production vs Non-Production separation
This is the single most important folder boundary. Put all live, customer-facing projects in a Production folder and everything else — development, staging, testing, sandboxes — in a Non-Production folder. This one split lets you apply stricter IAM and Organisation Policies to live systems without affecting your development environments.
Business unit or team separation
If your company has multiple independent teams or divisions, separate folders let you delegate control. A payments team manages their own projects without seeing or touching the data platform, and vice versa. Each folder can have its own IAM administrators. Use predefined roles rather than basic roles when granting access at the folder level.
Compliance or regional boundaries
If part of your infrastructure must comply with different regulations — GDPR-scoped EU workloads, or data that must stay in specific regions — a dedicated folder lets you apply Organisation Policy constraints to just those projects rather than everything in the company.
Shared services
Infrastructure shared across teams — a Shared VPC host project, a centralised logging setup, or a CI/CD toolchain — often sits best in its own folder with a dedicated owner, separate from both Production and Non-Production application projects.
If you are a solo developer or a very small team with two or three projects and no organisation-wide compliance requirements, placing projects directly under the Organisation node without folders is fine for now. Add folder structure before you start growing. Retrofitting it later is more work than getting it right at the start.
When this knowledge matters
Understanding the resource hierarchy is not abstract. It directly affects how you set up access, enforce guardrails, and structure your environment. Here is when this knowledge becomes immediately practical:
Setting up a new company GCP environment. The hierarchy is the first decision you make. Getting the Organisation, folder structure, and naming conventions right upfront saves significant rework later.
Planning IAM access before creating resources. Before you grant anyone a role, you need to know where in the tree to grant it. The principle of least privilege only makes sense once you understand how inheritance works.
Designing multi-project environments. If your team has more than one project, you need folders. Understanding how policies travel through the tree tells you exactly which grants and constraints to put at which level.
Separating production and development safely. The folder boundary is the mechanism that keeps a misconfigured development environment from affecting live systems. It is not just tidiness — it is a security control.
Applying guardrails with Organisation Policies. Organisation Policies are only as useful as the hierarchy they travel through. A constraint set at the right folder level covers exactly the right scope, automatically.
Debugging unexpected access. If someone has access they should not have, the hierarchy tells you where to look. Check the project policy, then the parent folder, then the Organisation. The binding is at one of those levels.
Using labels and tags for cost tracking. Labels and tags add metadata to resources for cost attribution and filtering within projects. They complement the hierarchy but do not replace it — knowing both helps you track spending across a multi-project environment.
GCP resource hierarchy vs related concepts
Resource hierarchy vs GCP projects
The hierarchy is the structure around projects. A GCP project is one node in that structure: the level where your resources actually live. The hierarchy gives you the ability to group projects and manage them collectively via folders and the Organisation. Without the hierarchy, you have isolated projects with no shared policy layer above them.
Folders vs projects
Folders group projects. Projects contain resources. You cannot put resources directly in a folder. You cannot deploy a VM, a database, or any other GCP service at the folder level. Folders exist solely for policy grouping and organisational structure. Projects are where the actual work and spending happen.
Resource hierarchy vs IAM
The hierarchy is the tree. IAM is the system that attaches roles to principals at nodes in that tree. The hierarchy determines how those role bindings propagate downward. You cannot understand how IAM works in GCP without knowing where in the tree a binding is placed and what that means for everything below it.
Resource hierarchy vs Organisation Policies
Like IAM bindings, Organisation Policy constraints are attached to nodes in the hierarchy and inherit downward. But they control configuration guardrails — what can be deployed — not who can act. Both systems use the same tree but solve different governance problems.
Common GCP resource hierarchy mistakes
No folders at all. Without folders, any policy that should apply to a group of projects must be applied to each one individually. When you create the tenth project under pressure, you will miss one. Folders let you set the policy once and have it apply to everything, including new projects added later.
Granting Owner or Editor too high in the tree. This is the most common and most costly hierarchy mistake. Someone who only needs access to one staging project gets
Editoron the Organisation “to save time.” They now have edit access to every project the company owns. Grant at the project level.Mixing production and development in the same folder. A policy applied to that folder affects both environments. One IAM grant, one Organisation Policy constraint, one mistake — it lands on your live system. Use at least two top-level folders from the start.
Confusing folders with projects. Folders are grouping containers. They do not hold resources. Resources live in projects. If you are trying to “put your database in the Production folder,” you are thinking of the wrong level.
Assuming lower-level IAM can cancel a higher-level grant. It cannot. If someone has
Ownerat the Organisation level, no IAM change at the project level will block them. Many beginners try to restrict a broad grant by modifying a project’s policy. Go back to the original level and remove it from there.Building deep folder nesting before you need it. Three levels of nesting for a five-person team is over-engineering. Start flat, add structure when you genuinely need it, and make sure every folder level adds real policy value, not just organisational tidiness.
Forgetting to link a billing account. The billing account is not part of the hierarchy itself — it sits alongside, linked to one or more projects. Forgetting to link it to a new project means paid resources will fail silently. Understand the GCP billing model before provisioning production infrastructure.
Best practice structure for a growing team
A well-designed hierarchy is one you can explain in two minutes and still understand a year from now. Here is a practical example for a company called Acme with several services and a small platform engineering team.
acme.com (Organisation)
├── Production
│ ├── acme-payments-prod
│ ├── acme-web-prod
│ └── acme-analytics-prod
├── Non-Production
│ ├── acme-payments-dev
│ ├── acme-payments-staging
│ ├── acme-web-dev
│ └── acme-web-staging
└── Shared Services
├── acme-shared-networking ← Shared VPC host project
├── acme-security-tooling ← Security scanning, audit log sink
└── acme-cicd ← CI/CD pipelines and Artifact RegistryWhy this structure works:
Production and Non-Production are separated. Stricter Organisation Policies and tighter IAM live on the Production folder. Developers have broader access in Non-Production and no access in Production by default.
Shared Services is its own folder. The platform team owns it. Application teams consume shared networking and CI/CD tooling without having any permissions to modify them. Billing for shared infrastructure is clear and separate.
The structure is shallow. Three folders, no nesting. Every project is exactly two hops from the Organisation root. Policies are easy to trace. New team members can understand the layout in five minutes.
It scales. Adding a new service means adding two or three projects under the existing folders. The IAM policies and Organisation Policy constraints on those folders apply immediately, with no manual policy work on the new projects.
Access patterns this structure makes clean
Security team needs read access to all production systems
Grant roles/viewer on the Production folder. They automatically have
read access to every project inside it, including new ones created next quarter.
No need to revisit individual project policies every time something is added.
Developers need full control of their dev environments
Grant roles/editor on the Non-Production folder. Developers can build
freely but cannot touch anything in Production, because Production is a sibling
folder, not a parent. The folder boundary does the work.
An on-call engineer needs temporary access to one production project
Grant the role at the project level with an IAM Condition that expires after the incident window. The condition removes itself. No cleanup required, no risk of a forgotten emergency grant sitting around permanently.
New developers join regularly
Add them to the appropriate Google Group. The group already has the right role on the right folder. No IAM policy changes needed across any individual project. Remove them from the group when they leave and access is gone immediately.
Summary
- The GCP resource hierarchy has four levels: Organisation, Folders, Projects, and Resources
- IAM policies and Organisation Policies set at any level inherit downward to everything below it
- Inherited permissions are additive — a higher-level grant cannot be overridden or blocked at a lower level
- A member’s effective permissions are the union of every binding that applies at every ancestor level
- IAM controls who can act. Organisation Policies control what can be configured. Both travel through the same hierarchy
- Separate Production and Non-Production into different folders from the very start
- Grant access at the narrowest scope that works and use Google Groups to manage team membership
- Keep the folder structure shallow — two or three levels is almost always enough
Frequently asked questions
What are the four levels of the GCP resource hierarchy?
The four levels from top to bottom are: Organisation (the root node tied to your company domain), Folders (optional groupings of projects), Projects (the primary boundary for resources, billing, and access), and Resources (individual services like VMs, storage buckets, and databases). IAM policies and Organisation Policies set at any level inherit downward to everything below it.
Do I need folders in GCP?
Folders are optional but strongly recommended for any setup with more than a handful of projects. The most useful starting point is two top-level folders: Production and Non-Production. This lets you apply different IAM and Organisation Policies to live systems versus development without touching individual projects. Very small teams with only one or two projects can skip folders initially, but add them before you grow.
Can I use GCP without an Organisation node?
Yes. If you sign up with a personal Google account, you get projects without an Organisation node. However, without an Organisation you cannot enforce company-wide policies, you lose consolidated billing visibility across projects, and you cannot use folders. For any team or business use, set up an Organisation node using Google Workspace or Cloud Identity. It is free and takes a few minutes.
Can a project belong to more than one folder?
No. A project can only have one parent: either a single folder or the Organisation node directly. Projects cannot belong to two folders simultaneously. If you need a project to apply to multiple organisational contexts, use IAM bindings and labels to reflect that rather than trying to place the project in multiple locations.
What is inherited through the GCP resource hierarchy?
Two things inherit downward: IAM bindings (who can do what) and Organisation Policy constraints (what can be configured or deployed). An IAM binding set at the Organisation level applies to every folder, project, and resource underneath. Neither can be revoked or blocked at a lower level — they can only be removed at the level where they were originally set.
What is the difference between IAM and Organisation Policies in GCP?
IAM controls who can perform actions — it answers "who is allowed to do this?" Organisation Policies control what can be configured or deployed — they answer "what is allowed to exist here?" For example, an IAM binding grants a user permission to create Cloud Storage buckets. An Organisation Policy can enforce that no bucket can ever be made public, regardless of who creates it. Both follow the hierarchy, but they solve different problems.
What is the best folder structure for a small team?
For a small team, keep it simple: two top-level folders named Production and Non-Production. Put all live projects under Production and everything else under Non-Production. This separation alone gives you meaningful policy control without adding complexity. Avoid adding more nesting until there is a clear reason for it.