mediumMultiple ChoiceObjective-mapped
Google ACE A startup is building a mobile app backend Practice Question
A startup is building a mobile app backend. Traffic is highly variable: 10 requests/second at night, peaking to 50,000 requests/second during business hours. The backend is stateless. Which compute option best handles this traffic variability with minimal cost and operational effort?
⚠ Common exam trap
Google Cloud often tests the misconception that managed instance groups or GKE are more 'powerful' or 'flexible' for high traffic, but the trap here is ignoring the operational effort and cost of idle resources; candidates overlook that serverless options like Cloud Run can handle 50,000 req/s with proper concurrency tuning and are far simpler for stateless apps.
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
✓
Cloud Run with concurrency and max-instances configured.
Cloud Run is the best choice because it is a fully managed serverless platform that scales from zero to thousands of requests per second automatically, handling the extreme variability from 10 to 50,000 requests/second without provisioning overhead. By configuring concurrency (e.g., 80 concurrent requests per container) and max-instances, you cap costs while Cloud Run's autoscaling adds or removes container instances based on incoming traffic, making it ideal for stateless workloads with minimal operational effort.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Compute Engine managed instance group with autoscaling.
Why it's wrong here
A managed instance group (MIG) autoscaler reacts to utilization metrics like CPU or requests per second, but its scaling decisions occur at the instance level and require time to provision new VMs and initialize the application, typically taking minutes. Also, an autoscaler must maintain a configured minimum number of instances even when traffic drops to zero, so idle-night costs remain. To sustain a 50,000 RPS spike from a low baseline, you'd need aggressive over-provisioning or accept latency from scaling lag.
- ✓
Cloud Run with concurrency and max-instances configured.
Why this is correct
Cloud Run is a serverless container platform that automatically provisions instances based on incoming requests, and because each container instance can serve multiple concurrent requests (based on the concurrency setting), it can handle 50,000 RPS with a relatively small number of instances. With max-instances configured, you control the upper bound, receiving 429 errors if exceeded, but the default scaling can spin up thousands of instances in seconds to absorb spikes. When no traffic arrives at night, Cloud Run scales to zero instances, so you pay only for requests, making it the most cost-effective and responsive choice.
- ✗
GKE cluster with Horizontal Pod Autoscaler.
Why it's wrong here
The Horizontal Pod Autoscaler adjusts pod count based on CPU or custom metrics, but the underlying GKE node pool must always have at least one node running, so even with zero traffic you incur node costs overnight. Scaling a new node requires provisioning a VM and scheduling pods, which takes longer than Cloud Run's instantaneous request-driven instance creation. Additionally, HPA typically reacts to observed metrics over a 30-second window, making it slower to handle a sudden 50,000 RPS burst without excessive pre-provisioned capacity.
- ✗
App Engine Standard environment with automatic scaling.
Why it's wrong here
The App Engine Standard environment does scale to zero and can handle rapid traffic increases, so it is not inherently incapable of this workload. However, it restricts applications to specific runtimes and sandbox constraints, meaning you cannot freely use custom container images or certain libraries, which reduces flexibility for a service needing 50,000 RPS. Cloud Run provides the same request-based autoscaling with full container portability, making App Engine Standard the weaker option when the workload is already containerized or needs custom dependencies.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
Learn chapter
Google Cloud Platform Overview
Key term
Cloud Run
Cloud Run is a fully managed compute platform from Google Cloud that lets you run containerized applications in a serverless environment, automatically scaling from zero to thousands of requests.
Key term
Serverless
Serverless is a cloud computing model where the cloud provider manages the servers, and you only pay for the actual compute time your code uses, without having to worry about provisioning or maintaining infrastructure.
About these practice questions
One of 769 original ACE practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This ACE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the ACE exam.