Answer guide
Read the answer guide
Cloud Run suits a stateless, containerised service that handles requests or events and can scale with demand, including down to zero. You hand over a container and the platform manages servers, scaling and much of the networking, so there is no cluster to patch or size. Trade-offs to weigh are cold starts, request time limits, concurrency settings and less control over the environment. Costs also differ by traffic shape. Before choosing, I would list the service's requirements against the platform limits in current documentation and run a small load test.
What the interviewer is assessing
Ability to match a workload to a managed serverless container platform and to know where Kubernetes is still justified.
A strong answer covers
- Cloud Run suits stateless containerised services handling requests or events that scale with demand, including to zero.
- You hand over a container and the platform manages servers, scaling and networking, so no cluster to patch or size.
- Weigh cold starts, request time limits, concurrency settings and less control over the environment.
- Costs differ by traffic shape, which can favour either option.
- List requirements against current platform limits and run a small load test before choosing.
Common mistakes
- Choosing Kubernetes for a simple stateless API because it is what everyone uses.
- Ignoring cold starts, timeouts or concurrency behaviour when moving to Cloud Run.
Practise a follow-up
- How would you reduce the impact of cold starts on a latency-sensitive endpoint?
- What kind of workload would push you back to Kubernetes?