10.1 Creating VPCs, Subnets & Shared VPC

Why This Matters on the ACE Exam

"Deploying and implementing a cloud solution" is the single heaviest domain on the ACE exam guide at 25% of the exam — more than any other domain — and its networking sub-topic (3.5) is tested almost entirely through scenario questions: given a description of an organization's team structure and connectivity needs, choose the correct way to lay out a Virtual Private Cloud (VPC) network. Chapter 5 covered the planning decision (load balancer type, regional placement); this section covers the deployment mechanics the exam actually asks you to execute: how a VPC and its subnets get created, and when a single project's network is the wrong shape for the organization described in the question.

VPCs and Subnets: Global vs. Regional

A VPC network is a global, project-scoped resource — it has no single region and can span every Google Cloud region without a gateway or extra configuration. A subnet, by contrast, is a regional resource that lives inside a VPC and defines the actual IPv4 (and optionally IPv6) address range that instances in that region draw from. Every VM's internal IP comes from exactly one subnet, and resources in different subnets of the same VPC talk to each other over internal IPs by default — no peering, no NAT, no public internet involved.

Every new VPC is created in one of two subnet creation modes, chosen at creation time and impossible to change afterward:

The default VPC that ships with every new project is an auto mode network. The exam guide's own emphasis on "creating a VPC with subnets (e.g., custom mode VPC, Shared VPC)" signals that custom mode is the expected production answer whenever a scenario mentions IP planning, multiple regions with specific ranges, or avoiding address overlap with another network.

Command reference:

gcloud compute networks create my-vpc --subnet-mode=custom
gcloud compute networks subnets create my-subnet \
  --network=my-vpc --region=us-central1 --range=10.10.0.0/24

A critical, easy-to-miss trap: because auto mode subnets are hard-coded inside 10.128.0.0/9, Google's own documentation warns that you cannot connect an auto-mode VPC to an on-premises or peer network using VPC Network Peering or Cloud VPN if that other network already uses any address inside 10.128.0.0/9. Any scenario that mentions hybrid connectivity to an existing corporate network is a strong signal that the answer is a custom-mode VPC with deliberately chosen, non-overlapping ranges — not auto mode.

Subnets can also carry secondary IP ranges — additional CIDR blocks attached to a primary subnet range, most commonly used to reserve address space for GKE Pod IPs and Service (ClusterIP) IPs in a VPC-native cluster (covered further in Chapter 7). Planning secondary ranges at VPC-design time avoids having to rebuild a subnet later.

Shared VPC: One Network, Many Projects

Many exam scenarios describe an organization with multiple teams, each wanting its own project for billing and IAM isolation, but all needing to communicate over private IPs and be governed by one central networking team. The deployment answer is Shared VPC (formerly called XPN, cross-project networking):

• One project is designated the host project — it owns the VPC network and its subnets.
• Other projects become service projects — they run VMs, GKE clusters, and other resources, but those resources attach to subnets that live in the host project.
• A user needs the Shared VPC Admin role at the organization or folder level to designate a host project in the first place.
• The host project's network team grants the Compute Network User role (roles/compute.networkUser) to specific users, groups, or service accounts in each service project — and critically, that role can be scoped down to a single subnet, not the whole host VPC. This lets the central team hand a service project team access to exactly one region's subnet without exposing the rest of the network.

Exam Scenario

A retailer runs 12 microservice teams, each in its own GCP project for cost tracking and access isolation. All 12 need to call each other over private IPs, and the platform team wants to enforce firewall rules and IP allocation from one place. The correct deployment is: designate one host project, enable Shared VPC on it, attach all 12 as service projects, and grant each team's service account the Network User role scoped to its assigned subnet — not 12 separate VPCs peered together, and not one giant shared project holding every team's workloads.

Key Takeaways

• A VPC is global; a subnet is regional — every instance's internal IP comes from exactly one regional subnet.
• Auto mode pre-creates one /20 subnet per region from 10.128.0.0/9; custom mode requires you to define every subnet's region and CIDR range yourself, and is the production-grade choice.
• Auto-mode VPCs cannot be peered or VPN-connected to a network that already uses 10.128.0.0/9 addresses — a recurring exam trap.
• Shared VPC centralizes network ownership in one host project while service projects attach via the Network User role, which can be scoped to a single subnet.
• Secondary IP ranges on a subnet reserve address space in advance for uses like GKE Pod/Service IPs.