Resource Hierarchy (Organisations, Folders, Projects)

Google Cloud Platform organises all resources within a clearly defined hierarchy. Understanding this hierarchy is fundamental because it determines how you manage access control, apply policies, and organise billing. Every resource you create in GCP — a virtual machine, a storage bucket, a database — lives inside a project, and projects can be organised within folders and an organisation.

---

The Four Levels of the Resource Hierarchy

The GCP resource hierarchy has four levels:

Organisation
└── Folder (optional, can be nested)
    └── Project
        └── Resource (VM, bucket, database, etc.)

Level	Description
Organisation	The root node of the hierarchy, representing your company or institution
Folder	An optional grouping mechanism for projects (can be nested up to 10 levels deep)
Project	The fundamental organising entity in GCP — all resources belong to a project
Resource	The actual GCP services you use (VMs, buckets, databases, etc.)

---

Organisation

The Organisation is the top-level node in the GCP resource hierarchy. It represents your company, institution, or domain and is automatically created when you set up Google Workspace or Cloud Identity with a domain.

Key characteristics:

• There is one Organisation per Google Workspace or Cloud Identity domain
• The Organisation provides centralised visibility and control over all GCP resources in the domain
• IAM policies set at the Organisation level are inherited by all folders, projects, and resources beneath it
• The Organisation Administrator role grants the ability to manage IAM policies and view all resources across the entire organisation
• Organisation policies (constraints) can be applied at this level to enforce governance rules across all projects

Without an Organisation, projects exist independently and cannot be centrally managed.

Creating an Organisation

An Organisation node is created automatically when:

1. A Google Workspace customer starts using GCP
2. A Cloud Identity Free or Premium account is set up

If you are using a personal Gmail account, you will not have an Organisation node — your projects will exist independently.

---

Folders

Folders provide an additional grouping layer between the Organisation and projects. They are optional but extremely useful for large organisations.

Key characteristics:

• Folders can be nested up to 10 levels deep
• A folder can contain projects and other folders
• IAM policies set on a folder are inherited by all projects and sub-folders within it
• Organisation policies can be applied at the folder level for more granular governance
• Folders typically map to departments, teams, environments, or business units

Common Folder Structures

By Department

Organisation
├── Engineering
│   ├── Project: backend-api
│   └── Project: frontend-app
├── Data Science
│   └── Project: ml-platform
└── Finance
    └── Project: billing-dashboard

By Environment

Organisation
├── Production
│   ├── Project: prod-api
│   └── Project: prod-data
├── Staging
│   └── Project: staging-api
└── Development
    └── Project: dev-api

Hybrid (Department + Environment)

Organisation
├── Engineering
│   ├── Production
│   │   └── Project: eng-prod
│   └── Development
│       └── Project: eng-dev
└── Marketing
    └── Production
        └── Project: mkt-prod

---

Projects

The project is the most important level of the GCP resource hierarchy. Every GCP resource — a Compute Engine VM, a Cloud Storage bucket, a BigQuery dataset — must belong to a project.

Project Properties

Every project has three identifiers:

Property	Description	Example
Project Name	A human-readable name (can be changed)	My First Project
Project ID	A globally unique identifier (set at creation, cannot be changed)	my-first-project-123456
Project Number	An automatically assigned numeric ID	123456789012

The Project ID is the most commonly used identifier in CLI commands and API calls.

What Projects Control