Study guide
13.2 Cloud Run CPU, Private Egress, and Secrets
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
13.2 Cloud Run CPU, Private Egress, and Secrets
Key Takeaways Explain This Topic AI
Always-allocated CPU does not make post-response business work durable.
Static public egress uses an all-traffic VPC route and configured Cloud NAT addresses.
Mounted secrets and environment secrets have different refresh behavior; tag URLs still obey service access controls.
Last updated: October 2026
CPU Allocation Models: Throttling vs. Always-Allocated
Cloud Run provides two distinct CPU allocation models that dictate how the virtual CPU behaves throughout the container lifecycle: ## Model 1: CPU allocated only during request processing (default)
gcloud run services update order-service --cpu-throttling --region=us-central1
- ## Model 2: CPU always allocated (continuous execution)
- gcloud run services update order-service --no-cpu-throttling --region=us-central1
Architectural Dimension CPU Only During Request ( --cpu-throttling ) CPU Always Allocated ( --no-cpu-throttling )
CPU State When Idle Throttled to near-zero as soon as HTTP response finishes Full CPU capacity remains continuously available between requests
Billing Model Billed only while actively processing requests (rounded to 100ms) Billed continuously for the entire instance lifespan (startup to shutdown)
Background Threads Suspended; background goroutines/threads pause execution Can run between requests while the instance exists; shutdown still interrupts them
Outbound Async Calls Unreliable; firing an async task after returning 200 OK causes failures CPU available while instance exists; termination can still interrupt work
Use Cases Traditional REST/GraphQL APIs, webhooks, synchronous request-response Best-effort background housekeeping; use durable dispatch for business work. Active streams already count as requests
Exam Trap: A common exam scenario involves an application that returns an HTTP 200 OK to a client and attempts to process data or write analytics asynchronously on a background worker thread. With default CPU throttling, Cloud Run freezes the CPU milliseconds after the HTTP response is sent. The background thread halts mid-execution until another request happens to hit that same container instance! For best-effort between-request work, choose instance-based CPU allocation. For invoice generation or other required business effects, enqueue durable work and acknowledge only after completion; CPU allocation alone cannot guarantee completion.
Networking: Ingress & Egress Architectures
Cloud Run microservices operate within a multi-tenant Google frontend architecture. Securing ingress paths and controlling outbound egress routing are essential developer requirements.
Ingress Controls
Ingress controls restrict the network origins from which requests can reach your Cloud Run service:
- Ingress Mode CLI Parameter Allowed Traffic Sources
- All (Default) --ingress=all Direct public internet traffic, VPC networks, and Google Cloud services
Internal --ingress=internal Recognized internal VPC and Google-service paths meeting the documented project/perimeter and URL conditions; arbitrary same-organization traffic is not automatically internal
Internal and Cloud Load Balancing --ingress=internal-and-cloud-load-balancing Internal VPC resources plus External/Internal Application Load Balancers (ALB)
Using internal-and-cloud-load-balancing is an enterprise best practice: it restricts external traffic to supported load-balancer ingress while still allowing recognized internal access to the default URL. IAM remains separate. Route public traffic through a Cloud Load Balancer equipped with Cloud Armor (DDoS mitigation, WAF rules) and Cloud CDN caching.
Egress Controls: Direct VPC Egress vs. Serverless VPC Access
To communicate privately with internal VPC workloads (such as private Cloud SQL instances, Memorystore Redis caches, internal GKE services, or on-premises servers via Cloud Interconnect), Cloud Run must route egress traffic into your VPC.
Serverless VPC Access Connector ( --vpc-connector ):
Requires creating a dedicated /28 CIDR connector subnet.
Provisions Google-managed connector VMs ( e2-micro or f1-micro ) inside your project.
Bandwidth throughput is constrained by connector VM instance count and introduces billing overhead for idle connector VMs.
Direct VPC Egress ( --network and --subnet ):
Attaches subnetwork interfaces directly to Cloud Run container instances without intermediary connector VMs.
Offers higher network throughput, sub-millisecond latency improvements, and zero VM maintenance costs.
Modern standard for Cloud Run VPC connectivity.
Routing All Egress via Cloud NAT for Static Public IPs
By default, Cloud Run egress to the public internet uses dynamic Google IP pools. If an external third-party API requires IP whitelisting, you must force all outbound traffic through your VPC:
Configure Direct VPC egress: --network=prod-vpc --subnet=backend-subnet .
Set --vpc-egress=all-traffic (routes RFC 1918 private ranges AND public internet ranges through the VPC subnet).
Attach a Cloud NAT gateway with a reserved Static Cloud External IP to the VPC subnet.
All outbound calls to third-party endpoints will originate deterministically from the reserved Static IP address.
Environment Variables, Secret Manager & Volume Mounts
Applications require externalized configuration and sensitive credentials at runtime.
Environment Variables & Secret Manager Integration ## Injecting plain environment variables and Secret Manager secrets
- gcloud run services update order-service \
- -set-env-vars=FEATURE_FLAG_NEW_CHECKOUT=true,CACHE_TTL=3600 \
- -set-secrets=DATABASE_PASSWORD=order-db-secret:latest,STRIPE_KEY=stripe-api-token:2
Secret Injection Trade-offs:
Environment Variables ( --set-secrets=ENV_VAR=SECRET:VERSION ): Fast and convenient. However, secrets injected as environment variables are evaluated only during container startup. If you reference latest and update the secret version in Secret Manager, running instances continue using the old version until a new revision is deployed or instances restart.
Volume Mounts ( --set-secrets=/secrets/api-key=SECRET:VERSION ): Mounts the secret as a read-only file at the specified filesystem path. Applications reading from the file system can detect updated secret versions without restarting containers.
Cloud Storage FUSE Mounts & In-Memory Volumes
Cloud Run supports second-generation execution environments that allow mounting Cloud Storage buckets and temporary memory filesystems:
Cloud Storage FUSE Mounts: Mounts a Cloud Storage bucket directly into the container filesystem namespace ( --add-volume=name=docs-vol,type=cloud-storage,bucket=corp-docs-bucket and --add-volume-mount=volume=docs-vol,mount-path=/mnt/docs ). Ideal for reading static assets, machine learning model weights, or large batch files using standard POSIX file I/O.
In-Memory Volumes ( emptyDir ): Mounts an ephemeral RAM-backed filesystem ( medium: Memory ). Writing to an in-memory volume consumes container RAM but provides ultra-high IOPS for temporary scratch files, image transforms, or ephemeral caches without persisting data to disk.
Revision Tagging & Targeted Routing
Changes to the revision template create a new immutable Revision ; traffic-only or service-level changes need not create one. Cloud Run allows assigning traffic tags to specific revisions using --tag : ## Deploying a new revision with a dedicated URL tag
- gcloud run deploy order-service \
- -image=us-central1-docker.pkg.dev/my-project/app-repo/order-service:v2.2.0 \
- -tag=canary \
- -no-traffic
Assigning --tag=canary generates a unique, deterministic URL: https://canary---order-service-67abcde-uc.a.run.app
This architecture allows internal integration test suites, QA teams, or automated synthetic monitors to send live HTTP requests directly to the new container revision while 100% of public user traffic remains safely pinned to the stable production revision.
Official references checked October 18, 2026: Google Cloud 1 .