Resource Hierarchy: Organization, Folders, Projects

GCP Basics · Foundations – Regions, Resource Hierarchy, gcloud and Billing · Lesson 2 of 5

Every resource belongs to a project; projects sit in folders under an organization, and IAM and organization policies set higher up are inherited downwards.

Google Cloud organises everything in a tree. Policies attached higher in the tree are inherited by everything below.

flowchart TB
  O["Organization example.com"] --> F1["Folder Production"]
  O --> F2["Folder Non-production"]
  F1 --> P1["Project dl-lab-prod"]
  F2 --> P2["Project dl-lab-dev"]
  P1 --> R1["VM, bucket, Cloud SQL"]
  %% step O: The organization node is tied to a Cloud Identity or Google Workspace domain and is the root of the tree.
  %% step F1: Folders group projects by department, environment or team, and can be nested.
  %% step F2: Policies set on a folder apply to every project inside it.
  %% step P1: A project is the container for resources, APIs, billing link and quotas.
  %% step R1: Resources such as VMs and buckets always belong to exactly one project.

The four levels

Level	What it is	Notes
Organization	Root node for a company, linked to a Cloud Identity / Workspace domain	Created automatically when the domain first uses Google Cloud
Folder	Group of projects and other folders	Up to 10 levels deep; good for environments or business units
Project	Base unit for resources, APIs, IAM, billing and quotas	Has a project ID (globally unique, permanent), a project name (changeable) and a project number (assigned by Google)
Resource	VM, bucket, dataset…	Belongs to one project

What is inherited

IAM allow policies are additive down the tree: a role granted on a folder applies to every project and resource below it. You cannot remove an inherited role lower down; use IAM deny policies or restructure.
Organization policies (constraints such as “no external IPs on VMs”) are inherited and can be overridden lower down only if the policy allows it.
Billing is not inherited: each project is linked to a billing account on its own.

Project identifiers

The project ID (for example dl-lab-prod) is what you type in gcloud --project. It is unique across all of Google Cloud and can never be changed or reused after deletion. Deleting a project starts a 30-day shutdown period during which you can restore it.

A typical layout

example.com (organization)
├── Production
│   ├── dl-shop-prod
│   └── dl-network-hub       ← Shared VPC host project
├── Non-production
│   ├── dl-shop-dev
│   └── dl-shop-test
└── Sandbox                  ← short-lived projects, strict budgets

Separate projects per environment give you clean IAM boundaries, separate quotas and a clear cost per environment.

Command	Meaning
`gcloud projects create dl-lab-dev --folder=123456789012`	New project in a folder
`gcloud projects list`	Projects you can see
`gcloud resource-manager folders list --organization=111122223333`	Folders under the organization
`gcloud projects delete dl-lab-dev`	Shut down (restorable for 30 days)

Traps: project IDs are permanent; IAM is inherited and additive; without an organization node (personal Gmail accounts) you cannot use folders or organization policies.