Cloud Run

Cloud Run runs containers as a managed service. You provide a container image that listens for HTTP requests on a port; the platform handles provisioning, scaling, load balancing, TLS certificates and availability. There are no servers, clusters or node pools to configure.

Because the unit of deployment is a standard container, you are not restricted in language or framework. If it runs in a container and serves HTTP, it runs here — which makes it far less constraining than earlier generations of serverless platforms.

For a large share of web services and APIs, Cloud Run is the shortest distance between working code and a production deployment. It removes a category of operational work — patching, capacity planning, cluster upgrades — that produces no value for most teams.

The economics matter as much as the convenience. Scaling to zero means a service with no traffic costs nothing. For internal tools, low-traffic APIs and development environments, this frequently changes the total cost by an order of magnitude compared with an always-on virtual machine.

• Service — a deployed container with a stable HTTPS URL. Each deployment creates a new immutable revision.
• Revision — a specific version of the service, including its image and configuration. Revisions are immutable, which makes rollback instant.
• Traffic splitting — sending a percentage of requests to a specific revision. This is what makes canary releases straightforward.
• Concurrency — how many simultaneous requests one container instance handles. Unlike most function platforms, this defaults well above one, which changes the cost model significantly.
• Cold start — the delay when a request arrives and no instance is running. Minimum instances keep containers warm at the cost of paying for idle capacity.
• Minimum and maximum instances — the floor that controls cold starts and the ceiling that protects downstream systems and your budget.
• Jobs — for work that runs to completion rather than serving requests, such as scheduled batch processing.
• Service identity — each service runs as a service account; give it only the permissions the code actually needs.

The exam framing is usually about operational burden rather than capability. When a scenario mentions a small team, a desire to minimise operations, or unpredictable traffic, the fully managed option is generally the intended answer.

• Public REST and GraphQL APIs that scale with demand and cost nothing overnight.
• Server-rendered web applications behind a global load balancer.
• Event handlers triggered by messages, storage changes or scheduled jobs.
• Internal tools that are used a few times a day and should not run a server continuously.
• Batch processing as a job — data transformation, report generation, scheduled maintenance.