Your operations team has asked you to help diagnose a performance issue in a production application that runs on Compute Engine. The application is dropping requests that reach it when under heavy…

Question

Options

• AChange the autoscaling metric to agent.googleapis.com/memory/percent_used.
• BRestart the affected instances on a staggered schedule.
• CSSH to each instance and restart the application process.
• DIncrease the maximum number of instances in the autoscaling group.

• A
  5% (2)
• B
  9% (4)
• C
  2% (1)
• D
  84% (37)

Explanation

Increasing the maximum instance count (D) is correct because the autoscaler is already working as designed - it wants to add more instances to handle the CPU load, but the configured ceiling is blocking it. Raising the maximum immediately allows new instances to spin up and absorb the traffic, which directly addresses both the CPU saturation and dropped requests with minimal delay.

Why the distractors fail:

• A is wrong because the bottleneck is CPU, not memory - switching the autoscaling metric to memory would make the scaler blind to the actual problem and could prevent new instances from launching when they're needed.
• B is wrong because staggered restarts temporarily reduce your already-insufficient capacity, making the traffic-dropping problem worse before it gets better.
• C is wrong because manually SSH-ing to each instance is slow, error-prone at scale, and briefly takes each instance offline - again reducing capacity during a crisis rather than expanding it.

Memory tip: Whenever a question says "autoscaling has reached its limit," that phrase is a direct signal that the answer involves raising the limit - the system is trying to help itself, you just need to get out of the way.

No community discussion yet for this question.