Study guide
1.2 Cloud Run Execution and Platform Selection
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
1.2 Cloud Run Execution and Platform Selection
Key Takeaways Explain This Topic AI
Cloud Run services receive requests on the configured PORT and use external durable storage.
Concurrency is an explicit workload setting; new-service defaults differ between console and CLI/Terraform.
Instance-based CPU helps between requests but does not guarantee durable post-response execution.
Last updated: October 2026
Compute Platform Selection: Cloud Run, GKE, and Compute Engine
Designing cloud-native applications on Google Cloud begins with selecting the compute platform that matches your workload's operational profile, scaling requirements, hardware dependencies, and execution model. The Google Cloud Professional Cloud Developer exam tests your ability to evaluate trade-offs between fully managed serverless containers ( Cloud Run ), enterprise container orchestration ( Google Kubernetes Engine / GKE ), and Infrastructure as a Service ( Compute Engine ).
Cloud Run: Fully Managed Serverless Containers
Cloud Run executes containers without requiring cluster management, VM provisioning, or node OS patching. Its container contract and Knative-style configuration support portable application packaging, but networking, identity, triggers, and managed-service integrations still require migration work.
Core Capabilities and Runtime Semantics
Scale-to-Zero and Instant Elasticity: When no traffic arrives, Cloud Run scales active container instances to zero, avoiding instance compute charges when scaled to zero; other services, storage, and networking can still incur charges. When an HTTP request, gRPC call, or Eventarc event arrives, Cloud Run provisions container instances in milliseconds to seconds.
Container Port Contract: The containerized application must listen for incoming HTTP/1.1, HTTP/2, or gRPC requests on the port specified by the PORT environment variable (default 8080 ), binding to 0.0.0.0 .
Stateless Execution: Container file systems are ephemeral and memory-backed (written to RAM). Persistent data must be committed to external storage systems such as Cloud Storage, Cloud SQL, Firestore, or Cloud Spanner.
Request Timeout: Individual request execution is bounded by a configurable timeout (default 5 minutes, configurable up to 60 minutes for HTTP services, and up to 168 hours per non-GPU Cloud Run job task attempt; GPU tasks have a 1-hour maximum).
Concurrency and Scaling Triggers
Unlike traditional Functions-as-a-Service (FaaS) platforms where each instance handles only one request at a time, Cloud Run supports multi-concurrency :
Container Concurrency ( --concurrency ): Defines the maximum number of simultaneous requests a single container instance can receive (maximum 1000 ; console-created services default to 80 , while new CLI/Terraform services default to 80 times vCPU count).
Multi-threaded vs. Single-threaded Runtimes: For multi-threaded runtimes (Go, Java, .NET, Rust), high concurrency (e.g., 80 to 250 ) optimizes resource utilization and lowers cost. For CPU-heavy single-threaded handlers, lower concurrency can reduce contention. I/O-bound Node.js handlers can efficiently overlap requests. Load-test the actual framework and worker count instead of assigning concurrency solely from language choice. ## Deploying a high-concurrency microservice to Cloud Run
- gcloud run deploy order-service \
- -image=us-central1-docker.pkg.dev/my-project/apps/order-service:v1.2 \
- -concurrency=80 \
- -min-instances=2 \
- -max-instances=100 \
- -cpu=2 \
- -memory=2Gi \
- -no-cpu-throttling \
- -region=us-central1
- CPU Allocation Models
Cloud Run offers two distinct CPU allocation models that dictate pricing and execution guarantees:
Feature Request-Based CPU Allocation ( cpu-throttling ) Always-Allocated CPU ( --no-cpu-throttling )
CPU Availability CPU is only allocated during request processing and lifecycle events CPU is continuously allocated for the entire container instance lifetime
Background Threads Throttled to near-zero when no active requests are pending Full CPU cycles available for background processing between requests
Billing Model Billed per vCPU-second and GiB-second during active request handling Billed for the entire time the instance is running (warm or active)
Cost Profile Lowest cost for intermittent, bursty, or spiky request traffic Higher baseline cost; comparable to persistent VM pricing
Use Cases Synchronous REST/gRPC APIs, webhooks, short-lived tasks Pub/Sub subscriber pull loops, background batch caching, metrics flushing
Exam Trap: If a developer launches a background goroutine or thread to flush logs, send telemetry, or execute asynchronous cleanup after returning the HTTP response, request-based CPU allocation will throttle the CPU almost immediately. The thread will freeze until a subsequent request wakes the instance, leading to dropped telemetry or delayed processing. To execute background threads safely between requests, specify --no-cpu-throttling .
Cold Starts and Mitigation Strategies
A cold start occurs when Cloud Run provisions a new container instance from scratch to handle incoming traffic. Cold start latency comprises container image pull time, container start, and runtime/application initialization.
Minimum Instances ( --min-instances ): Keeps a predetermined number of container instances initialized, warm, and ready to serve traffic immediately, reducing cold starts for baseline traffic; replacements and traffic growth can still require new instances.
Startup CPU Boost ( --cpu-boost ): Temporarily allocates extra vCPUs during container initialization (startup probe and app boot) to reduce initialization latency; the improvement depends on the workload before scaling down to configured steady-state CPU limits.
Image Size Optimization: Use minimal base images (Distroless, Alpine) stored in Artifact Registry near the workload to reduce transfer overhead; measure application initialization rather than assuming image size determines startup latency.
Official references checked October 18, 2026: Google Cloud 1 , Google Cloud 2 .