Google PCNE: Routing, Network Connectivity Center and Segmentation — 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

This section explains routing, Network Connectivity Center (NCC), and segmentation patterns in Google Cloud. It focuses on how routes are created and selected, how to interconnect VPCs and organizations while preserving isolation, how to build scalable transit and service-insertion designs, and how to validate and contain failures.

Routing fundamentals and control

• Route types

  • System-generated subnet routes: One per primary and secondary subnet range; always most preferred for their exact prefixes.
  • Default route to the internet gateway: Automatically created in new VPCs; can be removed or overridden.
  • Static routes: Custom prefixes with next hops such as default internet gateway, a specific instance, an internal TCP/UDP load balancer (ILB) as next hop, or a Cloud VPN tunnel. Policy-based routes add match conditions (tags, service accounts, protocol/port) and steer to an instance or ILB next hop for advanced service insertion.
  • Dynamic routes: Learned via Cloud Router over BGP from Cloud VPN or Cloud Interconnect. Their scope is controlled by the VPC’s dynamic routing mode (regional or global).

• Route selection

  • Longest prefix match first.
  • If multiple routes have the same prefix length, the lowest numerical route priority wins (default 1000 for custom routes). Avoid equal-prefix overlaps across static/dynamic paths; design to prefer one unambiguously.
  • Ties beyond priority resolve via platform-internal tie-breakers; do not rely on them.

• Next-hop choices and service insertion

  • To centralize egress or insert L3/L7 services, point a 0.0.0.0/0 static route or policy-based routes to an ILB next hop whose backends are network virtual appliances (NVAs).
  • When appliances must be bypassed for Google APIs by instances without external IPs, enable Private Google Access on the subnets and add custom static routes for the published Google APIs VIP ranges to the default internet gateway. This preserves private access to Google services while other egress follows the NGFW path.

• Dynamic routing mode and multi-region behavior

  • Regional: Routes learned by a Cloud Router are installed for subnets in the same region only.
  • Global: Routes learned anywhere are installed for all regions in the VPC, enabling simple multi-region connectivity and reduced operational overhead for hub-and-spoke designs. For users and workloads near us-east1 and europe-west1, a single VPC with regional subnets and global dynamic routing lets them communicate privately over RFC1918 with optimal efficiency.

• Route advertisement control

  • Cloud Router can advertise all subnets or a custom set of prefixes (including a default route) to on-premises. Control inbound-on-prem path selection using standard BGP tools (MED, AS-path prepending, local preference on-prem). For active/standby toward on-prem, set a lower MED on the primary path and higher MED on the standby.
  • Avoid advertising the same prefix from different on-prem peers with different ASNs to the same Cloud Router; for dual-homed ECMP or clean failover, use the same peer ASN on redundant on-prem routers.

VPC interconnectivity and segmentation

• VPC Network Peering

  • Enables private RFC1918 connectivity across VPCs with low latency and no data-plane appliances. It exchanges subnet routes by default and can optionally import/export custom routes (static and dynamic) to extend reachability to resources behind Cloud VPN/Interconnect. There is no transitive routing: routes learned from a peer are not re-exported to another peer.
  • Failure modes and limits: No overlapping CIDRs; firewall rules remain independent per VPC; bandwidth is high but not a substitute for load balancers; asymmetric routing across mesh peering is not supported. To connect three VPCs in a triangle, configure a full mesh of peering pairs; Sales↔Finance and Marketing↔Finance do not enable Sales↔Marketing unless that pair is also peered.
  • Address planning: When peering an auto-mode VPC (which reserves 10.128.0.0/9), create the peer as custom mode with a non-overlapping CIDR such as 10.0.0.0/9.

• Shared VPC and multi-project connectivity

  • A host project owns the VPC; service projects attach to selected subnets. This centralizes networking and hybrid connectivity (Cloud Routers, Cloud NAT, Interconnect) while enabling delegated application ownership per project. Place VLAN attachments and Cloud Routers for Dedicated Interconnect in the host project to provide cost-efficient, centralized on-prem connectivity to all service projects.
  • Least privilege: Network Admins manage routing and subnets; Security Admins manage firewall rules and policies. If you cannot update firewalls with Network Admin, request Security Admin in the Shared VPC scope.
  • Segmentation: Share only the specific subnets required by a service project. This aligns with Google best practices to tightly control route exposure between Production and Staging.

• Network isolation controls

  • VPC boundaries: No routing between VPCs without explicit peering, VPN, or Private Service Connect. Use separate VPCs for departments or tenants that must be fully isolated; peer only those that need connectivity to minimize operational overhead.
  • Firewall policies: Use hierarchical firewall policies at the organization/folder level for consistent guardrails and per-VPC rules for local exceptions. Default ingress deny/egress allow can be tightened.
  • Perimeters: Use VPC Service Controls to restrict access to Google APIs and mitigate data exfiltration risks across projects and networks.
  • IPv6 exposure: For public IPv6 access, assign IPv6 to a global external HTTP(S) load balancer fronting your service. Backends remain private.

Network Connectivity Center and transit architectures

• NCC hub-and-spoke

  • The hub provides a control-plane for routing between spokes. Spokes include VLAN attachments (Interconnect), HA VPN tunnels, router appliance spokes, and supported VPC spokes for site-to-site data transfer. NCC route tables control which prefixes are imported/exported and which spokes receive them, enabling precise segmentation.
  • Site-to-site data transfer lets on-prem sites reach each other via Google’s backbone using the hub as transit, reducing the need for third-party transit and simplifying operations.

• Router appliance spokes and third-party NVAs

  • Router appliance spokes onboard virtual routers/firewalls hosted on Compute Engine as transit or inline services. Use ILB as next hop to achieve scale and health-checked failover across multiple appliances.
  • HA design: Deploy at least two appliances in different zones; place them behind an ILB with a MIG where possible; enable IP forwarding on instances; use symmetric steering with ILB next hop; distribute load using policy-based routes based on tags or service accounts.
  • Throughput and failure trade-offs: NVAs are limited by instance type and NIC bandwidth; plan for horizontal scale. Appliance failure or health check failure triggers ILB removal and fast failover, but ensure route convergence timers and health thresholds are tuned to avoid flaps.

• Transit topology trade-offs

  • Hub-and-spoke with NCC: Central policy, high scalability, clear blast-radius control; requires route-table design and import/export intent.
  • Full mesh peering: Simple for a small number of VPCs, no central transit, but scales poorly and cannot provide transitivity or service insertion.
  • Centralized egress: Simple security enforcement via one NGFW or NAT; may add latency and become a choke point; mitigate with regional egress points and autoscaling.
  • Mesh VPN with Cloud Routers: Flexible and quick to deploy; operational overhead rises with peer count; consider NCC to consolidate.

• Cloud VPN considerations

  • If the on-prem device lacks BGP, use policy-based Cloud VPN with static routes and carefully scoped traffic selectors; plan eventual migration to HA VPN with BGP to minimize long-term overhead.
  • For active/standby tunnels toward on-prem, manipulate MED or AS-path on-prem. For dual on-prem routers connecting to a single Cloud Router, prefer identical peer ASNs to allow installation of both paths and ECMP; using different peer ASNs commonly results in only one path being selected.

Operations: validation, analysis, and outage containment

• Connectivity validation and route analysis

  • Use Network Intelligence Center’s Connectivity Tests to trace data path across VMs, load balancers, VPC peering, Cloud VPN, and Interconnect, validating firewall rules and routes.
  • Analyze effective routes per VM/subnet to confirm next hops and dynamic prefixes; verify dynamic routing mode scope aligns with intent.
  • For performance or user-experience issues, prefer global HTTP(S) load balancing to reduce latency for worldwide users through anycast ingress and edge termination; network load balancers are regional and do not improve global latency.

• Outage containment and blast radius reduction

  • Segment by VPCs, NCC route tables, and per-project Shared VPC subnets to prevent unintended propagation of failures or misconfigurations.
  • Avoid transitive dependencies via peering; where transit is required, use NCC and controlled import/export to constrain reachability.
  • Use centralized org-level firewall policies for baseline deny/allow and local policies for application exceptions; test changes with Connectivity Tests.
  • Where inline security is required, deploy next-hop ILB with health checks and policy-based routing for graceful failover. Ensure critical Google APIs are reachable via Private Google Access or Cloud NAT without relying on external IPs.
  • Monitor BGP sessions and route changes; standardize metrics (MED, local preference) and address plans to avoid route oscillation and asymmetric flows.

• Short configuration examples

  • Create a static route to steer traffic through an inline ILB:
    • gcloud compute routes create egress-via-ngfw –network my-vpc –destination-range 0.0.0.0/0 –next-hop-ilb ngfw-ilb –priority 900
  • Prefer one of two BGP paths inbound to on-prem using MED (on-prem router):
    • route-map FROM_GCP permit 10
    • set metric 20
    • router bgp 65000
    • neighbor 169.254.x.y route-map FROM_GCP in

Practical Problem Scenario

Acme Retail operates in a multi-project Google Cloud organization with two user populations near us-east1 and europe-west1. They need private, low-cost communication between workloads across regions, centralized on-prem connectivity, and inline URL filtering for internet egress, while keeping Finance isolated from Engineering.

1. Build a single Shared VPC in a host project with regional subnets in us-east1 and europe-west1, and set dynamic routing mode to global.

• Rationale: One VPC enables direct RFC1918 communication between regions with no peering overhead. Global dynamic routing installs learned hybrid routes across all regions, simplifying operations and ensuring efficient intra-VPC flows.

2. Share only the required subnets to each service project; place Finance and Engineering in separate service projects.

• Rationale: Subnet-level sharing provides organizational segmentation and minimizes unintended route exposure. Finance remains isolated by simply not sharing Engineering subnets and by separate firewall policy scopes.

3. Terminate Dedicated Interconnect in the host project and attach Cloud Routers; advertise only necessary prefixes using custom advertisements.

• Rationale: Centralized hybrid connectivity reduces cost and complexity while keeping control of what reaches on-prem. Custom advertisements prevent overexposure and contain blast radius.

4. Insert an inline L7 URL filtering appliance behind a regional internal TCP/UDP load balancer; steer egress with a 0.0.0.0/0 static route to the ILB next hop in each region.

• Rationale: ILB next hop plus health checks provides HA service insertion with symmetric flows across appliances. Static routes with higher priority than the default ensure all egress is filtered.

5. Ensure instances without external IPs can reach Google APIs directly: enable Private Google Access on all subnets and add static routes for Google APIs VIP ranges to the default internet gateway to bypass the appliance.

• Rationale: Private Google Access preserves private access to BigQuery and Pub/Sub; custom routes prevent unnecessary hairpinning through the filter, reducing cost and latency.

6. Keep Finance isolated: deny inter-project traffic in hierarchical firewall policies and do not configure peering between Finance and Engineering. Where Engineering↔Analytics collaboration is needed, create a dedicated peered VPC pair with non-overlapping CIDRs.

• Rationale: VPC boundaries, absence of peering, and org-level firewall policies enforce isolation. Targeted peering offers low operational overhead for specific departmental connectivity without transitivity.

7. Validate and monitor: use Connectivity Tests to verify inter-region reachability and appliance insertion; monitor Cloud Router BGP health and route tables; implement MED on on-prem routers for active/standby failover if multiple tunnels exist.

• Rationale: Proactive validation detects misconfigurations early. BGP controls keep on-prem paths deterministic during maintenance or failures, while NCC/Cloud Router telemetry accelerates troubleshooting.

This design meets Acme Retail’s requirements with minimal cost and high efficiency: private multi-region routing in one VPC, centralized hybrid connectivity, controlled service insertion, and strong organizational segmentation.

← Private Connectivity to Google and Managed Services · All domains · GKE →

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

Browse Google →