Google ACE Practice Question: Running a batch processing job on Compute Engine…

A company is running a batch processing job on Compute Engine every night. The job usually completes in 2 hours, but recently it has been taking over 4 hours. The CPU utilization on the VM is consistently below 20%. What is the most likely cause?

⚠ Common exam trap

Google Cloud often tests the misconception that low CPU utilization always means the machine is over-provisioned, but the trap here is that I/O-bound workloads (like memory swapping) can cause severe performance degradation while CPU remains idle, leading candidates to incorrectly choose a machine type or disk zone issue.

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 VM is running out of memory and swapping to disk.

When CPU utilization is below 20% but job execution time has doubled, the bottleneck is likely I/O, not compute. Swapping to disk occurs when the VM runs out of memory, causing the kernel to page memory to the persistent disk, which is orders of magnitude slower than RAM. This I/O wait directly increases job duration without raising CPU utilization.

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 VM is using a shared-core machine type.
Why it's wrong here
Shared-core machine types (e.g., e2-small, e2-medium) enforce CPU quotas with burstable bursts, so CPU would fluctuate as throttling kicks in. The reported symptom is consistently low CPU with high disk I/O, which does not match throttling; throttling starves CPU time but does not generate disk activity. Thus, the machine type's shared nature is not a plausible root cause for the observed performance plateau.
✗
The VM's machine type is too small.
Why it's wrong here
A machine too small in overall capacity typically becomes CPU-saturated, showing sustained high utilization as the vCPUs struggle to keep up. Here CPU is low, so the bottleneck lies elsewhere; undersized vCPUs cannot explain the heavy disk write/read traffic. If memory were the constraint, that is a different failure mode, not "machine too small" in the CPU sense, and would manifest as swapping.
✓
The VM is running out of memory and swapping to disk.
Why this is correct
When physical memory is exhausted, the Linux kernel moves cold pages to swap space on the attached persistent disk. Every swapped-in/out page causes block I/O, while the CPU idles waiting on disk, so overall CPU utilization stays low even though the job crawls. Combined with high disk I/O, this pattern is a classic signature of memory thrashing, not a CPU shortage.
✗
The VM's persistent disk is in a different zone.
Why it's wrong here
In Compute Engine, a persistent disk is a zonal resource and can only be attached to a VM in the same zone; you cannot attach a disk from another zone. Even if you could, zone placement affects latency slightly but does not trigger continuous disk I/O or suppress CPU usage. Therefore, a disk being in a different zone is both an invalid configuration and an implausible explanation for the symptom.

Go deeper

Google ACE Practice Question: Running a batch processing job on Compute Engine…

Why each option matters

Option-by-option breakdown

Related to this question