Google PCA Manage implementation of cloud architecture Practice Question

A company runs a critical application on a managed instance group (MIG) with autoscaling enabled. The application experiences sudden traffic spikes, and the team wants to ensure that new instances are added quickly while maintaining cost efficiency. They also want to avoid over-provisioning. Which autoscaling metric should they use?

⚠ Common exam trap

The trap here is assuming that CPU utilization is always the most responsive metric for autoscaling, but for web applications behind a load balancer, serving capacity provides a more direct and immediate signal of traffic load.

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

✓

HTTP load balancing serving capacity

HTTP load balancing serving capacity is the best metric for scaling a web application behind an HTTP(S) load balancer because it directly measures the load on the backend instances. It enables rapid scaling in response to traffic spikes and helps maintain cost efficiency by avoiding over-provisioning. Other metrics may not accurately reflect the incoming traffic or may introduce delays.

Answer analysis

Option-by-option breakdown

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

✗
CPU utilization
Why it's wrong here
CPU utilization is a common metric, but it may not reflect sudden traffic spikes accurately if the application is I/O-bound or if CPU usage lags behind traffic increases. It might cause delayed scaling, leading to performance degradation during spikes. Additionally, CPU utilization can be inefficient for cost if the application has variable CPU usage unrelated to load.
✗
Custom metric based on memory usage
Why it's wrong here
Memory usage can be a useful custom metric, but it may not correlate directly with traffic spikes for all applications. If the application has a memory leak or high baseline memory usage, it could cause unnecessary scaling. Additionally, setting up custom metrics requires additional configuration and may introduce latency in scaling decisions, making it less responsive to sudden spikes compared to load balancer metrics.
✗
Cloud Pub/Sub queue depth
Why it's wrong here
Cloud Pub/Sub queue depth is used for autoscaling based on the number of undelivered messages, which is suitable for asynchronous worker patterns. However, this application is a critical web application likely serving synchronous requests, not processing messages from a queue. Using Pub/Sub queue depth would not reflect the actual traffic to the application and could lead to incorrect scaling decisions.
✓
HTTP load balancing serving capacity
Why this is correct
HTTP load balancing serving capacity is a metric that measures the utilization of the load balancer's backend capacity. It directly reflects the incoming traffic and can trigger scaling based on the actual load, allowing quick response to traffic spikes. This metric is ideal for web applications behind an HTTP(S) load balancer, as it scales based on the number of requests and avoids over-provisioning by matching capacity to demand.

Go deeper

Google PCA Manage implementation of cloud architecture Practice Question

Why each option matters

Option-by-option breakdown

Related to this question