Study guide
3.2 Geography, Network Tiers, and Load Balancers
Google Cloud Professional Cloud Developer Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam and Compute Platform Decisions
1.1 Current Exam, Sources, and Scenario Method 1.2 Cloud Run Execution and Platform Selection 1.3 GKE Modes and Compute Engine Trade-offs
2 Chapter 2: Container Engineering and API Contracts
2.1 Stateless Microservices and Multi-stage Builds 2.2 Container Hardening, Signals, and Layer Caching 2.3 REST, gRPC, and Protobuf Contracts
3 Chapter 3: gRPC Compatibility and Geographic Routing
3.1 Schema Evolution and gRPC Routing 3.2 Geography, Network Tiers, and Load Balancers 3.3 Serverless NEGs, Sessions, and Edge Controls
4 Chapter 4: API Management and Caching
4.1 API Management & Rate Limiting with Apigee and API Gateway 4.2 Memorystore and Cache Access Patterns 4.3 Cache Invalidation, Capacity, and Failover
5 Chapter 5: Messaging, Task Dispatch, and Orchestration
5.1 Event-Driven Messaging with Cloud Pub/Sub 5.2 Task Queues & Rate Throttling with Cloud Tasks 5.3 Event Routing and Service Orchestration: Eventarc & Cloud Workflows
6 Chapter 6: Resilience and Relational Availability
6.1 Designing Resilient Systems: Circuit Breaking, Retries & Failover 6.2 Cloud SQL Availability and Recovery 6.3 Connection Budgets and Spanner Consistency
7 Chapter 7: Distributed Schemas and NoSQL Data Models
7.1 Spanner Keys, Indexes, and Transactions 7.2 Firestore Data, Indexes, and Transactions 7.3 Bigtable Row Keys and Replication
8 Chapter 8: Object Storage and Application Identity
8.1 Cloud Storage Lifecycle and Signed Access 8.2 Workload Identity and Service Authentication 8.3 Secret Delivery, Rotation, and IAP
9 Chapter 9: Security, Data Integration, and Developer Credentials
9.1 Private Communication, Key Rotation, and Vulnerability Response 9.2 AlloyDB Schemas and BigQuery Ingestion 9.3 CLI Configurations, Local ADC, and Cloud Shell
10 Chapter 10: Managed Development and Automated Tests
10.1 Cloud Workstations and the Container Inner Loop 10.2 Emulating Google Cloud Services & Database Auth Proxies 10.3 Automated Testing Strategies: Unit, Integration, and Mocking
11 Chapter 11: AI Development Tools and Build Pipelines
11.1 AI Coding Assistants, Context, MCP, and Test Review 11.2 Cloud Build Workers and Step Dependencies 11.3 Builders, Substitutions, Triggers, and IAM
12 Chapter 12: Artifact Security and Admission Policies
12.1 Artifact Management and Vulnerability Scanning with Artifact Registry 12.2 Build Provenance and Admission Concepts 12.3 Attestors, Policy Enforcement, and Break-glass
13 Chapter 13: Cloud Run and GKE Deployment Configuration
13.1 Cloud Run Deployment and Scaling Configuration 13.2 Cloud Run CPU, Private Egress, and Secrets 13.3 GKE Workload Controllers and Gateway Routing
14 Chapter 14: Kubernetes Resources, Health, and Progressive Releases
14.1 GKE Resources, OOM Diagnosis, and Autoscaling 14.2 Container Health Probes, Lifecycle Hooks & Graceful Shutdown 14.3 Progressive Delivery: Traffic Splitting, Canary, and Blue/Green Rollouts
15 Chapter 15: Source/Event Deployment and Cloud API Integration
15.1 Source Deployment, Event Receivers, and API Versions 15.2 Client Libraries, Service Enablement, and ADC 15.3 API Responses, Pagination, Caches, and Retries
16 Chapter 16: Tracing, Sampling, and Monitoring
16.1 Trace Context and OpenTelemetry Export 16.2 Custom Spans, Trace Analysis, and Sampling 16.3 Application Metrics, Health Checks & Alerting with Cloud Monitoring
17 Chapter 17: Structured Logs, Routing, and Error Management
17.1 Structured Logs, Trace Correlation, and Queries 17.2 Log Routing, Export Destinations, and Exclusions 17.3 Error Reporting Formats and Regression Handling
18 Chapter 18: Profiling, Generative AI, and Assisted Troubleshooting
18.1 Cloud Profiler Types and Flame Graph Analysis 18.2 Generative AI Integration with the Google Gen AI SDK 18.3 Evidence-Based Troubleshooting with AI Assistance
3.2 Geography, Network Tiers, and Load Balancers
Key Takeaways Explain This Topic AI
Availability and residency properties depend on the actual service configuration.
Global external Application Load Balancers use Premium Tier and GFEs.
Regional external Application Load Balancers use regional proxy processing and support appropriate regional designs.
Last updated: October 2026
2.1 Geographic Distribution & Cloud Load Balancing
Designing resilient, highly responsive cloud-native applications on Google Cloud requires understanding how client requests traverse global network infrastructure. As a developer, selecting the correct load balancing architecture, network service tier, and backend abstraction determines whether your services survive regional outages, satisfy latency service level objectives (SLOs), and adhere to international data sovereignty mandates.
Geographic Resilience: Zonal, Regional, and Multi-Region Architectures
Google Cloud partitions its physical infrastructure into regions (independent geographic areas) and zones (isolated failure domains within a region interconnected with low-latency, high-bandwidth networking). +--------------------------------------------------------------------------+
- | Google Cloud Physical Infrastructure Topology |
- +--------------------------------------------------------------------------+
- | Multi-Region (Global Anycast Routing, Active-Active Cross-Continent) |
- | |
- | +---------------------------+ +---------------------------+ |
- | | Region: us-central1 | | Region: europe-west1 | |
- | | (Service-specific availability) | | (Service-specific availability) | |
- | | +------+ +------+ +------+ | | +------+ +------+ +------+ | |
- | | |Zone A| |Zone B| |Zone C| | | |Zone B| |Zone C| |Zone D| | |
- | | +------+ +------+ +------+ | | +------+ +------+ +------+ | |
- | +---------------------------+ +---------------------------+ |
- +--------------------------------------------------------------------------+
- Zonal Deployments
Topology: Resources (such as standalone Compute Engine VMs, zonal persistent disks, or single-zone GKE node pools) reside entirely within a single zone (e.g., us-central1-a ).
Availability: Single point of failure. A localized data center power disruption, physical hardware fault, or maintenance event will cause downtime.
Use Cases: Batch compute tasks with checkpointing, non-production test environments, or temporary processing instances where cost minimization overrides availability.
Regional Deployments
Topology: Resources use a service-specific multi-zone design within one region (e.g., regional Managed Instance Groups [MIGs] or regional GKE clusters operating in us-central1 ).
Availability: Availability SLAs depend on the product, edition, and deployment configuration. If an entire zone fails, the regional control plane and healthy instances in surviving zones continue serving traffic without operational disruption.
Compliance & Latency: Regional placement can help meet residency requirements. Assess the specific service, replication, backups, logs, support access, and contract; a regional deployment does not itself establish regulatory compliance.
Multi-Region Deployments
Topology: Services run active-active across multiple geographically separated regions (e.g., us-central1 , europe-west1 , and asia-east1 ).
Availability: Shields the system against catastrophic civil infrastructure failures, submarine cable cuts, or total regional cloud outages.
Routing Mechanics: Client traffic is directed to the geographically closest healthy region via Anycast BGP routing, minimizing Round-Trip Time (RTT).
Network Service Tiers: Premium Tier vs. Standard Tier
Google Cloud provides two distinct network tiers for external public ingress and egress. The network tier directly dictates how packets traverse the public internet versus Google's internal private fiber network.
Feature Premium Tier (Default) Standard Tier
Routing Strategy Cold Potato Routing: Ingress traffic enters Google's private global backbone at the Point of Presence (PoP) nearest the client. Hot Potato Routing: Ingress traffic remains on the public transit internet, entering Google's network only at the PoP closest to the destination region.
IP Address Type Single Global Anycast IPv4 or IPv6 address. Regional Unicast IPv4 address.
Performance & Jitter Uses Google's backbone for more of the path; actual latency, loss, and throughput depend on the complete connection. Dependent on public ISP transit congestion and third-party peering points; higher jitter.
Load Balancer Support Global External Application Load Balancers, Classic External ALBs, Global Proxy Network Load Balancers. Regional External Application Load Balancers , Regional External Proxy Network Load Balancers, Regional External Passthrough NLBs.
Cost Profile Higher egress bandwidth pricing; optimized for performance-critical systems. Lower egress pricing; suitable for regional apps or cost-sensitive non-critical workloads.
Exam Trap: Global External Application Load Balancers cannot be deployed using Standard Tier. If a question describes deploying a global HTTP/S load balancer with a single Anycast IP to route between North America and Europe, Premium Tier is mandatory.
Cloud Load Balancing Topology
Google Cloud Load Balancing is a software-defined, distributed proxy service implemented across Google's global Andromeda virtualization and Envoy proxy fleet. It is not an appliance; there is no physical bottleneck or pre-warming requirement. +--------------------------------------------------------------------------+
- | Google Cloud Load Balancing Architectural Topology |
- +--------------------------------------------------------------------------+
- | |
- | [ External Traffic ] |
- | | |
- | v |
- | +--------------------------------------------------------------------+ |
- | | Global External Application Load Balancer (Google Front Ends) | |
- | | - Single Global Anycast VIP (IPv4/IPv6) | |
- | | - Edge SSL/TLS Termination & HTTP/2 / HTTP/3 (QUIC) Support | |
- | | - Edge Cloud Armor WAF & DDoS Inspection | |
- | | - Cloud CDN Edge Cache Offload | |
- | +--------------------------------------------------------------------+ |
- | | |
- | | URL Map Routing (Host Rules, Path Matchers, Header Matchers) |
- | v |
- | +----------------------------------+---------------------------------+ |
- | | | | |
- | v v v |
- | [ Backend Service: US ] [ Backend Service: EU ] [ GCS Bucket ]
| - Serverless NEG: no balancing-mode capacity settings - Serverless NEG: no balancing-mode capacity settings (Static Assets)
- | - Cloud Run affinity configured on the service |
- | +-------------------+ +-------------------+ |
- | | Serverless NEG | | Serverless NEG | |
- | | (Cloud Run: US) | | (Cloud Run: EU) | |
- | +-------------------+ +-------------------+ |
- +--------------------------------------------------------------------------+
- Global External Application Load Balancer
OSI Layer: Layer 7 (HTTP, HTTPS, HTTP/2, HTTP/3 with QUIC).
Architecture: Distributed Google Front Ends (GFEs) terminate client sessions. Regional external Application Load Balancers use regional Envoy proxies. Backends can be located across multiple regions.
Key Features: Cross-region automatic failover, single global Anycast IP, URL maps for path-based ( /api/v1/* vs /static/* ) and header-based routing, traffic splitting (canary releases), and seamless integration with Cloud Armor and Cloud CDN.
Regional External Application Load Balancer
OSI Layer: Layer 7 (HTTP/S).
Architecture: Regional Envoy proxy terminating traffic inside a specific Google Cloud region.
Use Case: Systems bound by data sovereignty laws requiring that TLS termination, payload inspection, and routing logic occur strictly within the borders of a specific region (e.g., Frankfurt europe-west3 ). Supports both Standard and Premium Tiers.
Internal Application Load Balancers (Regional & Cross-Region)
OSI Layer: Layer 7.
Architecture: Private RFC 1918 load balancer deployed inside a Virtual Private Cloud (VPC). Proxies traffic between internal microservices with TLS inspection, URL maps, and zero-trust service perimeters.
Official references checked October 18, 2026: Google Cloud 1 .