If you don't understand serverless deployment, you will waste time managing servers you don't need and pay for compute power you never use. Cloud Run solves this by letting you deploy containerised applications without provisioning or operating any underlying infrastructure. For the PCD exam, mastering Cloud Run is essential because it represents Google's premier fully managed compute platform for running stateless containers in a serverless way.
Jump to a section
A simple way to picture Serverless Deployment with Cloud Run
A busy city park during a food truck festival. A new taco truck arrives and parks in a designated spot, but the owner doesn't need to build a permanent kitchen, hire a full waitstaff, or worry about what happens when the festival ends.
Instead, they hand their secret recipe—a Docker container image—to the festival organiser. The organiser (Cloud Run) handles everything: they give the truck a clean, prepped parking space (an isolated container instance), connect it to the festival's power and water (the underlying server infrastructure), and only charge the owner for the minutes the truck actually serves customers. If a huge lunch crowd arrives, the organiser magically summons a dozen identical taco trucks in adjacent parking spots (automatic scaling). If nobody shows up for an hour, all but one truck vanishes, and the owner pays nothing for that idle time (scale to zero). The owner never sees the organiser's clipboard full of vendor insurance, health permits, or parking logistics—that's the serverless part. They just update the recipe online, and the next day every truck serves the new salsa. This is exactly what Cloud Run does: it runs your containerised application on demand, scales it to zero when idle, and hides all the server management headaches behind a simple "deploy this image" command.
Cloud Run is a fully managed compute platform from Google Cloud that runs your application inside a container. A container is a lightweight, standalone, executable package that includes everything your software needs to run: code, runtime, system tools, libraries, and settings. Think of it as a self-contained lunchbox for your app.
Before Cloud Run, developers had to perform several time-consuming tasks to get an application online. They would provision virtual machines (VMs), configure the operating system, install a web server like Nginx or Apache, set up load balancers to distribute traffic, and configure auto-scaling rules to handle spikes in visitors. They also had to manage security patches, operating system updates, and monitor CPU usage to avoid outages. This was known as the "undifferentiated heavy lifting"—the tedious, non-unique work that every developer had to do but that added no direct business value.
Cloud Run eliminates that heavy lifting. You package your application as a container image (using a tool like Docker), push that image to Artifact Registry or Container Registry (Google's image storage services), and then deploy it to Cloud Run with a single command. Cloud Run automatically handles everything else:
Provisioning the server resources (CPU and memory) your container needs
Starting and stopping container instances based on incoming requests
Scaling your application up to handle thousands of concurrent users, even instantly from zero
Load balancing requests across multiple container instances
Encrypting traffic with HTTPS by default (using a managed TLS certificate)
Health checking and restarting containers that fail
Cloud Run uses a request-driven model. This means your container only runs when it receives a request. When no request is active, Cloud Run can scale the number of running container instances down to zero. You are charged only for the time your container actually processes requests—measured in increments of 100 milliseconds. This is often called "pay-per-use" or "scale-to-zero" pricing.
There are two execution environments for Cloud Run: the fully managed version (called Cloud Run fully managed) and Cloud Run for Anthos (which runs on your own Google Kubernetes Engine cluster). For the PCD exam, you need to focus on fully managed Cloud Run, as it is the serverless option that requires zero infrastructure management.
Each deployment to Cloud Run creates a new revision. A revision is a specific snapshot of your container configuration—the image version, environment variables, CPU and memory allocation, concurrency settings, and timeout. Revisions are immutable: once created, you cannot change a revision. If you update your application and deploy again, you get a new revision while the old one continues to exist. Cloud Run keeps a history of your recent revisions (by default the last 100) so you can roll back to a previous version instantly if something goes wrong.
You can control traffic routing between revisions. This means you can send 100% of your live traffic to the latest revision, or you can split traffic 90/10 between two revisions for canary deployments or A/B testing. Traffic splitting is done by percentage and can be updated without redeploying.
Cloud Run also supports environment variables, secrets (via Secret Manager), and Cloud SQL connections. It integrates natively with Cloud IAM for access control, Cloud Logging and Cloud Monitoring for observability, and Cloud Build for continuous deployment.
For the PCD exam, you should understand that Cloud Run is ideal for stateless applications (applications that do not store data on the local filesystem or in memory between requests). Examples include REST APIs, web applications, microservices, batch processing jobs, and event-driven functions (triggered by Cloud Pub/Sub, Cloud Storage events, or HTTP calls). Stateful applications, like databases, are not suitable for Cloud Run because container instances can be created or destroyed at any time.
Prepare your application
Write your application code (e.g., a Python Flask or Node.js Express app) that listens on the port specified by the environment variable PORT (default 8080). The application must be stateless: no data stored on the local filesystem or in memory between requests. Package your code into a Docker container image.
Build and push the container image
Use Cloud Build or Docker to create a container image that includes your application and all its dependencies. Push that image to Artifact Registry or Container Registry in your Google Cloud project. This step prepares the deployable artifact that Cloud Run will run.
Deploy the image to Cloud Run
Run the 'gcloud run deploy' command, specifying the service name, image location, region, and whether to allow unauthenticated access. Cloud Run creates a new revision of the service and starts routing traffic to it. You receive a unique HTTPS URL for your service.
Manage revisions and traffic
After deployment, you can update the service with new container images or configuration changes. Each update creates a new revision. Use 'gcloud run services update-traffic' to route a percentage of traffic to specific revisions, enabling canary rollouts or rollbacks.
Monitor and scale
Cloud Run automatically scales the number of container instances based on incoming traffic. Use Cloud Monitoring to track request latency, error rates, and concurrency. Adjust settings like 'max-instances', 'min-instances', and 'concurrency' as needed to balance cost and performance.
Secure and configure
Configure IAM permissions to control who can invoke your service. Add environment variables for configuration, and use Secret Manager to inject sensitive data like API keys. Optionally connect your service to a VPC network for private resource access.
A mid-sized e-commerce company, "QuickCart", needs to launch a new product recommendation microservice. The development team has built the service as a Node.js application packaged in a Docker container. They want to deploy it without hiring a dedicated operations engineer to manage servers.
Here is what the IT professional actually does, step by step:
First, they authenticate with Google Cloud using the gcloud command-line tool and set their project ID. They enable the Cloud Run API for the project.
Second, they build the container image using Docker and push it to Artifact Registry. The command might look like: 'gcloud builds submit --tag gcr.io/quickcart/recommendations:v1'. This uses Cloud Build, Google's managed CI/CD service, to build the image from source code and store it securely.
Third, they deploy the image to Cloud Run with a single command: 'gcloud run deploy recommendations --image gcr.io/quickcart/recommendations:v1 --platform managed --region us-central1 --allow-unauthenticated'. This tells Cloud Run to create a new service named 'recommendations' using the container image, run it in the us-central1 region, and allow anyone to invoke it via HTTP.
Fourth, Cloud Run automatically creates a revision. The IT professional receives a fully qualified HTTPS URL (e.g., https://recommendations-abc123-uc.a.run.app). They can now test the endpoint by sending a curl request.
Fifth, the team runs performance tests. The service is slow under load, so the IT professional increases the CPU allocation: 'gcloud run services update recommendations --cpu 2'. Cloud Run updates the service with a new revision containing the increased CPU setting.
Sixth, they need to roll out a new version of the algorithm to 10% of users first. They deploy the new image as a new revision: 'gcloud run deploy recommendations --image gcr.io/quickcart/recommendations:v2'. Then they split traffic: 'gcloud run services update-traffic recommendations --to-revisions=recommendations-00001=90,recommendations-00002=10'. Now 90% of users see the old algorithm and 10% see the new one. After monitoring error rates for a day, they move all traffic to the new revision.
Seventh, they set up a Cloud Scheduler job to call the service every hour to keep it "warm" if latency is critical (optional, since Cloud Run can start from cold in under a second).
Eighth, they integrate with Cloud Monitoring to set an alert if the service's error rate exceeds 1% or if p99 latency goes above 500ms.
The IT professional never touches a virtual machine, never patches an operating system, and never configures a load balancer. They manage the entire lifecycle through revisions and traffic routing. If a bug is found, they roll back to the previous revision in seconds with one command: 'gcloud run services update-traffic recommendations --to-revisions=recommendations-00001=100'.
The PCD exam tests 'Serverless Deployment with Cloud Run' thoroughly. You must understand the difference between Cloud Run (serverless containers) and Cloud Functions (serverless functions). Cloud Run gives you a full container runtime; Cloud Functions gives you a single-purpose function with limited runtime and dependencies. The exam loves to ask: "When would you choose Cloud Run over Cloud Functions?" The correct answer is: when you need to run a complete web framework (like Express.js, Django, or Spring Boot), use a custom runtime (like Python with native extensions), or need more flexible scaling and concurrency control.
Specific topics the exam focuses on:
Revision management: understand that every deployment creates a new revision. Revisions are immutable. You can manage traffic between revisions. You can roll back to any previous revision that still exists (the last 100 by default, configurable). The exam presents scenarios where you need to revert a bad deployment; the answer is to use 'gcloud run services update-traffic' to send traffic back to an older revision.
Concurrency and scaling: Cloud Run allows you to set the maximum number of concurrent requests each container instance can handle (default is 80, configurable up to 1000). The exam tests that setting concurrency too low wastes resources, while setting it too high can overload your application. Also, Cloud Run can scale to zero when idle; the exam asks about cold starts (the latency when scaling from zero to one) and how you can mitigate cold starts (e.g., setting 'min-instances' to 1 to keep one instance always warm).
Environment variables and secrets: the exam expects you to know how to pass configuration via environment variables ('--set-env-vars') and how to securely inject secrets using Secret Manager (via '--set-secrets'). You cannot store secrets directly in the container image.
Execution environment: Cloud Run offers two CPUs: standard (vCPU) and first-generation (only for backward compatibility). The exam tests that you can choose CPU allocation at deploy time and that CPU is always allocated (even when idle) if you set '--cpu-throttling' to false (for tasks that need background processing).
IAM roles and authentication: the exam tests the difference between '--allow-unauthenticated' (public HTTP endpoint) and '--no-allow-unauthenticated' (requires IAM authentication). For internal services, you use Cloud IAM with the 'roles/run.invoker' role.
VPC connectivity: Cloud Run can connect to a VPC network via VPC connectors or serverless VPC access. The exam tests this for accessing private resources like Cloud SQL or on-premises databases.
Minimum instance count: you can set '--min-instances' to keep N instances always running, which reduces cold starts but increases cost. The exam asks about the trade-off: lower latency for start-up sensitive apps versus higher cost.
Timeout and memory: the exam tests that each request has a maximum timeout (default 5 minutes, max 60 minutes) and that you specify memory per instance (default 256MB, max 32GB). If your request takes longer than the timeout, Cloud Run terminates it.
Common traps in the exam:
Confusing revisions with services (a service can have many revisions, but a revision belongs to exactly one service).
Thinking that container instances persist state across requests (they are stateless).
Believing that Cloud Run supports WebSockets (it does, but only with certain limitations on the managed platform).
Forgetting that Cloud Run containers run in a sandboxed environment with a read-only filesystem (except the /tmp directory).
Key definitions to memorise:
Cold start: the first request to a newly created container instance, which takes longer because the container must start.
Concurrency: the number of simultaneous requests a single container instance can handle.
Revision: an immutable snapshot of your deployment configuration.
Service: a collection of revisions with traffic routing rules.
Cloud Run is a fully managed serverless compute platform that runs stateless containers and scales to zero when idle.
Each deployment creates an immutable revision; you can route traffic between revisions and roll back instantly.
Cloud Run only charges you for actual request processing time in 100-millisecond increments, not for idle capacity.
Your container must listen on the port specified by the PORT environment variable (default 8080) and must be entirely stateless.
You can split traffic between revisions (e.g., 90% old, 10% new) for canary deployments and A/B testing.
Cold starts occur when scaling from zero; use the 'min-instances' setting to keep one instance warm if low latency is critical.
Cloud Run integrates with Cloud IAM, Secret Manager, Cloud Logging, and Cloud Monitoring out of the box.
The maximum request timeout is 60 minutes, and the maximum concurrency per instance is 1000 concurrent requests.
These come up on the exam all the time. Here's how to tell them apart.
Cloud Run (Fully Managed)
No infrastructure management required; Google manages servers.
Billed per request and compute time used.
Scales to zero automatically when idle.
Cloud Run for Anthos
Runs on your own GKE cluster; you manage the Kubernetes nodes.
Billed for the underlying GKE cluster resources (VMs).
Cannot scale below 1 node; typically higher minimum cost.
Cloud Run
Runs full container images with any runtime or dependency.
Supports up to 1000 concurrent requests per instance.
Best for microservices, REST APIs, and web applications.
Cloud Functions
Runs single-purpose functions with limited runtimes (Node.js, Python, etc.).
Concurrency is 1 per function instance (each request gets a new instance).
Best for simple event-driven processing (e.g., file uploads, Pub/Sub messages).
Revision (Cloud Run)
An immutable snapshot of a deployment configuration.
Created every time you deploy or update the service.
Can receive a percentage of traffic independently.
Service (Cloud Run)
A logical grouping of revisions with a single DNS endpoint.
Provides traffic routing and revision management.
Has a name and region; revisions belong to exactly one service.
Mistake
Cloud Run always keeps at least one container instance running, so it never scales to zero.
Correct
Cloud Run can scale to zero by default, meaning no container instances run when there are no incoming requests, and you pay nothing during that idle time. You can optionally set a minimum number of instances to prevent scale-to-zero, but this is not the default.
Beginners equate 'serverless' with 'always available' and assume a serverless platform must keep something running. In reality, the serverless benefit is that you pay only for actual usage.
Mistake
You must rewrite your application to use a special Cloud Run API or SDK to run on it.
Correct
Cloud Run runs any stateless application that runs in a Docker container and listens on HTTP requests on port 8080. You do not need to use any Google-specific SDK inside your container.
This misconception stems from experience with proprietary serverless platforms like AWS Lambda, which enforce a specific function signature. Cloud Run is more flexible, as it uses standard containers.
Mistake
Cloud Run revisions can be updated in place, so you can change a revision's configuration after it is created.
Correct
Revisions are immutable. Once created, you cannot modify a revision's configuration, environment variables, or image. If you want to change something, you must deploy a new revision. The old revision remains available for rollback.
Beginners confuse 'updates' (which create new revisions) with 'modifications' (which are not allowed). The word 'update' in the gcloud command creates a new revision, not modifies an existing one.
Mistake
Cloud Run supports any port by default, so you can configure your container to listen on port 5000.
Correct
Cloud Run only forwards requests to your container on the port specified by the 'PORT' environment variable, which defaults to 8080. Your container must listen on the port specified in this variable to receive requests.
Many developers are used to running containers on arbitrary ports. Cloud Run abstracts away port configuration by enforcing a single standardised port for simplicity.
Mistake
Cloud Run charges you for the time your container is deployed, even if it is idle.
Correct
Cloud Run charges only for the time your container actually processes requests, measured in 100-millisecond increments. When no requests are incoming and scale-to-zero is active, you pay nothing for compute.
This is a carryover from traditional VM or Kubernetes pricing, where you pay for allocated resources regardless of usage. Serverless billing is fundamentally different.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, Cloud Run is designed for stateless applications only. Container instances can be created or destroyed at any time, so any data stored locally is lost. For stateful workloads, use Google Kubernetes Engine with persistent volumes or a managed database like Cloud SQL.
A cold start occurs when a request arrives and no container instance is running, so Cloud Run must start a new instance. To avoid cold starts, set the 'min-instances' parameter to a value like 1, which keeps at least one instance always warm, but this incurs cost even when idle.
Cloud Run runs any containerised application that listens on HTTP, giving you full control over the runtime and dependencies. Cloud Functions runs only individual functions with limited runtimes (e.g., Node.js, Python, Go) and is better for simple event-driven tasks. Choose Cloud Run for full web frameworks or custom runtimes.
Yes. Cloud Run can connect to Cloud SQL using Serverless VPC Access or a VPC connector, and you can use the Cloud SQL Proxy or Unix domain sockets for secure authentication. The connection is private and does not go through the public internet.
Use the 'gcloud run services update-traffic' command to send 100% of traffic to an older revision. You can see a list of recent revisions with 'gcloud run revisions list'. By default, Cloud Run keeps the last 100 revisions for rollback.
Yes, but with a maximum request timeout of 60 minutes. For longer tasks, consider Cloud Run Jobs (for batch jobs) or Cloud Tasks (for asynchronous processing). Cloud Run is not designed for infinite background processes.
You've finished Serverless Deployment with Cloud Run. Continue through the PCD study guide to build a complete picture of the exam.
Done with this chapter?