VCP-DCV vSphere Performance and Scaling Practice Question
An administrator is troubleshooting a VM that reports poor application responsiveness. In esxtop on the ESXi host, the VM shows a CPU ready time (READY) of 12 percent, and the host has more vCPUs assigned to running VMs than physical cores. Which factor is the PRIMARY contributor to this ready time?
⚠ Common exam trap
The trap here is attributing ready time to guest activity or memory pressure instead of recognizing it as host-level CPU scheduling contention.
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 waiting for a physical CPU to become available because the host is overcommitted and the scheduler cannot place it immediately.
CPU ready time reflects how long a vCPU waits for a physical core. With more vCPUs assigned than physical cores, the ESXi scheduler must time-slice, producing ready time. Reducing vCPU counts, adding hosts, or using shares and reservations to prioritize the latency-sensitive VM are the appropriate remedies for this contention.
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 waiting for a physical CPU to become available because the host is overcommitted and the scheduler cannot place it immediately.
Why this is correct
CPU ready time measures the time a VM is ready to run but is waiting for a physical core. When vCPUs exceed physical cores, the scheduler must time-slice, so VMs wait in the run queue. A READY value around 12 percent for a latency-sensitive workload directly reflects this contention and is the primary contributor here.
- ✗
The physical CPU cores are running below their rated clock speed, so each vCPU takes longer to execute.
Why it's wrong here
Reduced clock speed would increase the time each vCPU actually runs, but ready time specifically measures waiting before execution, not execution duration. The scenario states vCPUs exceed physical cores, which is the textbook cause of scheduling delay. Clock throttling does not explain the run-queue wait.
- ✗
The VM's memory reservation is too low, causing the vCPU to stall while pages are faulted from disk.
Why it's wrong here
Low memory reservation can trigger ballooning or swapping, which would show up as memory-related metrics such as MEMCTL or SWAP, not as CPU ready time. Memory stalls and CPU scheduling delays are distinct conditions. This option confuses memory pressure with CPU contention.
- ✗
The guest operating system is running too many background services, which inflates the ready time reported by esxtop.
Why it's wrong here
Ready time is measured by the hypervisor as the interval between when a vCPU is ready to execute and when it is actually scheduled on a physical core. Guest background services increase CPU usage but do not directly create ready time unless the host lacks capacity. This option misplaces the cause inside the guest.
Go deeper
Related to this question
About these practice questions
Courseiva writes every VCP-DCV question from scratch — 281 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official VMware exam blueprint
This VCP-DCV practice question is part of Courseiva's free VMware 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 VCP-DCV exam.