GCP Concepts & Resource Hierarchy
Resource Hierarchy
Organization (tied 1:1 to a domain — e.g. theodo.com)
└── Folder(s) (optional grouping — by env, team, BU)
└── Project (hard tenancy boundary — billing, APIs, IAM all scoped here)
└── Resources (GCS buckets, VMs, BigQuery datasets, Cloud Run, etc.)
A Project is the GCP equivalent of an AWS Account or an Azure Subscription — it is the smallest unit of isolation.
Projects can exist without an org (personal/Gmail accounts). They float under your Google Account directly.
Identity & Account Concepts
| Concept | What it is |
|---|---|
| Google Account | Your identity (you@gmail.com or you@theodo.com) |
| Cloud Identity / Google Workspace | Manages users & groups for a domain. Provisioning an org requires one of these. |
| Organization | GCP resource container tied to a domain. Auto-created when you set up Cloud Identity/Workspace. |
| Service Account | A non-human identity for workloads. Both an identity and a resource you can grant access to. |
Relationships
| Relationship | Cardinality | Notes |
|---|---|---|
| Domain → Organization | 1 : 1 | One domain, one org. No exceptions. |
| Google Account ↔ Organization | n : n | A user can be member of many orgs (via IAM); an org has many users. |
| Google Account → create Orgs | 1 : n | You can create multiple orgs if you control multiple domains. |
| Organization → Folders | 1 : n | Folders are optional but recommended for large setups. |
| Organization → Projects | 1 : n | Projects live under org (or directly under a folder). |
| Project → Billing Account | n : 1 | A project has exactly one billing account at a time (switchable). |
| Billing Account → Projects | 1 : n | One billing account funds many projects. |
| Organization → Billing Accounts | 1 : n | An org can have multiple billing accounts (per team, per client, etc). |
| Google Account ↔ Billing Accounts | n : n | A user can admin multiple billing accounts. |
Billing Account
A billing account holds a payment method (credit card or invoice) and is linked to projects to fund their usage.
- Lives inside an org, or standalone for personal use.
- A project without a billing account cannot use paid services.
- You can have multiple billing accounts under one org.
IAM Model
GCP IAM is resource-centric and additive:
- Bindings are set on a resource (org, folder, project, or individual resource).
- Permissions inherit downward — a binding on the org applies to all folders and projects below it.
- No explicit deny by default —
IAM Denyis a separate, newer feature.
| Role type | When to use |
|---|---|
| Basic (Owner / Editor / Viewer) | Avoid — too broad |
| Predefined | Default choice — Google-managed, service-specific |
| Custom | When predefined is still too broad — least-privilege |
AWS / Azure → GCP Mental Map
| Concept | AWS | Azure | GCP |
|---|---|---|---|
| Hard tenancy boundary | Account | Subscription | Project |
| Hierarchy / grouping | OU (Organizations) | Management Group / RG | Org → Folder → Project |
| Workload identity | IAM Role | Managed Identity | Service Account |
| Permission grant | Policy on principal | Role assignment | IAM binding (role on resource → member) |
| Human SSO | IAM Identity Center | Entra ID | Cloud Identity / Workforce Identity |
| CLI | aws | az | gcloud / gsutil / bq |
| Named profiles | ~/.aws/config [profile x] | az account set | Named configurations |
| SDK auth (Terraform etc.) | AWS_PROFILE / env vars | az login (unified) | ADC (application-default login) — separate from CLI auth |