GCP for DevOps — Resource Hierarchy
GCP Resource Hierarchy
GCP organizes resources in a hierarchy that controls access, billing, and policy inheritance. Understanding this hierarchy is critical — it’s the backbone of how GCP security and governance work.
The Four Levels
┌─────────────────────────────────────────────────┐
│ GCP Resource Hierarchy │
├─────────────────────────────────────────────────┤
│ │
│ Level 1: Organization (optional) │
│ │ └── tied to Cloud Identity domain │
│ │ │
│ Level 2: Folders (optional, nestable) │
│ │ └── group projects logically │
│ │ │
│ Level 3: Projects (required) │
│ │ └── all resources live here │
│ │ │
│ Level 4: Resources │
│ └── VMs, buckets, clusters, etc. │
│ │
└─────────────────────────────────────────────────┘
Real-World Analogy: Think of it like a company: the Organization is the company itself, Folders are departments, Projects are teams, and Resources are the actual work product.
Organization
The Organization is the root node. It’s automatically created when you set up Cloud Identity or Google Workspace for your domain.
$ gcloud organizations list
DISPLAY_NAME ID DIRECTORY_CUSTOMER_ID
timesofcloud.com 123456789012 C0abcde12
$ gcloud organizations describe 123456789012
creationTime: '2024-01-15T10:00:00.000Z'
displayName: timesofcloud.com
lifecycleState: ACTIVE
name: organizations/123456789012
owner:
directoryCustomerId: C0abcde12
Note: If you’re using a personal Gmail account, you won’t have an Organization node. Projects exist directly under your account. For production use, always set up Cloud Identity.
Folders
Folders let you group projects logically. Folders can be nested up to 10 levels deep.
Organization: timesofcloud.com
├── Folder: Production
│ ├── Project: webapp-prod
│ └── Project: api-prod
├── Folder: Development
│ ├── Project: webapp-dev
│ └── Project: api-dev
├── Folder: Shared Services
│ ├── Project: shared-networking
│ └── Project: shared-monitoring
└── Folder: Sandbox
└── Project: engineer-sandbox
# Create a folder (requires Organization)
$ gcloud resource-manager folders create \
--display-name="Production" \
--organization=123456789012
Created Folder [folders/987654321012].
displayName: Production
lifecycleState: ACTIVE
name: folders/987654321012
parent: organizations/123456789012
# List folders
$ gcloud resource-manager folders list \
--organization=123456789012
DISPLAY_NAME PARENT ID
Production organizations/123456789012 987654321012
Development organizations/123456789012 111222333444
Shared Services organizations/123456789012 555666777888
Projects
Projects are the fundamental organizational unit in GCP. Every resource (VMs, buckets, clusters) belongs to exactly one project.
A project has three identifiers:
| Identifier | Example | Notes |
|---|---|---|
| Project Name | “My Web App” | Human-readable, can be changed |
| Project ID | my-web-app-12345 |
Globally unique, immutable |
| Project Number | 123456789012 |
Auto-assigned, immutable |
# Create a project
$ gcloud projects create my-devops-lab \
--name="DevOps Lab" \
--folder=987654321012
Create in progress for [https://cloudresourcemanager.googleapis.com/v1/projects/my-devops-lab].
Waiting for [operations/cp.123456789] to finish...done.
# List your projects
$ gcloud projects list
PROJECT_ID NAME PROJECT_NUMBER
my-devops-lab DevOps Lab 123456789012
my-first-project First Proj 234567890123
# Set active project
$ gcloud config set project my-devops-lab
Updated property [core/project].
Policy Inheritance
IAM policies and organization policies inherit downward through the hierarchy:
Organization (policy: "All users must use MFA")
│
├── Folder: Production (policy: "No external IPs on VMs")
│ │
│ └── Project: webapp-prod (inherits BOTH policies)
│ │
│ └── VM instance (inherits ALL three levels)
│
└── Folder: Development (no extra policies)
│
└── Project: webapp-dev (inherits only org policy)
Key rules:
- Policies set at a higher level are inherited by all children
- A child cannot remove a policy set by a parent
- A child can add more restrictive policies
- The effective policy is the union of all inherited policies
Enabling APIs
GCP requires you to enable APIs before you can use a service. This is a common gotcha for beginners:
# Enable Compute Engine API
$ gcloud services enable compute.googleapis.com
Operation "operations/abc123" finished successfully.
# Enable multiple APIs at once
$ gcloud services enable \
compute.googleapis.com \
container.googleapis.com \
cloudbuild.googleapis.com \
secretmanager.googleapis.com
# List enabled APIs
$ gcloud services list --enabled --format="table(name)"
NAME
bigquery.googleapis.com
compute.googleapis.com
container.googleapis.com
cloudbuild.googleapis.com
secretmanager.googleapis.com
storage-api.googleapis.com
Common Mistakes
| Mistake | Fix |
|---|---|
| Not enabling APIs before use | Enable required APIs first: gcloud services enable <api> |
| Using one project for everything | Separate projects for prod, dev, shared services |
| Ignoring policy inheritance | Set policies at the right level — they flow down |
| Not tracking project IDs | Use meaningful project IDs (they’re permanent) |
| Forgetting to link billing | Link billing account to each project |
Quick Reference
| Command | Description |
|---|---|
gcloud projects create <id> |
Create a project |
gcloud projects list |
List all projects |
gcloud config set project <id> |
Set active project |
gcloud resource-manager folders create |
Create a folder |
gcloud services enable <api> |
Enable an API |
gcloud services list --enabled |
List enabled APIs |
gcloud organizations list |
List organizations |
Next → GCP Free Tier
