GCP
Intermediate 15 min read GCP

GCP Projects and Organization

The resource hierarchy and billing boundary

GCP is organized as an org → folder → project tree. IAM binds roles to members at any level, billing rolls up per project, and folders/org policies set guardrails.

GCP projectsfoldersorganizationIAMresource hierarchybilling
Prerequisites: GCP Service Catalog Cloud Account Structure
Before we start

What you will learn

  • Structure org → folders → projects
  • Apply IAM boolean/role bindings at the right node
  • Use folders and org policies for governance
In 60 seconds

Google Cloud resources nest: Organization → Folders → Projects → Resources. IAM roles bind at any level and inherit down; billing is per-project; Organization policies constrain creation/usage.

Introduction

What is this?

The GCP resource hierarchy starts at the Organization (the root of all resources, tied to a Cloud Identity/Workspace domain). Folders group projects into teams/environments for policy and IAM aggregation. Projects are the core container: every API-enabled resource lives in a project, which owns quota and billing. IAM binds roles to principals (users, groups, service accounts) at org/folder/project/resource scopes; permissions inherit down unless overridden. Organization/Project policies (constraints like 'restrict VM external IPs') enforce guardrails.

Motivation

Why do you need it?

  • Project isolation is the blast-radius unit: prod vs dev projects keep leakage small.
  • Folder-level IAM lets a security team read everything without touching each project.
  • Billing attribution is per project — cost centers map directly to projects.
  • Org policies stop 'oops, I made a public bucket' before it happens.
Think about it

Mental model

Imagine

A company HQ with floors, teams and desks

Think of

Org, folders, projects, resources

HQ (org) sets company policy; floors (folders) organize teams; each team's rooms (projects) hold their desks (resources). Security badges issued at HQ carry into every room; floor guards enforce extra rules.

Mechanics

How it works

  • Organization root grants the initial Organization Admin; folders nest beneath.
  • Projects get unique project IDs/names/numbers; billing account(s) attach at project or folder level.
  • IAM allows/denies at scopes: org → folder → project → resource; child can't grant what parent denies.
  • ServicAccounts are machine identities; keys are restricted best-practice (prefer workload identity).
  • Org policies are constraints enforced during resource creation/use (e.g. deny public buckets, restrict regions).

GCP resource hierarchy.

Organization
Folder: prod
Folder: dev
Project
Resources
Hands-on

Examples

Inspect hierarchy and apply a role

Inspect hierarchy and apply a role
# List projects you can see
gcloud projects list --format=table(projectId,name)
 
# Set a folder-scoped viewer role (folder 12345)
gcloud projects add-iam-policy-binding <project-id> \
  --member group:platform@example.com --role roles/viewer
 
# Check org policy constraints in a project
gcloud resource-manager org-policies list --project <project-id>

CLI trails show where you are in the tree — project list, IAM bindings, and constraints reveal governance in one sweep.

Real world

In production

  • A platform org uses one folder per environment, a shared infra folder, and a security folder with a log sink.
  • A startup pins each product to its own project with per-product billing and a shared network project.
  • A bank applies an org policy banning external IPs on VMs inside the prod folder.
Guidelines

Best practices

  • Give each environment/team a project; avoid one-and-done 'everything' projects early.
  • Bind IAM at the highest node that is safe (e.g. Viewer at org, Editor at project).
  • Use folder-level org policies and validate in audit mode before enforcing.
  • Restrict service account keys; prefer workload identity federation in CI.
Watch out

Common mistakes

  • Granting Owner at org level to whoever builds the first project.
  • Creating 200 projects with no folder structure or naming convention.
  • Putting prod and dev in one project to 'simplify' billing.
  • Enabling a deny org policy before a rollout plan — breakage and pushback.
Root cause analysis

Common issues

Error
Cannot create resource in an allowed region
Root cause

Org policy restrictRegions constraint excludes it

Fix

Check restrictRegions at org/folder/project and request an exception or use an allowed region.

Error
CI can't access a bucket
Root cause

Service account lacks storage.objectViewer on the bucket/project

Fix

Grant the role at the correct scope or use the project-level default compute SA carefully.

Error
Billing shows unknown spend
Root cause

Another project uses the same billing account, or missing labels

Fix

Review per-project cost reports and apply budget alerts per project.

When things break

Debugging tips

  • Permission denied at project but granted at folder → check folder binding and inherited role.
  • Quota errors: verify the project's quota and the region's capacity separately.
  • Org policy blocking a deploy → look at constraint violations in the Cloud Logging audit trail.
  • Use `gcloud projects get-iam-policy` and `--format=json` to diff policy drift.
Interviews

Interview checkpoint

Practice

Hands-on lab

Walk the Project Hierarchy and a Budget
25 min · beginner
In progress
Objectives
  • List projects and inspect their metadata
  • Create a budget alert for a project
  • Verify IAM bindings at folder/project scope

Walk the Project Hierarchy and a Budget

25 min · beginner

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

What is the smallest container that holds GCP resources and owns quota/billing?

2

An organization policy can forbid the creation of publicly-exposed buckets.

Go deeper

Official documentation

GCP — Resource hierarchy
docs
GCP — IAM overview
docs
GCP — Org policy constraints
docs