Google PCNE: Load Balancing, Cloud CDN and Global Traffic Management — 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 how Google Cloud Load Balancing, Cloud CDN, and global traffic management work together to deliver resilient, performant, and secure services. It covers load-balancer families and selection, proxy versus passthrough behavior, backend and routing components, failover and capacity management, Cloud CDN caching and origin protections, anycast and cross-region designs, DNS steering and health checks, observability, and design patterns for robust global entry points.

Load-balancer families, selection, and data-plane behavior

Google Cloud provides external and internal load balancers with distinct scope, protocol, and data-plane characteristics. Choosing the right one aligns protocol needs, geography, and operational controls.

External proxy L7 (global): External Application Load Balancer for HTTP(S) and gRPC. Terminates TLS, enforces L7 policies, supports URL maps, Cloud CDN, Cloud Armor, request/response features, and anycast IPv4/IPv6. Best for internet-facing web APIs/sites requiring advanced routing, security, and caching.
External proxy L4.5: External TCP Proxy Load Balancer (global) and External UDP Proxy Load Balancer (regional) terminate client connections and proxy to backends. Use when you need global VIP and L4 features (TLS policy, client IP preservation via headers for TCP) without L7 routing.
External passthrough L3/L4 (regional): External Network Load Balancer forwards packets without terminating the connection. Lowest latency and simplest; supports TCP/UDP/ESP/ICMP. Appropriate for lift-and-shift, heterogeneous backends, or protocols that cannot tolerate proxy termination. Classic NLB uses target pools; newer regional passthrough NLB uses backend services.
Internal proxy (regional): Internal HTTP(S) Load Balancer (L7) and Internal TCP Proxy Load Balancer (L4.5) terminate and proxy inside a VPC for microservice north-south and service-to-service use. Support host/path routing (HTTP), mTLS to clients via application, and per-service security policies.
Internal passthrough (regional): Internal TCP/UDP Load Balancer distributes connections to backends over private RFC1918, preserving client IP and using MAGLEV hashing. Ideal for east-west services (databases, custom protocols) requiring zone-aware distribution and low overhead.

Layer and termination trade-offs:

Proxy L7/4.5 gives advanced routing, TLS offload, observability, Cloud Armor/CDN, and cross-region failover at the cost of additional hops and possible header/NAT changes. It suits public entry points and service meshes.
Passthrough L3/L4 preserves client IP end-to-end and minimizes latency, but no L7 features and fewer observability hooks. Session behavior is hash-based; health checks are simpler.

Scope and IP families:

Global anycast VIPs are available for external Application LB and external TCP Proxy LB, providing single IPv4/IPv6 addresses reachable from everywhere. Regional LBs use regional unicast VIPs. IPv6 exposure for public services is achieved by configuring an external global load balancer with an IPv6 address.

Selection criteria highlights:

Need host/path routing, redirects, Cloud CDN, Cloud Armor, or gRPC: External Application LB.
Need global TCP without L7: External TCP Proxy LB.
Protocols that dislike proxies (e.g., some legacy UDP/TFTP): External or Internal passthrough.
Private service-to-service with HTTP routing: Internal HTTP(S) LB.
Minimize cost/hops for intra-VPC traffic: Internal passthrough.

Backend services, routing objects, health, and traffic stickiness

Core data-plane objects:

Backend services: Define backends (instance groups, zonal NEG, hybrid NEG, serverless NEG), health checks, balancing mode, capacity, session affinity, timeout, and failover policy. Required for proxy LBs and newer passthrough LBs.
Target pools: Legacy construct for classic external NLB. Suitable for simple TCP/UDP distributions and heterogeneous VMs during lift-and-shift.
Named ports: Keys on instance groups mapping logical names (e.g., http) to port numbers, referenced by backend services and URL maps. Ensure consistency across group members.

Health checks and failover:

Types: HTTP(S), HTTP/2, gRPC, TCP, SSL. Choose a check that validates actual service readiness, not just OS reachability.
Scope: Health checks are regional; each backend should have a health check scoped to its serving region.
Failover policy: Backend service can designate primary and failover backends. Traffic fails over when primary is unhealthy or out of capacity (if failover-on-capacity is enabled and threshold is met). Consider draining and capacity reservation to avoid thundering herd.

URL maps and routing:

URL map attaches to the external or internal HTTP(S) LB and defines host rules and path matchers.
Default service: Catch-all backend for requests that match no rule; if unset, 404 is returned.
Redirects and rewrites: Use URL map actions to perform HTTPS redirects, canonical host redirects, or path rewrites before routing.

Example: minimal URL map with HTTPS redirect and default backend

Create a host rule for example.com, redirect HTTP to HTTPS, route /static to a CDN-enabled backend bucket, and default to a regional backend service.

Session affinity and draining:

Affinity options depend on LB type. Common options:
- None: Best for stateless; maximizes load distribution.
- Client IP: Sticky by source IP across L4/L7; use when multiple protocols (e.g., HTTP and TFTP) must be co-sticky to the same backend.
- Generated cookie (L7 only): LB sets a cookie to persist to a backend; better distribution than client-IP on NATed clients.
Trade-offs: Affinity can cause hotspotting and complicate autoscaling. Prefer statelessness where possible.
Connection draining: On scale-in or backend removal, the LB honors draining timeout to let existing connections close gracefully. Tune drain time to your longest expected request to prevent resets.

Capacity and autoscaling:

Balancing modes: Based on utilization (e.g., CPU), RPS, or connections. Each backend advertises capacity; the LB sheds load or fails over when saturation occurs.
Autoscaling: Managed instance groups scale based on signals (CPU, custom metrics). Scale-out lag can cause 503 if LB runs out of capacity; pre-warm by minimum replicas or predictive autoscaling for diurnal traffic.
Failover and overflow: Enabling failover-on-capacity with an appropriate threshold allows smooth cross-region overflow.

Security at backends:

Restrict backend access using firewall rules targeting instance tags or service accounts. Allow only traffic from Google load balancer and health-check source ranges and your approved client ranges if direct access is required for internal clients.

Example: restrict clients and health checks to a backend-tagged group

Tag instances with application.
Create an ingress allow rule for tcp:80 from your client CIDRs and Google health check ranges, targeting tag application.
Deny-by-default is recommended to surface dropped traffic in logs.

Cloud CDN, cache policy, and origin protection

Cloud CDN integrates with the external Application Load Balancer to cache responses at edge POPs, reducing latency and offloading origin capacity.

Cache modes and TTLs:

Use origin headers: Honors Cache-Control and Expires from your origin. Preferred for correctness.
Force cache: Caches all responses with a configured default TTL, optionally overriding or ignoring origin headers for static content. Use carefully to avoid caching dynamic data.
Bypass cache: Useful for paths that must never be cached.

Cache keys:

Key fields include protocol, host, path, query parameters, headers, and cookies. Configure query-string policy (include all, include selected, or ignore), selective header and cookie inclusion, and device segmentation as needed.
Keep keys minimal to maximize hit ratio; vary only on fields that change representation.

Signed requests:

Signed URLs: Attach an HMAC or RSA signature with expiry and path scope to grant time-bound access to specific resources. Good for CDN-as-accelerator with per-object authorization.
Signed cookies: Authorize a set of paths with a cookie; useful for whole-site gated content.
Rotate keys and enforce short expirations to reduce replay risk.

Compression and correctness:

Origins must compress even when requests include a Via header. If CDN serves uncompressed objects while origin “supports compression,” verify the origin is configured to compress when Via is present.

Origin security:

Use HTTPS from edge proxies to origins with modern TLS policies.
Limit origin reachability: backend firewall rules that only permit traffic from Google load balancer and health check source ranges and from known private producers. Backend instances should not accept arbitrary public ingress.
Pair with Cloud Armor for L7 DDoS/WAF, rate limiting, and threat detection. Use preview mode for new rules to mitigate false positives.
Invalidate content intentionally using cache invalidation APIs when you must purge before TTL expiry. For dynamic content, prefer short TTLs and revalidation (ETag/If-None-Match).

Failure modes and trade-offs:

Overly broad cache keys waste cache and lower hit ratio; overly narrow keys risk serving incorrect variants.
Force caching dynamic data can leak personalized content.
Signed URLs/cookies protect access at the edge, but origin bypass must still be denied via network policy.

Global traffic management, DNS steering, observability, and resilient entry points

Anycast front doors and cross-region failover:

External Application LB and external TCP Proxy LB use global anycast VIPs to attract clients to the nearest Google edge. Traffic is then proxied to the healthiest and nearest backend with capacity. Configure multiple backend regions with consistent health checks and capacity settings for seamless failover and overflow.
Pre-provision capacity in secondary regions to avoid cold-start penalties; coordinate autoscaler min/max with LB capacity thresholds.

Regional internal traffic management:

Internal HTTP(S) LB and internal passthrough LB are regional; design for zone diversity within a region and, when needed, multi-region using separate LBs with Private Service Connect or service-aware clients to select regional endpoints.
Keep east-west latency low by placing communicating services in the same region and VPC. Use RFC1918 addressing with a single VPC or peered VPCs for minimal cost and operational simplicity.

Cloud DNS routing policies and health checks:

Policies: Weighted round robin (traffic splitting), geolocation (send users to the closest regional VIP), and failover (primary/backup). Combine policies to meet business rules.
Health checks: Attach DNS health checks (HTTP/HTTPS/TCP) to A/AAAA records used in steering so unhealthy endpoints are withdrawn. Account for resolver caching (TTL) which delays reaction; keep TTLs low on steered records to improve failover responsiveness at the cost of more DNS lookups.
Traffic steering: Use weighted policies to phase migrations or shift load between regions. Avoid steering to private addresses from the internet unless using split-horizon DNS.

Observability and diagnostics:

Load-balancer logging: Enable logging for all LBs. HTTP(S) logs include request method/URI, latency, cache hit/miss, backend service, URL map rule, TLS details, and response codes. TCP/UDP logs provide connection metadata and health probe status.
Metrics: Monitor backend health, utilization, RPS, connections, latency, cache hit ratio, 4xx/5xx rates, and capacity saturation. Alert on sudden changes and sustained thresholds.
Common HTTP(S) error patterns:
- 404: No URL map match; confirm host/path rules and default service.
- 301/302: Intentional redirects; verify redirect loops.
- 502: Backend connection or protocol mismatch (e.g., HTTP/1.1 vs gRPC); check health and backend protocol config.
- 503: No healthy or no capacity backends; verify health checks, quotas, and autoscaler behavior.
Request tracing: Use X-Forwarded-For, X-Forwarded-Proto, and trace IDs propagated by your app. Correlate LB logs with backend logs using request IDs.
Firewall insights: Enable VPC firewall logging on allow and deny rules. To log drops explicitly, add a low-priority deny-all with logging enabled.

Resilient global entry-point design:

Use a single global anycast VIP on an external Application LB fronting multiple regional backends. Place serverless/VM/container backends in at least two regions. Enable cross-region failover and overflow, configure conservative health checks, and tune draining and timeouts for your workloads.
Protect entry with Cloud Armor and quota-limiting policies. Use Cloud CDN for static and cacheable dynamic content to absorb traffic surges at the edge.
Expose dual-stack IPv4/IPv6 on the global LB to serve all networks. For strict client access, apply backend firewall rules with precise source ranges and instance tags or service accounts.

Example: firewall rule restricting client and health check ranges to tagged backends

Tag instances with application.
Create an ingress allow for tcp:443 source-ranges=203.0.113.0/24,198.51.100.0/24, and Google health check ranges targeting application.
Ensure a lower-priority deny-all with logging exists to capture unexpected sources.

Practical Problem Scenario

Acme Retail launches a global e-commerce platform needing low latency, strong security, and transparent failover across us-east1 and europe-west1 while serving static media efficiently. Only corporate offices and a partner CDN staging network should reach the private admin interface.

Front door and backends

Create an external Application Load Balancer with a dual-stack anycast VIP and TLS certificates for the public storefront hostname.
Define two backend services, each pointing to a regional managed instance group in us-east1 and europe-west1. Enable health checks (HTTPS) and set balancing mode to utilization with an 80% capacity threshold. Rationale: Anycast plus multi-region backends ensures users hit the closest edge and fail over seamlessly if a region is unhealthy or saturated.

URL map, routing, and redirects

Configure a URL map with host rules for the public storefront and private administrator hostnames. Route /static to a backend bucket with Cloud CDN enabled; route /api and / to the VM backends. Add an HTTP-to-HTTPS redirect. Rationale: Host/path routing separates static from dynamic traffic and enforces secure access.

Cloud CDN policy

For the /static backend bucket, set cache mode to use origin headers and define a cache key that ignores non-functional query params and only includes the Accept-Encoding header. Enable negative caching for common 404s with a short TTL. Rationale: Honors content semantics, maximizes hit ratio, and avoids caching incorrect variants.

Session affinity and draining

Set generated-cookie affinity for the public storefront and none for static assets; set connection draining to 60 seconds. Rationale: Cookies keep cart sessions stable while allowing broad distribution; draining prevents user-visible errors during scale-in or failover.

Cross-region failover and autoscaling

Enable failover-on-capacity with a 90% overflow threshold to shift excess to the other region. Configure MIG autoscaling with minimum replicas of 4 per region and CPU targets matching LB utilization. Rationale: Avoids capacity cliffs and coordinates LB and autoscaler decisions for smooth scaling.

Admin interface restriction

Create an internal HTTP(S) Load Balancer for the private administrator hostname, accessible only inside the VPC. Publish split-horizon Cloud DNS so internal clients resolve to the ILB VIP and external clients receive NXDOMAIN. Rationale: Keeps admin traffic private and controlled without exposing public endpoints.

Backend firewall and origin security

Tag admin and web backends application and add an allow rule for tcp:443 from corporate and staging CIDRs plus Google load balancer and health check source ranges; add a deny-all with logging at lower priority. Rationale: Ensures only intended clients and Google infrastructure can reach backends and provides drop visibility.

Cloud Armor

Apply a security policy with managed WAF rules and a previewed rate limit for /api bursts. Rationale: L7 protection and staged enforcement reduce risk while tuning.

Cloud DNS steering and health checks

Publish A and AAAA records for the public storefront hostname to the ALB anycast VIP. For a blue/green canary, create a weighted policy on a designated canary hostname, splitting 5% to the europe-west1-only ALB and 95% to the global deployment. Attach HTTPS health checks to withdraw the canary if unhealthy and set TTL to 20 seconds. Rationale: DNS-based canary enables gradual exposure with health-aware removal and quick convergence.

Observability

Enable LB and CDN logs; export to BigQuery for analysis. Set alerts on 5xx rate, backend capacity, health check failures, and CDN hit ratio. Use URL map tests and request logs to diagnose routing errors; inspect 502/503 spikes for backend saturation or protocol mismatches. Rationale: Proactive monitoring and rapid diagnostics minimize MTTR and preserve user experience.

← Hybrid Connectivity · All domains · Cloud DNS →

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