ExamFinch.com My Study

Study guide

13.1 Cloud Run Deployment and Scaling Configuration

Practice this exam

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.1 Cloud Run Deployment and Scaling Configuration

Key Takeaways Explain This Topic AI

Autoscaling considers CPU and concurrency, with capacity and quotas affecting results.

Minimum instances reduce but do not eliminate all cold starts.

Instance limits can temporarily be exceeded and revisions can overlap; reserve database capacity and enforce pooling.

Last updated: October 2026

Serverless Deployment Configuration on Cloud Run

Google Cloud Run is a managed serverless platform that deploys and runs containerized applications directly on Google's scalable infrastructure. Built upon the open Knative specification, Cloud Run abstracts away underlying cluster management, virtual machine provisioning, and OS patching, allowing developers to focus purely on application logic. Cloud Run handles HTTP requests, gRPC calls, WebSockets, and asynchronous events while scaling elastically from zero to thousands of container instances.

For the Google Cloud Professional Cloud Developer exam, mastering Cloud Run deployment requires a deep understanding of runtime scaling parameters, CPU throttling models, VPC networking architectures, secret mounting techniques, and declarative service schemas.

Cloud Run Deployment Workflows & Declarative Schemas

Cloud Run supports two deployment workflows: imperative CLI commands via gcloud run deploy and declarative manifest application via gcloud run services replace .

Imperative Deployment with gcloud run deploy

The gcloud run deploy command deploys container images from Artifact Registry to Cloud Run, automatically creating or updating the service and generating an immutable revision: ## Deploying a production-ready Cloud Run microservice

  • gcloud run deploy order-service \
  • -image=us-central1-docker.pkg.dev/my-project/app-repo/order-service:v2.1.0 \
  • -region=us-central1 \
  • -platform=managed \
  • -allow-unauthenticated \
  • -port=8080 \
  • -concurrency=80 \
  • -cpu=2 \
  • -memory=2Gi \
  • -min-instances=2 \
  • -max-instances=100 \
  • -no-cpu-throttling \
  • -ingress=all \
  • -network=production-vpc \
  • -subnet=backend-subnet \
  • -vpc-egress=all-traffic \
  • -set-env-vars=ENVIRONMENT=production,LOG_LEVEL=info \
  • -set-secrets=/secrets/db-password=order-db-secret:latest \
  • -service-account=sa-order-runner@my-project.iam.gserviceaccount.com
  • Declarative Service Schema ( service.yaml )

In GitOps and CI/CD pipelines, Cloud Run services are declared using Knative-compliant YAML manifests adhering to the serving.knative.dev/v1 API group: apiVersion: serving.knative.dev/v1

kind: Service

metadata:

  • name: order-service
  • namespace: 'my-project'

annotations:

  • run.googleapis.com/ingress: all
  • run.googleapis.com/launch-stage: GA

spec:

template:

metadata:

name: order-service-v2-1-0

annotations:

  • # Minimum and maximum autoscaling instances
  • autoscaling.knative.dev/minScale: '2'
  • autoscaling.knative.dev/maxScale: '100'
  • # CPU allocation: false means CPU is always allocated
  • run.googleapis.com/cpu-throttling: 'false'
  • # Direct VPC egress network interface
  • run.googleapis.com/network-interfaces: '[{"network":"production-vpc","subnetwork":"backend-subnet"}]'
  • run.googleapis.com/vpc-access-egress: all-traffic

spec:

  • containerConcurrency: 80
  • timeoutSeconds: 300
  • serviceAccountName: sa-order-runner@my-project.iam.gserviceaccount.com

containers:

- image: us-central1-docker.pkg.dev/my-project/app-repo/order-service:v2.1.0

ports:

  • name: http1
  • containerPort: 8080

resources:

limits:

  • cpu: '2000m'
  • memory: '2Gi'

env:

  • name: ENVIRONMENT
  • value: 'production'

volumeMounts:

  • name: db-secret-volume
  • mountPath: /secrets

volumes:

- name: db-secret-volume

secret:

secretName: order-db-secret

items:

  • key: latest
  • path: db-password

To apply this declarative configuration, execute: gcloud run services replace service.yaml --region=us-central1

Scaling Parameters: Concurrency, Min Instances & Max Instances

Cloud Run autoscaling operates at the instance level. Unlike Kubernetes Horizontal Pod Autoscaler (which scales based on average CPU or memory utilization), Cloud Run uses CPU and request-concurrency signals. CPU utilization is averaged across allocated vCPUs, which can hide a single busy thread on a multi-vCPU instance.

Request Concurrency ( --concurrency )

Concurrency defines the maximum number of requests that can be processed simultaneously by a single container instance:

Default Value: 80 for console-created services; 80 times vCPU count for newly created CLI/Terraform services. Set the value explicitly for reproducible examples.

Configurable Range: 1 to 1000 requests per instance.

When the volume of incoming concurrent requests exceeds (current_instances * concurrency) , Cloud Run can provision new container instances, subject to scaling behavior, quotas, and capacity to absorb the load.

Concurrency Setting Optimal Workload Profile Architectural Rationale

Concurrency = 1 CPU-bound computation, image/video rendering, non-thread-safe runtimes (legacy Python/Ruby, C extensions) Ensures each container instance executes exactly one request at a time. Prevents CPU starvation and eliminates race conditions in non-thread-safe application code.

Concurrency = 80 (explicit example) Standard I/O-bound web services, REST APIs, Node.js / Go / Java async microservices Maximizes resource efficiency by multiplexing multiple incoming HTTP requests over asynchronous network threads within a single container.

Concurrency > 250 (up to 1000) Ultra-lightweight asynchronous microservices, reverse proxies, static API redirects Minimizes container instance sprawl and reduces overall compute cost for high-throughput, low-latency microservices. Requires adequate CPU and memory limits.

Exam Trap: CPU-heavy synchronous handlers can contend at high concurrency; I/O-bound single-threaded handlers can still overlap requests. Load-test latency and throughput, then consider reducing --concurrency (e.g., to 1 or 5) for compute-intensive tasks.

Cold Starts and Minimum Instances ( --min-instances )

By default, Cloud Run scales down to zero instances when no traffic is present ( --min-instances=0 ). When an incoming request arrives at an idle service, Cloud Run must provision container infrastructure, pull or load the image, execute the runtime binary, and wait for the application listening port to open. This introduces cold start latency (dependent on runtime, initialization and platform conditions).

To reduce baseline cold starts for latency-sensitive user-facing applications, configure minimum instances: gcloud run services update order-service --min-instances=2 --region=us-central1

Operational and Cost Characteristics of Min Instances:

Cloud Run keeps the specified number of container instances pre-warmed and ready to serve traffic immediately.

When no requests are active, idle min instances with default CPU throttling are billed at a discounted idle rate (covering allocated memory and base infrastructure), drastically lowering costs compared to fully active compute.

The warm baseline can absorb some requests; demand above that baseline and replacement instances can still incur cold starts.

Protecting Downstream Dependencies with Maximum Instances ( --max-instances )

Cloud Run can scale up rapidly to hundreds or thousands of container instances. While this ensures frontend resilience during traffic surges, unbounded horizontal scaling can instantly overwhelm downstream stateful systems (such as Cloud SQL database connection pools, legacy mainframe APIs, or third-party rate-limited services).

Configuring --max-instances enforces an upper ceiling on horizontal expansion: gcloud run services update order-service --max-instances=50 --region=us-central1

Calculating Safe Max Instances for Cloud SQL: If your Cloud SQL PostgreSQL instance supports a maximum of 500 connections, and your Cloud Run application maintains an internal connection pool of 10 connections per container instance, the nominal estimate is 50 * 10 = 500 , leaving no margin. That is unsafe: overlapping revisions, temporary excess instances, administration, and other clients need headroom. Select a lower limit and enforce a shared database-side pool limit; the instance maximum is not a strict connection invariant.

Official references checked October 18, 2026: Google Cloud 1 , Google Cloud 2 .