Google ACE Using Cloud Run for a stateless application Practice Question

A company is using Cloud Run for a stateless application. The application sometimes fails with HTTP 503 errors when traffic spikes. Which action should the team take to improve reliability?

⚠ Common exam trap

Test-takers frequently confuse liveness probes (which check container health) with scaling mechanisms, or assume that adding a CDN or switching to Cloud Functions will magically absorb traffic spikes, when the root cause is simply hitting the instance cap.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Increase the maximum number of container instances.

HTTP 503 errors during traffic spikes indicate that Cloud Run is scaling out but hitting the maximum number of container instances limit, causing new requests to be rejected. Increasing the maximum number of container instances allows Cloud Run to spin up more concurrent containers to handle the burst, directly improving reliability under load.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Configure a liveness probe with a higher initial delay.
Why it's wrong here
Liveness probe configuration only controls how Cloud Run assesses container health and restarts unhealthy instances. It does not influence the number of instances or their capacity to handle concurrent requests. Increasing the initial delay might even keep a failing container alive longer, potentially increasing 503s rather than reducing them. The correct fix is to raise the max container instance count to allow more parallel execution.
✓
Increase the maximum number of container instances.
Why this is correct
Raising the maximum number of container instances directly increases the scaling ceiling for the Cloud Run service, so the platform can allocate more instances when the current set is saturated. When all running instances are at full concurrency and the max instance count has been reached, excess requests are rejected with HTTP 503. By increasing this limit, the service can spawn additional containers to absorb the load, addressing the capacity shortfall at its root.
✗
Use Cloud Functions instead of Cloud Run.
Why it's wrong here
Migrating to Cloud Functions does not eliminate the underlying scaling constraint; it simply swaps one serverless platform for another with its own instance limits and sometimes higher cold-start latency. Cloud Functions also has a configurable maximum instance count and can return 503 errors when that limit is hit. This move adds migration risk and operational overhead without resolving why the Cloud Run service is hitting its instance ceiling.
✗
Enable HTTP load balancing with Cloud CDN.
Why it's wrong here
HTTP load balancing with Cloud CDN places a caching layer at Google's edge, which can offload cached static content and reduce requests that reach the origin, but it does not increase the compute capacity of the Cloud Run service. For dynamic requests or APIs that cannot be cached, the origin still receives the same load, so 503s from insufficient container instances will persist. Cloud CDN does not affect the maximum instance count or concurrency settings that actually govern Cloud Run's scaling.

Go deeper

Google ACE Using Cloud Run for a stateless application Practice Question

Why each option matters

Option-by-option breakdown

Related to this question