Cloud Run makes it easy to deploy and scale containerised workloads on Google Cloud without managing infrastructure. Understanding the distinction between services and jobs, concurrency models, CPU allocation options, and sidecar support unlocks Cloud Run's full potential.
0 / 5 completed
1 / 5
What is the fundamental difference between a Cloud Run Service and a Cloud Run Job?
A Cloud Run Service is designed for request-driven workloads: it starts instances when requests arrive and scales to zero when idle. A Cloud Run Job runs a container to completion for batch or scheduled tasks — no HTTP server needed, billed only for task execution time.
2 / 5
You set a Cloud Run Service's concurrency to 1. What is the effect on scaling?
Cloud Run's concurrency setting controls how many simultaneous requests a single instance handles. Setting it to 1 means each instance is exclusive to one request — Cloud Run must scale out a new instance for every additional concurrent request, suitable for non-thread-safe workloads.
3 / 5
What does CPU allocation: always on mean for a Cloud Run Service, compared to the default CPU is only allocated during request processing?
By default, Cloud Run throttles CPU to near-zero between requests. Always-on CPU keeps the full vCPU allocated at all times, allowing background goroutines, cron tasks, and cache warm-up between requests — but instances are billed continuously, not just per request.
4 / 5
Why would you set min-instances greater than zero on a Cloud Run Service?
Setting min-instances > 0 keeps at least that many instances alive and warm at all times. This eliminates cold starts for those instances (at the cost of idle billing), which is valuable for latency-sensitive services that cannot afford the startup time of a fresh container.
5 / 5
A Cloud Run Service is configured with a sidecar container. What use cases does this enable that a single-container setup cannot easily support?
Cloud Run's sidecar support (multi-container services) allows co-locating auxiliary containers — like an Envoy proxy for mTLS, a Fluent Bit log shipper, or a config agent — alongside the main container. They share the network namespace (localhost) and scale together as a unit.