Google ACE Planning and Configuring a Cloud Solution Practice Question

A company wants to use Cloud Run to deploy a containerized API that requires up to 8 GB of memory per request. The API experiences unpredictable traffic spikes. They want to minimize cost while ensuring fast cold starts. Which configuration should they use?

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

✓

Set min-instances to 1 and max-instances to a value that handles peak traffic with CPU throttled

Cloud Run supports up to 8 GB memory per container (as of 2024). Setting min-instances to a small number (e.g., 1) reduces cold starts, while max-instances limits costs during spikes. CPU boost can also speed up cold starts. Using CPU always allocated increases costs, so CPU throttled (default) is fine. The question emphasizes cost minimization, so setting a minimal min-instances is appropriate.

Answer analysis

Option-by-option breakdown

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

✗
Use Cloud Run jobs instead of Cloud Run service
Why it's wrong here
Cloud Run jobs are designed for batch workloads that run to completion, such as data processing or ETL pipelines, not for serving continuous HTTP traffic. A Cloud Run job does not provide a stable URL endpoint or autoscaling based on incoming request load, so deploying the API there would make it inaccessible via HTTPS. Thus, while jobs might be appropriate for a one-off container task, they cannot replace a Cloud Run service for an application that must handle unpredictable real-time requests.
✗
Deploy the container to GKE Autopilot with a single pod
Why it's wrong here
Deploying to GKE Autopilot with a single pod fails to address unpredictable traffic spikes and minimise cost, as it lacks Cloud Run's rapid scale-to-zero capability, leading to higher expenditure during idle periods and slower cold starts. Autopilot is tempting for its managed Kubernetes experience, abstracting node management. It would be a suitable choice for applications requiring persistent connections, specific Kubernetes features, or where sustained high resource utilisation makes Cloud Run's request-based billing less cost-effective.
✗
Set max-instances to a high number and min-instances to 0 with CPU always allocated
Why it's wrong here
Setting max-instances very high and min-instances to 0 with CPU always allocated combines a high cost ceiling with no pre-provisioned warm instances. With min-instances=0, the service scales down to zero during idle periods, meaning the first request after idle incurs a cold start latency that can be seconds. CPU always allocated also charges for CPU time even when no requests are being processed, increasing cost unnecessarily; additionally, a very high max-instances limit risks runaway billing if a traffic spike or a bug triggers rapid scaling beyond actual need.
✓
Set min-instances to 1 and max-instances to a value that handles peak traffic with CPU throttled
Why this is correct
Setting min-instances to 1 keeps one container instance always warm, eliminating the cold start for the first request after idle periods. A max-instances value calibrated to peak traffic caps both concurrent capacity and monthly cost, preventing unbounded scaling. CPU throttled (the default) charges only for CPU time used while processing requests, so the idle warm instance costs nothing for CPU, making this configuration both cost-effective and responsive to unpredictable traffic spikes.

Go deeper

Google ACE Planning and Configuring a Cloud Solution Practice Question

Why each option matters

Option-by-option breakdown

Related to this question