Cloud Digital Leader Scaling with Google Cloud operations Practice Question

You are monitoring Compute Engine instances with Cloud Monitoring. You notice that autoscaling is not triggering even though CPU utilization is above 80% for several minutes. The managed instance group has autoscaling based on CPU utilization with a target of 0.8. What is the most likely cause?

⚠ Common exam trap

The trap here is that candidates often focus on the CPU target and cool-down settings, overlooking the hard boundary of the maximum instance count, which is a fundamental constraint in autoscaling logic.

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

✓

The maximum number of instances is already reached.

The most likely cause is that the managed instance group has already reached its configured maximum number of instances. When the maximum instance count is hit, the autoscaler cannot add more instances even if CPU utilization exceeds the target of 0.8 (80%). This is a common boundary condition in autoscaling logic where the scaling policy is overridden by the hard limit.

Answer analysis

Option-by-option breakdown

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

✓
The maximum number of instances is already reached.
Why this is correct
The Managed Instance Group (MIG) autoscaler's scaling decision is fundamentally constrained by the group's `maxNumReplicas`/max size. When the current running instance count equals this upper bound, the autoscaler will not add new VMs even if the aggregated CPU utilization remains persistently above the target threshold, because that would violate the configured capacity limit. In this state, the autoscaler is effectively 'capped' and any observed lack of scale-out is the intended, expected behavior, not a failure of the monitoring or autoscaling logic.
✗
The autoscaler is disabled.
Why it's wrong here
If the autoscaler is disabled, the MIG will not perform any automatic scaling operations at all: it will ignore all utilization signals and keep the instance count static. However, the question explicitly states autoscaling is configured and active, and Cloud Monitoring is being used to observe the ongoing situation, so a disabled autoscaler would contradict that premise. Additionally, if it were disabled, the instance count would remain at its current value regardless of load, but the correct diagnosis requires examining the group's capacity bounds first.
✗
The minimum number of instances is set too high.
Why it's wrong here
Setting a high `minNumReplicas` only establishes a lower bound on the instance count; it does not constrain how many instances can be added when load rises. The autoscaler's scale-out decision uses the current utilization against the target utilization, and even if the minimum is high, as long as the group size is below the maximum, the autoscaler can add instances. A high minimum might cause a baseline that is unnecessarily costly, but it would never prevent scaling up, because the autoscaler's lower bound only affects the floor, not the ceiling.
✗
The cool-down period is too long.
Why it's wrong here
The cool-down period (also known as 'cool-down' in GCP autoscaling) is the waiting time after a newly added instance is booted before that instance's utilization is considered in autoscaling decisions. A long cool-down can delay when new VMs contribute to the load averaging, but it does not block scale-out events triggered by existing instances. If CPU utilization remains high on current VMs after the cool-down interval expires, the autoscaler will still add more instances, so this is not the reason scaling never happens. In contrast, reaching the maximum cap is a permanent, condition-based block until the cap is raised or load drops.

Go deeper

Cloud Digital Leader Scaling with Google Cloud operations Practice Question

Why each option matters

Option-by-option breakdown

Related to this question