Creating a resource hierarchy

A Google Cloud resource hierarchy is the tree that every other control in the platform hangs from. At the root sits the Organization node, beneath it any number of Folders nested up to ten levels deep, and at the leaves the Projects that hold workloads. Resources (VMs, buckets, datasets, clusters) belong to exactly one Project, and every node in the tree carries its own IAM policy, its own Organization Policy constraints, and its own audit log destination. When you change a binding at a Folder, every Project beneath it inherits the change. The hierarchy is therefore the first place you defend a blast radius: a misplaced grant at the Organization node hands access to every workload the company runs, while the same grant at a Project node touches one workload only.

The Organization node is created implicitly the moment a Cloud Identity or Google Workspace tenant is provisioned against a verified DNS domain. You do not run a command to make an Organization; you sign up for Cloud Identity, prove ownership of acme-glide.example, and the Organization appears in the Cloud Console with an organizationId numeric identifier. That identifier is permanent and is referenced in every gcloud organizations command. The Organization Administrator role (roles/resourcemanager.organizationAdmin) is the seed role that lets a human grant other roles below the Organization; assign it to a Cloud Identity group, never to a personal user account, so the role survives turnover.

Folders give you a place to model the company's reality without coupling that reality to a Project. The two patterns the exam tests are organizational hierarchy (Folders by business unit or team, for example payments, risk, mobile) and environment hierarchy (Folders by lifecycle stage, for example prod, nonprod, sandbox). The decision driver is which axis carries the policy most often: if security policy and budget per environment differ more than policy per team, build the environment hierarchy first and nest team folders inside; if compliance scope per team differs more than per environment, build the team hierarchy first. Folders can be nested ten levels deep, which is enough for any realistic structure but not unlimited.

Projects are the unit of isolation, billing, and quota. Every API call, every IAM grant a service account uses, every quota counter, and every Cloud Billing usage line item is attributed to exactly one Project. A Project carries a globally unique projectId (six to thirty characters, lowercase, immutable once chosen), a projectNumber (numeric, auto-assigned, immutable), and a mutable projectName for display. Workloads should sit in a Project that matches one team and one environment, never both production and staging in the same Project, and never two unrelated teams sharing a Project just because they share a billing account.

Building the Hierarchy with gcloud

The full sequence to scaffold the hierarchy is shown below. Run these commands from a Cloud Shell session authenticated as a user holding roles/resourcemanager.organizationAdmin.

# Capture the Organization ID for reuse
export ORG_ID=$(gcloud organizations list \
 --filter="displayName=acme-glide.example" \
 --format="value(ID)")

# Create the top-level environment folders
gcloud resource-manager folders create \
 --display-name="prod" \
 --organization=${ORG_ID}

gcloud resource-manager folders create \
 --display-name="nonprod" \
 --organization=${ORG_ID}

# Capture the prod folder ID
export PROD_FOLDER=$(gcloud resource-manager folders list \
 --organization=${ORG_ID} \
 --filter="displayName=prod" \
 --format="value(ID)")

# Nest a team folder under prod
gcloud resource-manager folders create \
 --display-name="payments" \
 --folder=${PROD_FOLDER}

# Create a project under the payments folder
export PAYMENTS_FOLDER=$(gcloud resource-manager folders list \
 --folder=${PROD_FOLDER} \
 --filter="displayName=payments" \
 --format="value(ID)")

gcloud projects create acme-pay-prod-001 \
 --name="Payments Production" \
 --folder=${PAYMENTS_FOLDER}

Every project inherits the IAM policy and Organization Policy constraints of the folders above it, which is why placement is the first design choice you make. Moving a project from one folder to another is supported, but the move triggers re-evaluation of every inherited binding and constraint, and IAM Conditions that reference the previous folder path break silently.

Setting up Cloud Networking

Once Projects exist, networking is the next layer. A Virtual Private Cloud (VPC) network is a global Google Cloud resource that lives inside a Project; its subnets are regional and carry primary IPv4 ranges plus optional secondary ranges for alias IPs and Google Kubernetes Engine (GKE) pods. Two creation modes exist: auto-mode, which auto-provisions a subnet in every region with predefined ranges, and custom-mode, which leaves the operator to declare each subnet explicitly. Production designs almost always use custom mode because auto mode's predefined ranges collide with on-premises CIDR ranges and force later renumbering.

The minimal pattern is one VPC per environment, with subnets sized for the workloads in each region. For a multi-team Organization, Shared VPC centralizes a single host project's VPC and lets multiple service projects attach workloads to it; this lets a central platform team own routing and firewall policy while application teams own only their workloads' projects. The host project must be inside the same Organization as the service projects.

# Create a custom-mode VPC in a host project
gcloud compute networks create acme-shared-vpc \
 --project=acme-net-host-prod-001 \
 --subnet-mode=custom \
 --bgp-routing-mode=regional

# Add two regional subnets
gcloud compute networks subnets create payments-usc1 \
 --project=acme-net-host-prod-001 \
 --network=acme-shared-vpc \
 --region=us-central1 \
 --range=10.10.0.0/20 \
 --secondary-range=gke-pods=10.20.0.0/14,gke-svc=10.24.0.0/20 \
 --enable-private-ip-google-access

gcloud compute networks subnets create payments-euw4 \
 --project=acme-net-host-prod-001 \
 --network=acme-shared-vpc \
 --region=europe-west4 \
 --range=10.11.0.0/20 \
 --enable-private-ip-google-access

# Promote the project to a Shared VPC host
gcloud compute shared-vpc enable acme-net-host-prod-001

# Attach a service project
gcloud compute shared-vpc associated-projects add \
 acme-pay-prod-001 \
 --host-project=acme-net-host-prod-001

Subnet primary ranges cannot overlap inside a VPC. Secondary ranges back GKE alias IPs and must be planned at the same time as the cluster, because expansion later is non-disruptive but requires the new range to be contiguous to the existing one only when expansion uses gcloud compute networks subnets expand-ip-range. Private Google Access is the per-subnet switch that lets instances without external IPs reach Google APIs via Google's edge network; it is the default for any production subnet.

💡 Exam Trap: Folders cap at ten levels of nesting, but the hierarchy depth that really hurts is when policy inheritance has to be traced. A binding at the Organization plus a deny rule at a Folder three levels down plus a Conditional binding at the Project produces an effective policy you cannot read by eye. The exam tests the precedence order: Organization Policy denies override allows; IAM Deny policies override IAM Allow policies; everything else inherits additively from parent to child.

📊 Limit: A Cloud Billing account is hard-capped at 1,000 directly linked projects by default. A Project can be moved between Folders, but the operation is gcloud projects move, requires roles/resourcemanager.projectMover on both source and destination parents, and does not move the project's resources to a new region.

⚠️ Anti-Pattern: Creating a flat hierarchy of all Projects directly under the Organization node and then bolting Folders on later. Moving Projects en masse triggers re-evaluation of every inherited policy, every IAM Conditional binding that referenced the old path silently stops matching, and Organization Policy violations that were masked at the Organization level become hard failures the moment a constraint applies at a Folder you just added.

🎯 Scenario: A platform team inherits a sandbox tenant where the previous owner created sixty Projects directly under the Organization, all linked to one Billing account. The team needs to introduce a prod and nonprod Folder split with budget alerts per environment. The correct sequence is to create the two Folders, run gcloud projects move on each Project into the correct Folder (Billing account remains attached), then attach Organization Policy at each Folder. The wrong sequence is to leave Projects flat and attempt to filter budgets by Project ID, because that scales linearly and breaks every time a Project is added.

Decision Anchor: Choose a custom-mode VPC when you need predictable CIDR planning, integration with on-premises ranges, or alias IP support for GKE. Choose auto-mode VPC only for short-lived sandboxes where the predefined ranges are not going to collide with anything you care about.