Google PCNE: VPC Architecture, Subnets and Address Planning — Study Guide

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Part of the Google Professional Cloud Network Engineer — Study Guide. Practice with verified answers in the Google exam hub, or take timed practice tests on ExamRoll.io.

Overview

A Virtual Private Cloud (VPC) is a global, logically isolated network that spans all Google Cloud regions. Subnets are regional constructs within a VPC and host IP ranges that back Compute Engine, GKE, and other resources. A sound VPC architecture balances address efficiency, growth, and operational control, while ensuring low-latency, cost-effective connectivity for intra- and inter-project workloads and to Google APIs.

VPC scope, subnet architecture, and modes

• Global VPC, regional subnets

  • A single VPC spans all regions. Subnets are created per region and define primary IPv4 CIDRs and optional secondary ranges. Instances receive IPs from regional subnets but can privately communicate across regions within the same VPC by default.
  • Dynamic routing mode
    • Regional: Cloud Routers exchange routes only with subnets in their region.
    • Global: Cloud Routers in one region advertise learned routes to all regions. Prefer global when multi-regional workloads or HA egress are required.

• Auto mode vs custom mode

  • Auto mode creates one subnet per region with preassigned CIDRs. It’s convenient for quick starts but inflexible at scale. It can be converted to custom mode; conversion is one-way.
  • Custom mode provides full control over subnet creation and CIDR choices. This is the recommended pattern for production address planning, Shared VPC, peering, and growth.
  • Migration note: After converting auto to custom, artifacts or templates that assumed auto subnets often fail until explicitly updated to reference custom subnets.

• Subnet immutability and growth

  • Subnet region is immutable; you cannot move a subnet between regions.
  • Primary IPv4 ranges can be expanded in place (widened prefix), cannot be shrunk, and must remain non-overlapping across the VPC and any connected networks.
  • Secondary ranges can be added or removed (subject to use), but must also be non-overlapping.

Address planning: primary/secondary ranges, alias IPs, IPv6, and private space

• Primary and secondary IPv4 ranges

  • Primary range: assigns VM interface addresses (nic0 by default). It creates a system-generated subnet route and is used for most internal communication.
  • Secondary ranges: associate additional CIDRs with the subnet and are required for VPC-native GKE clusters. System-generated routes for secondary ranges allow east-west connectivity for Pods and Services.

• Alias IPs

  • Alias IPs let a VM NIC own multiple IPs from the subnet’s primary or secondary ranges, enabling tight IP-based policy, Pod IPs for VPC-native GKE, and efficient IP utilization.
  • For GKE, plan large continuous secondary CIDRs to minimize fragmentation and future resizing. Example: for 100 nodes with 200 Pods/node and 1500 Services, allocate Pod secondary of at least /17 and Services /21 to leave headroom.

• Private RFC 1918 design and IP management

  • Choose non-overlapping blocks across all current and planned VPCs, on-premises, and partners. Reserve large parent blocks for each environment, then carve predictable sub-blocks per region and per function.
  • Reserve capacity for growth, secondary ranges, migration buffers (temporary dual-stack/double NAT), and infrastructure endpoints (ILB VIPs, PSC endpoints).
  • Avoid the most common enterprise blocks if partner connectivity is likely; or segment with NAT to deconflict.

• IPv6 planning

  • External IPv6: use global external IPv6 addresses on global load balancers for client access and anycast reachability.
  • Internal IPv6: where available, enable dual-stack subnets to assign internal IPv6 to VMs and adjust firewall rules accordingly. Plan DNS AAAA records and ensure parity with IPv4 policy.
  • Retain IPv4 for intra-cloud controls and third-party integrations; introduce IPv6 incrementally through load balancers and dual-stack subnets.

Routing: implied routes, custom routes, priorities, tags, and next hops

• Implied (system-generated) routes

  • Subnet routes: one per primary subnet and per secondary range, destination equals the CIDR, next hop is the subnet itself.
  • Default route: 0.0.0.0/0 to the default internet gateway is created by default; egress to the internet requires an external IP or NAT.

• Custom routes and selection logic

  • Longest prefix match wins. If multiple routes have the same prefix length, the lowest priority number wins (default priority 1000).
  • Tags and service accounts
    • Routes without tags apply to all VMs. Tag-scoped routes apply only to instances with matching network tags.
    • Identity-based firewall rules can match service accounts; use them for finer control than tags where possible.

• Next hops

  • Supported next hops for custom routes include:
    • Default internet gateway (0.0.0.0/0 or more specific egress prefixes)
    • Instance (requires IP forwarding to route traffic for others; used for virtual appliances)
    • Cloud VPN tunnel (static routes)
    • Regional internal load balancer as next hop (for scalable appliance patterns)
  • You cannot set next hop to a VPC peering connection; peering handles its own route exchange.

• Traffic steering example (virtual appliance)

  • Create a more specific route than the subnet route with a next hop to an instance with IP forwarding, scoped by tags on source VMs.
  • Example:
    • gcloud compute routes create app-egress –network=prod-vpc –destination-range=0.0.0.0/0 –next-hop-instance=fw-appliance –next-hop-instance-zone=us-west1-a –priority=800 –tags=egress-via-fw

• Egress to Google APIs without external IPs

  • Option 1: Enable Private Google Access (PGA) on subnets, then add custom routes for Google API VIPs to the default internet gateway to bypass a third-party default egress path if necessary.
  • Option 2: Use Cloud NAT with PGA to provide egress for private VMs to Google services.
  • Option 3: Use Private Service Connect to Google APIs for internet-free consumption; traffic remains on Google’s network and uses a private RFC1918 endpoint in your VPC.
  • For restricted access, point clients to restricted Google API VIPs and enforce egress controls.

Shared VPC, peering, delegated administration, and service accounts

• Shared VPC

  • Host project owns one or more centrally managed VPCs and subnets. Service projects attach workloads to selected shared subnets.
  • Delegated administration
    • Shared VPC Admin configures attachments and subnet sharing.
    • Network Admins manage routes, subnets, and firewall in the host project.
    • Project-level IAM in service projects controls workload deployment; you can share only the required subnets to constrain blast radius and route visibility.
  • Service accounts
    • Prefer service account–based firewall policies for deterministic, identity-driven control across teams.
    • Use dedicated service accounts per tier and environment, with least-privilege roles for data access (for example, grant Storage Object Viewer to a service account that reads Cloud Storage).

• VPC Network Peering

  • Constraints
    • Non-transitive: A↔B and B↔C do not imply A↔C. Build a full mesh if needed.
    • No overlapping IP ranges across peered networks.
    • Exchange is limited to subnet routes (including secondary ranges); next-hop steering via peering is not supported.
  • Use peering for low-latency, private, intra-organization connectivity with minimal ops overhead when separate VPCs must remain administratively distinct.

• Hybrid connectivity

  • Centralize Dedicated Interconnect and Cloud Router in a Shared VPC host project to share high-capacity connectivity with departments’ service projects.
  • Use HA VLAN attachments, diverse edge locations, dual Cloud Routers, and global dynamic routing for resilience and propagation to all needed regions.

Operations: expansion, HA, private access, verification, and troubleshooting

• Subnet expansion and migration constraints

  • Expand in place when a subnet nears capacity; validate all connected networks for non-overlap and ensure dependent GKE secondary ranges remain adequate.
  • If ranges overlap across organizations or partners, employ NAT or staged renumbering. You cannot peer overlapping VPCs or install overlapping dynamic routes.

• Regional placement and high availability

  • Place subnets in regions closest to users and data. For cross-Atlantic user bases, a single VPC with regional subnets in us-east1 and europe-west1 provides direct private connectivity with optimal latency and zero egress charge inside the VPC.
  • Distribute workloads across zones; use regional managed instance groups and regional internal/external load balancers for zone failure tolerance.
  • For hybrid, deploy dual Cloud Routers and attachments per region or edge location; enable BFD where supported; use global dynamic routing for failover.

• Private Google access and restricted endpoints

  • Enable PGA on subnets hosting instances without external IPs.
  • To prevent general internet egress while allowing Google APIs:
    • Route default traffic to your NGFW.
    • Add more-specific static routes for Google API VIPs to the default internet gateway or deploy PSC endpoints to Google APIs.
  • Example:
    • gcloud compute networks subnets update app-subnet –region=us-central1 –enable-private-ip-google-access

• Topology verification and troubleshooting

  • Use Network Intelligence Center:
    • Connectivity Tests to validate reachability and simulate routing, firewall, and gateway decisions.
    • Performance Dashboard and Topology to visualize paths and health.
  • Logs and telemetry:
    • VPC Flow Logs to observe allow/deny and latency per interface.
    • Firewall Rules Logging to confirm rule matches.
    • Cloud NAT logs and health for egress issues without external IPs.
    • Load balancer and health-check logs for backend readiness.
  • CLI checks:
    • gcloud compute routes list and gcloud compute firewall-rules list to confirm effective policy.
    • traceroute and curl from test VMs; use packet mirroring for deep inspection when needed.

Practical Problem Scenario

Acme Retail Group needs a multi-region, low-latency Google Cloud network with centralized control, internet-free access to Google APIs for private instances, and strict isolation between departments that don’t need to communicate. Some teams run GKE with heavy Pod density. Acme also steers general egress through a third-party firewall but wants Google API traffic to avoid the firewall.

1. Build a single Shared VPC in a host project in custom mode with global dynamic routing, and create regional subnets in us-east1 and europe-west1 with reserved secondary ranges for GKE.

• Rationale: One VPC provides private, zero-cost, cross-region connectivity over RFC1918 addresses for optimal efficiency. Custom mode and global dynamic routing support precise IP planning and multi-region route propagation.

2. Share only the specific subnets needed with each department’s service project; create three service projects (Sales, Finance, Marketing) and expose only the required subnets to each.

• Rationale: Per-subnet sharing limits blast radius and route exposure, enforcing isolation while enabling central operations. Delegated IAM lets central network admins manage firewalls and routes, while app teams deploy workloads independently.

3. For departments that must communicate, peer their dedicated VPCs or place them in the same Shared VPC subnets; for isolated departments, refrain from peering and do not share overlapping subnets.

• Rationale: Peering provides low-latency private connectivity with minimal ops overhead. Non-transitivity requires explicit mesh connections only where needed, which preserves isolation by default.

4. Enable Private Google Access on all shared subnets and deploy Private Service Connect endpoints to Google APIs; retain the default route to a third-party firewall, plus add more-specific static routes for Google API VIPs to the default internet gateway.

• Rationale: PGA and PSC provide internet-free API consumption from private VMs. The more-specific routes ensure API traffic bypasses the NGFW while non-Google internet egress continues through the inspection path.

5. Allocate primary and secondary CIDRs with growth headroom: for GKE, size a Pod secondary (for example, /17) and a Services secondary (/21) per busy region; use alias IPs for Pods and Services and create VPC-native clusters bound to those ranges.

• Rationale: Secondary ranges and alias IPs prevent node IP depletion and allow dense scheduling. Sizing for future demand avoids disruptive resizing and secondary range renumbering.

6. Implement HA for hybrid and appliance traffic: deploy dual Cloud Routers and HA VPN or Interconnect as needed; where steering through a virtual appliance is required, use a more-specific custom route with next hop set to a regional internal load balancer or an instance with IP forwarding and tag-scoped applicability.

• Rationale: HA at the edge ensures continuity during failures. Route scoping by tags avoids accidental traffic hairpinning and lets only selected instances traverse the appliance path.

7. Verify and operate with Network Intelligence Center Connectivity Tests, VPC Flow Logs, and Firewall Rules Logging; enforce identity-based firewall policies using service accounts and maintain IPAM records with reserved buffers per region and function.

• Rationale: Proactive verification prevents outages during changes. Identity-based policies are more robust than tag-only approaches. IPAM discipline prevents overlap that would block peering or suppress learned routes.

All domains · Firewall Policy →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Google →