Study guide
3.3 Serverless NEGs, Sessions, and Edge Controls
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.3 Serverless NEGs, Sessions, and Edge Controls
Key Takeaways Explain This Topic AI
Serverless NEGs do not use ordinary backend health checks or balancing-mode capacity settings.
Use Cloud Run best-effort affinity where needed; keep authoritative session state external.
CDN cacheability follows the chosen mode and origin directives; do not cache private responses accidentally.
Last updated: October 2026
Serverless Network Endpoint Groups (Serverless NEGs)
A Network Endpoint Group (NEG) specifies a group of backend endpoints. While Zonal NEGs contain VM IP/port pairs or GKE Pod IPs, Serverless NEGs point directly to serverless compute engines:
- Cloud Run services
- App Engine apps (standard and flexible)
- Cloud Functions (HTTP-triggered 2nd gen / Cloud Run functions)
- Multi-Region Cloud Run Active-Active Pattern
By attaching multiple regional Serverless NEGs to a single global Backend Service, the Global External ALB directs each client to the nearest Cloud Run region. Serverless NEGs do not support ordinary backend health checks or balancing-mode capacity settings. Where supported, explicitly configure outlier detection to reduce traffic to failing regions; it is not a guaranteed instantaneous regional failover or overflow mechanism. Test dependency failures as well as service failures. ## Create a Serverless NEG pointing to Cloud Run in us-central1
- gcloud compute network-endpoint-groups create neg-cr-us \
- -region=us-central1 \
- -network-endpoint-type=serverless \
- -cloud-run-service=order-service
- ## Create a Serverless NEG pointing to Cloud Run in europe-west1
- gcloud compute network-endpoint-groups create neg-cr-eu \
- -region=europe-west1 \
- -network-endpoint-type=serverless \
- -cloud-run-service=order-service
- ## Create a global Backend Service
- gcloud compute backend-services create orders-backend-service \
- -global \
- -load-balancing-scheme=EXTERNAL_MANAGED \
- -protocol=HTTPS
- ## Attach both regional Serverless NEGs to the global Backend Service
- gcloud compute backend-services add-backend orders-backend-service \
- -global \
- -network-endpoint-group=neg-cr-us \
- -network-endpoint-group-region=us-central1
- gcloud compute backend-services add-backend orders-backend-service \
- -global \
- -network-endpoint-group=neg-cr-eu \
- -network-endpoint-group-region=europe-west1
- Session Affinity Options
For supported VM/GKE backends, backend-service session affinity can improve locality. Serverless NEG backend services do not support load-balancer session affinity; configure Cloud Run's own best-effort affinity when needed. Store authoritative session state externally so failover and scaling do not lose it. +--------------------------------------------------------------------------+
- | Session Affinity Decision Matrix |
- +--------------------------------------------------------------------------+
- | |
- | Are clients connecting through corporate NAT proxies or shared gateways? |
- | | |
- | +--- YES ---> Use GENERATED_COOKIE |
- | | (Sets 'GCLB' cookie; prevents IP hotspot skewing) |
- | | |
- | +--- NO ----> Do clients send a unique tracking header? |
- | | |
- | +--- YES ---> Use HEADER_FIELD |
- | | (Hashes header, e.g., 'X-User-ID') |
- | | |
- | +--- NO ----> Use CLIENT_IP |
- | (2-tuple hash of src/dest IP) |
- +--------------------------------------------------------------------------+
NONE (Default): Requests are distributed across backends using round-robin or least-loaded algorithms. No stickiness.
CLIENT_IP : Hashes the client's source IP address. Critical Pitfall: If thousands of users access the application from behind a single corporate enterprise NAT gateway or university proxy, all users share the same source IP. The load balancer hashes them to the exact same backend instance, creating an extreme performance bottleneck (hotspot) while other instances sit idle.
GENERATED_COOKIE : The load balancer issues an HTTP session cookie (named GCLB ) on the first response. Subsequent requests containing this cookie are routed to the same backend instance. If the instance fails or scale-down occurs, the cookie is regenerated for a healthy instance. Cookie-based affinity avoids grouping all users solely by a shared NAT address, but distribution remains best effort.
HEADER_FIELD : Hashes the value of an arbitrary HTTP request header specified by the developer (e.g., X-Organization-Token or Authorization ).
Edge Security Integration: Google Cloud Armor
Cloud Armor attaches directly to the Backend Services of External Application Load Balancers, inspecting traffic at the edge before packets can reach backend compute instances or Serverless NEGs.
Layer 7 WAF & OWASP Top 10: Cloud Armor contains preconfigured rules for SQL injection ( sqli-v33-stable ), Cross-Site Scripting ( xss-v33-stable ), Local File Inclusion ( lfi-v33-stable ), and Remote Code Execution ( rce-v33-stable ).
Adaptive Rate Limiting: Enforces maximum request thresholds per client IP or custom header over configurable time windows, with an automatic ban period (e.g., blocking an IP for 10 minutes if it exceeds 100 requests in 1 minute).
Geo-Fencing: Evaluates client origin IP geolocations using ISO 3166-1 alpha-2 country codes: origin.region_code == 'CN' || origin.region_code == 'RU'
Preview Mode: Allows developers to test new WAF rules against live production traffic without dropping packets; matched requests emit an audit log with the evaluated disposition.
Edge Caching: Cloud CDN
Cloud CDN leverages Google's globally distributed edge caching infrastructure to terminate client requests at the PoP, dramatically reducing origin server load and delivery latency.
Enabling CDN: Can be enabled on supported backend services and backend buckets; verify compatibility with the selected backend and other features.
Cache Modes:
CACHE_ALL_STATIC : Automatically caches static web assets (images, CSS, JS, fonts) using eligible content types and cacheability rules; it still respects origin directives such as private , no-store , and no-cache .
USE_ORIGIN_HEADERS : Strictly respects origin Cache-Control response headers ( public , max-age , s-maxage , no-store ).
FORCE_CACHE_ALL : Caches all responses regardless of origin headers (used with extreme caution).
Cache Invalidation: If an urgent deployment modifies cached assets, invalidations are requested globally; allow for propagation via URL maps: gcloud compute url-maps invalidate-cdn-cache web-url-map \
--path="/static/v2/*"
Signed URLs & Signed Cookies: Protects private media streams and restricted downloads by verifying HMAC cryptographic signatures before serving cached assets.
Official references checked October 18, 2026: Google Cloud 1 .