GCP approaches resource management differently than other cloud providers. In AWS, accounts are flat boundaries inside an Organization. In GCP, resources live within a strict parent-child tree: Organization → Folders → Projects → Resources.
Understanding this hierarchy is not just about organizing files — it governs IAM permission inheritance, organization policies, and billing linkages.
Topic 1: The Four Hierarchy Layers
- Organization Resource: The root node representing your corporate domain (e.g.,
company.com). It centralizes super-admin control, billing account administration, and Organization Policies (such as restricting public IPs or restricting location choices). - Folders: Logical groupings below the Organization (e.g.,
Engineering,Fintech-Platform,Production,Staging). Folders allow departmental or environment-level policy application and delegated administration. - Projects: The mandatory administrative boundary for all resources. Every VM, GCS bucket, GKE cluster, or BigQuery dataset MUST belong to exactly one project. Projects hold billing account linkages, API activation flags, and quota limits.
- Resources: The actual infrastructure assets (Compute Engine VMs, Persistent Disks, GKE Nodes, Cloud SQL instances).
# View the parent organization and folder of your active project
gcloud projects describe $(gcloud config get-value project) \
--format="yaml(projectId, projectNumber, parent, lifecycleState)"
Topic 2: Policy Inheritance & Permission Cascading
Permissions in GCP cascade downwards through the resource hierarchy:
- A permission granted at the Organization level applies to all Folders, Projects, and Resources below it.
- A permission granted at a Folder level applies to all child Projects and Resources inside that Folder.
- Parent policies are permissive: More permissive parent policies always overrule more restrictive child policies. If a user is granted
roles/storage.adminat the Folder level, granting a restrictive role at the Project level cannot revoke their storage admin access.
Topic 3: Critical Distinction: Labels vs. Network Tags
One of the most frequent operational confusions on GCP is confusing Labels with Network Tags. They serve completely different functions:
| Dimension | Labels | Network Tags |
|---|---|---|
| Format | Key-Value pairs (e.g., env=prod, owner=payments) | Simple string identifiers (e.g., target-web, allow-ssh) |
| Applicability | Almost all GCP resources (VMs, Buckets, Datasets, Disks) | VPC resources only (Compute Engine VMs, Instance Templates) |
| Primary Purpose | Resource organization, filtering, and BigQuery Billing Export | VPC Firewall Rules application and route targeting |
| Affects Traffic? | No — purely administrative metadata | Yes — dictates which firewall rules apply to a VM |
# Add a Label for cost tracking & FinOps attribution
gcloud compute instances add-labels web-vm-01 \
--zone=us-central1-a \
--labels=environment=production,team=checkout,cost-center=cc-402
# Add a Network Tag to apply a VPC firewall rule allowing HTTP traffic
gcloud compute instances add-tags web-vm-01 \
--zone=us-central1-a \
--tags=target-web-server,allow-health-check
Topic 4: Project Quotas & Billing Accounts
- Project ID vs Project Number: The Project ID is a globally unique string chosen at creation (
fintech-prod-api-402); the Project Number is an auto-assigned numeric identifier (847291039281). - Quota Management: GCP limits the number of resources (e.g., maximum vCPUs per region, external IP addresses, subnets) per project to prevent unexpected billing spikes or platform abuse. Quotas can be increased by submitting support requests in the GCP Console or CLI.
Common mistake: Creating projects flat under the organisation because folders feel like overhead. IAM inherits downward, so with no folder layer every policy is either granted per project — a hundred places to change — or at the org root, where it reaches everything. The hierarchy is far cheaper to design before there are eighty projects than after.