Google PCA: Networking, Hybrid Connectivity and Traffic Architecture — Study Guide

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Overview

Networking, hybrid connectivity, and traffic architecture on Google Cloud revolve around secure, scalable Virtual Private Cloud (VPC) design; reliable hybrid interconnects; intelligent traffic management; and robust observability. The objective is to deliver low-latency, resilient services with clear segmentation, controlled egress, and predictable failure modes. This section outlines practical design patterns, trade-offs, and operational guidance across core Google Cloud networking services.

VPC Architecture and Segmentation

• Address planning and subnets

  • Use custom-mode VPCs to control subnet creation and IP addressing. Avoid default VPCs in production.
  • Allocate non-overlapping RFC1918 blocks early. Consider future growth, high-availability topologies, and hybrid extensions. Reserve ranges for services (for example, Private Service Connect endpoints) and for peering/Interconnect.
  • Prefer smaller, per-function or per-environment subnets over large flat networks to minimize failure blast radius and simplify firewalling.

• Routes

  • Each VPC has a system route table; routes are evaluated by longest-prefix match then priority. Google-managed routes include default internet route if external IPs exist, and subnet routes. Dynamic routes are exchanged with on-premises via Cloud Router.
  • Use custom static routes sparingly; rely on dynamic routing where possible for resilience. Avoid blackhole routes except as a deliberate control.

• Firewall rules

  • VPC firewall is stateful and evaluated by priority, with implied deny at the end. Target by network tags or service accounts; service account targeting offers stronger identity guarantees than tags.
  • Separate allow rules by purpose (health checks, intra-tier, admin) and scope them to source service accounts or IP ranges.
  • Log firewall decisions for critical rules to Cloud Logging to aid forensics and performance analysis.

• Hierarchical firewall policies and organization policies

  • Hierarchical firewall policies apply at organization or folder level and are evaluated before VPC-level rules. Use them to set global guardrails (for example, deny 0.0.0.0/0 SSH) that projects cannot override. Pre- and post-policies provide flexibility, but denies at higher levels cannot be superseded.
  • Complement with Organization Policy constraints (for example, restrict external IP creation, disallow VPC peering creation by projects) to enforce governance.

• Shared VPC and segmentation

  • Use Shared VPC to centralize networking in Host Projects while isolating workloads in Service Projects. This pattern reduces duplicate egress paths, standardizes controls, and simplifies hybrid transit.
  • Isolate environments (prod, non-prod) in separate Host Projects or folders; enforce segmentation with hierarchical policies and separate subnets. Restrict IAM so only NetOps teams manage Host Project resources.

• VPC Network Peering

  • Peering is private, scalable, and low-latency but non-transitive. It is best for connecting autonomous networks or third-party managed services. Avoid building transit hubs with peering; use Network Connectivity Center for transit or a centralized Shared VPC.
  • Limitations: no overlapping IPs; certain routes (for example, default internet route) and some services are not propagated. Understand import/export of custom routes when designing.

Trade-offs and failure modes:

• Overlapping IP ranges block peering and hybrid route exchange; resolve with renumbering or NAT.
• Excessively permissive firewall rules or missing health check rules cause outages and hard-to-diagnose behavior.
• Static routes create brittle dependencies; prefer Cloud Router for failover.

Traffic Management, DNS, and Edge Security

• Cloud Load Balancing patterns

  • External HTTP(S) Load Balancer is global anycast with single anycast VIP, cross-region failover, path and host routing, and CDN/Armor integration. Use for internet-facing web and API workloads.
  • Internal HTTP(S) Load Balancer is regional, for service-to-service traffic within a VPC or via Private Service Connect.
  • External/Internal TCP/UDP Network Load Balancer is regional L4; use for non-HTTP protocols or where source IP preservation is required.
  • Backend services and Network Endpoint Groups (NEGs): use zonal instance group backends for VM pools; use zonal, regional, or serverless NEGs for GKE, hybrid backends, or Cloud Run. Create separate backend services per traffic class, health profile, or capacity policy. Example: serve old and new API versions under the same hostname by path routing to distinct backend services, keeping both deployable and independently scalable.

• Health checks and common pitfalls

  • Health checks must be allowed by firewall. For external HTTP(S) health checks, allow 130.211.0.0/22 and 35.191.0.0/16 to backends. A missing rule results in backends marked unhealthy and rapid VM restarts if autoscaling reacts to load balancer signals.
  • Align health check paths and ports with container readiness endpoints; set timeouts and thresholds to balance fast failover against false positives.

• DNS architecture

  • Use Cloud DNS for authoritative zones. Create private zones for internal names; create public zones for internet names.
  • Split-horizon DNS: serve different answers internally versus externally by creating separate public and private zones with identical names. This supports private service hostnames and public-facing records safely.
  • Forwarding and peering zones: integrate with on-premises DNS using DNS policies and server policies to forward queries for specific domains; use conditional forwarding to avoid recursion loops.
  • Service discovery: adopt consistent naming conventions per environment and service. For GKE, consider headless services with Cloud DNS, or map service endpoints via Internal HTTP(S) Load Balancer and private DNS names.

• Edge caching and protection

  • Cloud CDN offloads cacheable content at the edge, reducing origin latency and egress cost. Set cache keys, TTLs, and negative caching carefully; bypass caching for personalized or dynamic endpoints.
  • Cloud Armor provides WAF, rate limiting, and geo/IP-based access control. Attach security policies to load balancers; monitor rule hit logs. Use preconfigured rules for common CVEs, and custom signatures for application-specific threats.
  • TLS termination at the load balancer centralizes cert management; enable automatic certificate provisioning and managed renewals where possible.

Operational guidance:

• Versioned APIs: implement path- or host-based routing to separate backend services so each version rolls independently with blue-green or canary patterns.
• Use request headers and cookies for A/B testing via traffic steering policies; always validate that logging/metrics correlate to the correct backend identity.

Hybrid Connectivity, Private Access, and Transit

• Cloud Router and BGP

  • Cloud Router exchanges routes dynamically with on-premises via BGP for Cloud VPN tunnels and Interconnect attachments. Use global dynamic routing mode in the VPC when multi-region spoke connectivity is required.
  • Advertise only required prefixes; filter to prevent route leaks. Understand MED and priority interactions when designing primary/backup paths.

• Cloud VPN, Dedicated and Partner Interconnect

  • HA VPN provides SLA-backed, redundant tunnels over IPsec, supports dynamic routing via Cloud Router, and is suitable for production hybrid with moderate bandwidth needs.
  • Dedicated Interconnect provides physical 10/100 Gbps links in one or more locations; Partner Interconnect offers similar via a service provider. Use at least two diverse interconnects in separate metro locations or separate edge zones for high availability.
  • Redundant paths and failover: design active/active with BGP across two Cloud Routers per region and two on-prem routers; validate asymmetric routing tolerance. Test failover regularly; tune BFD timers and health thresholds for desired convergence.
  • Failure modes: MTU mismatch causes fragmentation and performance penalties; ensure jumbo frames end-to-end for Interconnect. Misconfigured route filters can blackhole subnets. Single-homed partner circuits are a common single point of failure.

• Cloud NAT, Private Google Access, and Private Service Connect

  • Cloud NAT enables egress to the internet for private VMs without external IPs. Size NAT IPs and port allocations for peak connections to avoid port exhaustion; enable logging for troubleshooting.
  • Private Google Access allows private VMs to reach Google APIs using internal IPs; enable on subnets for VM access and on GKE nodes for node-local API access. For on-prem clients, use Private Service Connect for Google APIs to expose private VIPs that front Google APIs.
  • Private Service Connect for producer/consumer services provides private, internal IP endpoints for cross-project or cross-organization service publishing; combine with private DNS to steer traffic without exposing networks.

• Network Connectivity Center (NCC) and transit

  • NCC enables hub-and-spoke topologies where spokes are VPCs, HA VPNs, or Interconnect attachments. Use a central hub to simplify route distribution and multi-VPC transit, especially across projects or organizations.
  • Prefer Shared VPC for intra-organization transit when governance permits; use NCC when you need flexible, multi-domain transit or SD-WAN integration.
  • Understand that VPC Peering is non-transitive; do not rely on it for transit. NCC or a centralized firewall/load balancer VPC forms the transit core.

Multi-region choices, latency, and egress costs:

• Place compute near users and near stateful backends to minimize RTT. External HTTP(S) Load Balancing provides global ingress with smart routing, but database replication latency and consistency remain application constraints.
• Cross-zone traffic incurs cost within a region; cross-region replication adds egress charges and latency. Use Cloud CDN to reduce internet egress and origin load, and keep chatty services co-located.
• For disaster recovery, weigh warm standby in another region against egress and operational complexity. Use global load balancing with failover policies and health checks spanning regions only when data plane and control plane can tolerate regional isolation.

Observability, Reliability Operations, and Controls

• Network observability

  • VPC Flow Logs: enable at the subnet level and tune sampling and metadata options. Use for traffic baselining, egress analysis, and threat hunting. Export to BigQuery for long-term analytics.
  • Firewall rules logging: enable on critical rules to capture allowed and denied traffic; correlate with flow logs to detect misconfigurations.
  • Connectivity Tests: model source-destination paths to validate reachability, route selection, and firewall evaluation. Integrate in CI/CD to detect drift before deployment.
  • Health dashboards: monitor load balancer backend health, Cloud NAT port utilization, Cloud Router BGP session status, and Interconnect utilization. Alert on deviations.

• Reliability patterns and common failure modes

  • Zonal resilience: distribute backends across at least two zones; use managed instance groups or multi-zonal GKE node pools. Validate that health checks and firewall tags apply to all zones.
  • Routing resilience: use global dynamic routing and multiple Cloud Routers for region-spanning connectivity. Test blackhole scenarios and ensure monitoring covers route withdrawals.
  • DNS resilience: deploy multiple name servers by default with Cloud DNS; for hybrid, ensure forwarders are redundant and avoid single points in on-prem resolvers. Prevent split-horizon misconfigurations that return unroutable answers from the wrong side.
  • Security at the edge: apply Cloud Armor rate limits to protect origin from floods; failure to do so can trigger autoscaling storms and cost spikes.

• Cost controls

  • Minimize cross-region calls, prefer internal load balancing for intra-VPC traffic, and consider PSC for producer-consumer traffic to avoid NAT egress.
  • Use Cloud CDN for static and semi-static assets; tune cacheability. Size Interconnect capacity to avoid overpaying for idle headroom; use traffic data to right-size commits.

Operational snippets:

• Allow load balancer health checks to private backends:
  • gcloud compute firewall-rules create allow-lb-hc –network=prod –action=ALLOW –direction=INGRESS –rules=tcp:80,tcp:443 –source-ranges=130.211.0.0/22,35.191.0.0/16 –target-service-accounts=backend-sa@project.iam.gserviceaccount.com
• Enable Private Google Access on a subnet:
  • gcloud compute networks subnets update app-subnet –region=us-central1 –enable-private-ip-google-access
• Create a Cloud Router for HA VPN:
  • gcloud compute routers create cr-us-central1 –region=us-central1 –network=prod –asn=64514

Practical Problem Scenario

Contoso Retail plans to launch a global e-commerce API with zero-downtime versioning, strict private connectivity to back-office systems, and no public IPs on application VMs. The solution must provide DDoS protection, edge caching, and reliable hybrid access from two data centers.

Approach:

1. Design the VPC and segmentation

• Create a custom-mode Shared VPC Host Project with dedicated subnets per tier (web, api, data) across two regions. Rationale: Shared VPC centralizes controls while service projects isolate teams. Per-tier subnets enable least-privilege firewalling and smaller failure domains.
• Apply hierarchical firewall policies at the org level to deny inbound SSH from the internet and restrict egress to allowed destinations. Rationale: Global guardrails reduce risk of misconfiguration in projects.

2. Implement path-based global ingress and API versioning

• Deploy an external HTTP(S) Load Balancer with a single anycast IP and HTTPS termination. Configure URL maps to route /v1/* and /v2/* to separate backend services backed by regional zonal NEGs. Rationale: Distinct backend services allow independent deployment and rollback for each API version under one hostname and TLS.
• Attach Cloud Armor WAF and rate limits; enable Cloud CDN for cacheable endpoints (for example, product images). Rationale: Protects origin and reduces latency and egress costs.

3. Ensure backend reachability and health

• Create a firewall rule to allow load balancer health checks to the api instance groups on the expected ports. Rationale: Without this, health checks fail and autoscalers may thrash as instances are deemed unhealthy.
• Distribute instances across two zones per region; set health check thresholds conservatively to avoid flapping. Rationale: Zonal diversity and stable health policies improve availability.

4. Build DNS with split-horizon and service discovery

• Create a public Cloud DNS zone for contoso.com and a private zone of the same name for internal-only records (for example, db.internal.contoso.com). Rationale: Split-horizon prevents internal names from leaking while keeping consistent naming.
• Configure DNS policies to forward on-premises corp.local queries to enterprise DNS and import private zones into application projects. Rationale: Seamless resolution across hybrid boundaries without recursion loops.

5. Establish hybrid connectivity with redundancy

• In each region, provision two HA VPN tunnels to each data center, each pair on separate Cloud Routers with BGP. If capacity and SLA needs justify it, add Partner Interconnect with redundant attachments in separate edge zones. Rationale: Multiple diverse paths provide failover; BGP enables fast convergence and dynamic route exchange.
• Use global dynamic routing in the Shared VPC and apply route filters to prevent unwanted on-premises prefixes from propagating. Rationale: Consistent routing across regions while reducing the risk of route leaks.

6. Provide private access to Google APIs and outbound internet

• Enable Private Google Access on app subnets and configure Private Service Connect endpoints for Google APIs used by batch jobs. Use Cloud NAT for non-API outbound egress where needed. Rationale: Backends maintain no public IPs while still reaching necessary services; PSC simplifies name resolution with private DNS.

7. Centralize transit and third-party connectivity

• Create a Network Connectivity Center hub in the Host Project; attach HA VPNs, Interconnect attachments, and any SD-WAN spokes. Rationale: Hub-and-spoke transit simplifies route distribution among multiple VPCs and external networks compared to peering meshes.

8. Implement observability and guardrails

• Enable VPC Flow Logs on all subnets with appropriate sampling; enable firewall logs on critical rules; export to BigQuery. Use Connectivity Tests in CI/CD before promoting new firewall or route changes. Rationale: Deep visibility supports troubleshooting, capacity planning, and auditability.
• Set alerts for Cloud Router BGP session drops, Cloud NAT port exhaustion, backend health dips, and Cloud Armor rule hits. Rationale: Early detection of failures and attacks reduces MTTR.

9. Optimize for performance and cost

• Co-locate stateful services with compute in the same region; cache static content at the edge with Cloud CDN. Rationale: Minimizes RTT and cross-region egress.
• Periodically review flow logs to identify cross-zone chatter and adjust placement or service boundaries. Rationale: Reduces unnecessary egress and latency.

This design delivers global, secure ingress with versioned routing, resilient hybrid connectivity with dynamic failover, private access to required services, and comprehensive observability, while controlling latency and egress costs.

← Data Storage · All domains · Security →

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

Browse Google →