A cloud operations engineer notices that the managed instance group 'my-mig' has been scaling up frequently, but the application performance is still degraded. The CPU utilization metric shows high values. What is most likely the issue?
The autoscaler is scaling based on a metric that does not accurately represent the application's real load, which is why performance remains degraded even as instances increase. CPU utilization is often a poor proxy for managed instance groups because workloads can be I/O-bound, memory-bound, or dependent on external queues and services. A custom metric such as request latency, queue depth, or concurrent requests directly measures the workload bottleneck and is recommended for autoscaling policies. Switching to a metric that aligns with the application's actual performance signals would enable the autoscaler to make precise scaling decisions and maintain target service levels.
Why this answer
The autoscaler is using CPU utilization as the scaling metric, but high CPU does not necessarily correlate with application performance degradation. If the application is bottlenecked on memory, I/O, or request queuing, CPU may remain high while throughput suffers. A custom metric (e.g., requests per second, latency, or queue depth) would better reflect actual application load and enable more accurate scaling decisions.
Exam trap
The trap here is that candidates assume high CPU utilization always means the application needs more compute capacity, but the question tests the understanding that the scaling metric must be aligned with the actual performance bottleneck, not just a generic system metric.
How to eliminate wrong answers
Option A is wrong because the target size being lower than needed capacity would prevent scaling up sufficiently, but the question states the instance group is scaling up frequently, so the autoscaler is actively adding instances; the issue is that scaling up is not fixing the performance problem. Option B is wrong because preemptible VMs being reclaimed would cause instance churn and potential performance degradation, but the question does not mention preemptible VMs, and the symptom of frequent scaling up with high CPU is not directly caused by preemption. Option C is wrong because a cooldown period that is too long would delay scaling down, not prevent scaling up; the issue here is that scaling up is happening but not resolving the degradation, so the cooldown period is not the root cause.