Cloud Run Study Notes

Cloud Run is a fully managed serverless platform that runs stateless containers and automatically scales them with incoming requests, including to zero when idle. You supply a container image, and Google handles infrastructure, load balancing, and TLS. It fits HTTP services, APIs, and webhooks that do not need a cluster.

Key facts

• Cloud Run services run containers that listen for HTTP requests on the port defined by the PORT environment variable, and each deployment creates an immutable revision.
• Traffic can be split between revisions by percentage, which enables gradual rollouts, canary releases, and quick rollback by shifting traffic back to a previous revision.
• By default a service can scale to zero instances when idle, which removes compute charges, though the first request after idle may experience a cold start.
• You can set minimum instances to keep containers warm, and maximum instances and per-instance concurrency to control cost and protect downstream systems.
• Cloud Run supports both fully managed services and jobs: services respond to requests or events, while jobs run a container to completion for tasks such as migrations or batch processing.
• A service is private by default in the sense that you choose its invokers: you can allow unauthenticated access publicly or require IAM authentication for internal callers.
• Serverless VPC Access connectors, or Direct VPC egress where available, let Cloud Run instances reach resources on a VPC network such as Memorystore or private Cloud SQL instances.
• Cloud Run builds on open Knative concepts, and billing is based on the CPU and memory allocated and used during request processing, rounded according to the service's billing model.

What the exam expects you to know

• Recognizing Cloud Run as the answer for stateless containers that must scale to zero with no infrastructure or cluster management.
• Using revisions and traffic percentages to roll out, test, and roll back a new version without downtime.
• Configuring invoker permissions with IAM, and understanding the difference between a public service and one restricted to authenticated callers.
• Connecting a service to VPC resources and to Cloud SQL, and knowing when a connector or private networking configuration is required.
• Setting concurrency, minimum and maximum instances, and CPU and memory to balance latency, cold starts, and cost in a scenario.
• Distinguishing Cloud Run services from Cloud Run jobs when the workload is a finite task rather than a request handler.

Cloud Run vs App Engine: when to use which

Choose Cloud Run when you already package your application as a container, need a specific language runtime or system library, or want to bring any HTTP-serving image and scale it to zero. Choose App Engine when you prefer a platform-managed runtime where you deploy source code and let Google supply the language environment. The decision criteria are packaging and portability: Cloud Run accepts any container that listens on a port, while App Engine is simpler for supported runtimes but ties you more closely to its environment. See also the App Engine notes.

Useful gcloud commands

gcloud run deploy my-service --image=gcr.io/my-project/my-image --region=us-central1
gcloud run services list --region=us-central1
gcloud run services update-traffic my-service --to-revisions=my-service-00002=10 --region=us-central1

Common exam traps

• Assuming Cloud Run is only for short web requests: it also runs jobs to completion and can process events, but it is designed for stateless work, not for storing local state on disk.
• Thinking local filesystem writes persist: the container filesystem is in-memory and ephemeral, so data that must survive must go to Cloud Storage, a database, or another external service.
• Forgetting cold starts after scaling to zero: setting minimum instances reduces cold starts but means you pay to keep idle containers warm.
• Exposing a service unintentionally: allowing allUsers the invoker role makes a service public, which is wrong for internal APIs that should require authentication.

Frequently asked questions

How does Cloud Run handle a new deployment safely?

Every deployment creates a new immutable revision while the previous revision keeps running. You can send a small percentage of traffic to the new revision first, watch logs and error rates, then shift all traffic when it looks healthy. If problems appear, you shift traffic back to the earlier revision for an almost instant rollback.

Can Cloud Run connect to a private database?

Yes. A service can reach VPC resources through a Serverless VPC Access connector or Direct VPC egress, and it can connect to Cloud SQL using the Cloud SQL Auth Proxy integration built into Cloud Run. You configure the connector, subnet, and Cloud SQL connection name on the service, then use private addresses from your application code.

What is the difference between a Cloud Run service and a job?

A service is long-lived in concept: it receives HTTP requests or events, scales with demand, and waits for the next request. A job runs one or more container instances to completion and then exits, with no endpoint to call. Use a job for database migrations, scheduled reports, and other finite tasks.

Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.