I85PREP
⌘ K
GCP Network Engineer study materials
GCP Network Engineer study resources

GCP Network Engineer: Design and plan a Google Cloud Virtual Private Cloud (VPC) network

GCP Network Engineer · Work through your exam, one topic at a time.

All guide sections

Design and plan a Google Cloud Virtual Private Cloud (VPC) network

This domain tests whether you can turn workload, security, and connectivity requirements into a global VPC design before deploying resources. Include DNS, logging, and hybrid reachability early, because retrofitting CIDRs is expensive and disruptive. Questions focus on CIDR planning, subnet scope, Shared VPC, peering limits, and service dependencies.

Core rules

  • A VPC network is global, but subnets are regional. A VM uses a subnet in its own region; firewall rules and routes are network-wide.
  • Auto mode creates one /20 subnet per region from 10.128.0.0/9. Custom mode is preferred when you must avoid overlap with on-premises or other clouds.
  • Reserve primary ranges for nodes and secondary alias ranges for GKE pods and services. Secondary ranges must not overlap any other subnet or peering range.
  • Shared VPC centralizes the network in a host project. Service projects attach, and IAM grants subnet-level use. Billing and quotas stay with the project that owns each resource.
  • VPC peering is non-transitive. If A peers with B and B peers with C, A cannot reach C through B. Plan hub-and-spoke with explicit peering or Network Connectivity Center instead.
  • Private Google Access is enabled per subnet and lets VMs without external IPs reach Google APIs and services.

Worked example

Plan two regional subnets for GKE and on-premises reachability. Use us-central1 primary 10.0.0.0/20, pods 10.16.0.0/14, services 10.32.0.0/20. Use europe-west1 primary 10.0.16.0/20, pods 10.20.0.0/14, services 10.33.0.0/20. On-premises uses 192.168.0.0/16, so no range overlaps. The /20 primary supports about 4,000 addresses; the /14 pod range supports roughly 262,000 pod IPs. Check that the pod and service ranges do not overlap the other region or the peered on-premises range.

Traps

  • Assuming a subnet can span regions.
  • Choosing auto mode and later colliding with 10.128.0.0/9 on-premises.
  • Forgetting GKE secondary ranges, then running out of pod IPs.
  • Treating VPC peering as transitive.
  • Enabling Private Google Access at the VPC level when it is a subnet setting.
  • Reserving pod ranges that are too small for node autoscaling.