Everything you create in Google Cloud sits in a tree called the resource hierarchy. At the top is the organization node, which represents your company and is tied to a Cloud Identity or Google Workspace domain such as example.com. Under it you can create folders, folders can contain other folders, and at the bottom are projects. Every resource, whether a VM, a bucket or a Cloud SQL instance, belongs to exactly one project. The hierarchy matters because it is how you apply access and rules to many resources at once instead of one at a time.
Projects are the basic unit of organization. Each one has its own set of enabled APIs, its own quotas and its own billing link, and it acts as a boundary for most resources. Folders usually mirror how the company works: by department (Finance, Engineering), by environment (Prod, Non-prod), or by team. A new organization is created automatically when a Cloud Identity or Workspace customer first creates a project, and administrators then decide who may create folders and projects.
Identity and Access Management (IAM) allow policies can be attached at the organization, folder, project and many individual resources. A policy is inherited by everything below it, and effective access is the union of all the policies from the resource up to the organization. That makes IAM additive: if a user is Viewer on a folder and Editor on a project inside it, they are Editor on that project. A child cannot remove a grant it inherits from a parent. When you truly need to block a permission regardless of grants, Google Cloud offers IAM deny policies, which are evaluated before allow policies.
Organization policies are a separate mechanism. Instead of saying who can do something, they restrict what can be configured, for example which regions resources may be created in, or whether VMs may have external IP addresses. Organization policies are also set on the organization, a folder or a project and are inherited downward. Depending on the constraint, a lower level can inherit the parent's policy, merge with it or replace it, if administrators allow that.
A practical design is to place broad, stable controls high in the tree (for example, security auditors as viewers at the organization, or a location restriction on an EU folder) and grant narrow, job-specific roles as low as possible, ideally on the project or the resource itself. This keeps least privilege intact and makes it easy to answer who has access to what.
Key terms
- Organization node
- The root of the hierarchy, tied to a Cloud Identity or Google Workspace domain.
- Folder
- A grouping of projects and other folders that lets you apply IAM and organization policies to all of them.
- Project
- The container that every resource belongs to, with its own APIs, quotas, IAM policy and billing link.
- Policy inheritance
- IAM and organization policies set on a node apply to every folder, project and resource beneath it.
A retailer creates folders named Prod and Non-prod under its organization. The security team is granted Security Reviewer at the organization, the platform team is Editor on the Non-prod folder only, and an organization policy on Prod blocks external IP addresses on VMs. New projects created in either folder get the right access and restrictions automatically.
Check yourself
A user is Viewer on the organization and has no project-level grants. Can they see resources in every project?
Yes. The Viewer grant at the organization is inherited by every folder and project below it.
What is the difference between an IAM allow policy and an organization policy?
An IAM policy says which principals have which roles. An organization policy restricts how resources may be configured, whatever roles the person has.