Defining the resource hierarchy

Defining the Resource Hierarchy

Managing Folders and Projects at Scale

The GCP resource hierarchy is a tree structure that starts with the organization node at the very top, representing your entire company or enterprise. Below the organization sit folders, which act as containers that can hold either projects or other folders, allowing you to create nested groupings that mirror your company's structure. Projects are the main units where resources like virtual machines, storage buckets, and databases actually live, and each project has its own billing account and set of permissions. When managing many projects at scale, folders let you group related projects together so you can apply policies and access controls to dozens or hundreds of projects at once rather than managing each one individually. The hierarchy flows downward: the organization contains folders, folders contain projects, and projects contain resources, so changes at a higher level can affect everything below it.

Managing Pre-Built or Custom Organization Policies

Organization policies are rules that you can set at any level of the hierarchy to control what people can do with resources. GCP provides pre-built policies for common restrictions, such as preventing public IP addresses on VMs or requiring disks to be encrypted with a specific key, and these can be applied immediately without configuration. You can also create custom policies that define your own constraints based on your security requirements, and these policies are written as constraints that the system enforces. When you set a policy at the organization level, it automatically applies to all folders and projects beneath it, but you can override it at a lower level if needed. The key relationship is that policies flow downward: a folder inherits policies from the organization, and a project inherits policies from its folder, unless a more specific policy explicitly replaces them.

Using the Resource Hierarchy for Access Control and Permissions Inheritance

IAM (Identity and Access Management) works closely with the resource hierarchy to control who can access what. When you grant someone access at the organization level, they automatically have access to everything inside it—every folder, project, and resource—because permissions inherit downward. You can also grant more limited access at the folder or project level, and these permissions apply to everything contained within that level. The inheritance works like a waterfall: if you give a team permission at the project level, they get access to all resources in that project, but they do not automatically get access to other projects in the same folder. This means you can grant broad access high up in the hierarchy for administrators while giving narrower access at lower levels for specific teams, and the system automatically combines all the permissions that apply to a user when they try to access a resource.