Cloud Digital Leader Scaling with Google Cloud operations Practice Question
Exhibit
Refer to the exhibit.
```json
{
"insertId": "1a2b3c4d5e",
"jsonPayload": {
"status": "SCALING_UP",
"instanceGroup": "my-mig",
"targetSize": 10,
"currentSize": 5,
"reason": "AutoScaler triggered by CPU utilization > 80% for 5 minutes"
},
"resource": {
"type": "gce_instance_group",
"labels": {
"instance_group_name": "my-mig",
"zone": "us-central1-a"
}
},
"severity": "INFO",
"timestamp": "2025-02-15T14:30:00Z"
}
```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?
⚠ Common exam trap
Many exam-takers 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.
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 scaling metric is not appropriate; consider using a custom metric that better reflects application load.
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.
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 target size is set to 10, which is lower than the current needed capacity.
Why it's wrong here
The log shows currentSize is 5 and targetSize is 10, meaning the autoscaler is actively scaling out toward its configured target. If the application is still degraded after reaching target size, the issue is not that the target is too low, but that the chosen metric (e.g., CPU utilization) does not capture the real bottleneck, such as memory pressure or request latency. The target size is a scaling limit, not a direct capacity guarantee; insufficient capacity would show the autoscaler pinned at the max with unmet demand, which is not the case here.
- ✗
The instance group is using preemptible VMs which are being reclaimed frequently.
Why it's wrong here
The exhibit provides no evidence that preemptible (spot) VMs are in use, nor does it show any preemption events. Preemptible VMs are reclaimed by Google Cloud when capacity is needed elsewhere, which would manifest as sudden drops in instance count or specific lifecycle events in the logs. Since the log shows a monotonic increase from 5 toward 10 instances, there is no indication of frequent reclamation disrupting the group, and even if spot VMs were used, the autoscaler would immediately attempt to replace them, not exhibit a steady scale-out toward a target.
- ✗
The autoscaler is using a cooldown period that is too long, preventing it from scaling down.
Why it's wrong here
The log indicates the autoscaler is scaling up (currentSize 5, targetSize 10), so a long cooldown period would affect how quickly the autoscaler reacts to changes, not prevent scale-down. A prolonged cooldown can delay scaling decisions, but during an active scale-up, it would only slow the addition of instances, potentially causing temporary degradation—not the persistent degraded performance described. The root cause remains the metric: CPU utilization or another proxy is not reflecting actual application load, so even a shorter cooldown would not fix the suboptimal scaling decision.
- ✓
The scaling metric is not appropriate; consider using a custom metric that better reflects application load.
Why this is correct
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.
Go deeper
Related to this question
Learn chapter
Cloud Digital Transformation
Key term
Managed instance group
A managed instance group is a collection of identical virtual machine instances that are automatically managed as a single unit to ensure high availability and scalability.
Key term
Autoscaler
An Autoscaler is a cloud service that automatically increases or decreases the number of virtual machines (instances) or resources based on real-time demand, so your application always has enough capacity without wasting money on idle servers.
About these practice questions
One of 829 original GCDL 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 GCDL 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 GCDL exam.