easyMultiple Choice
CV0-004 Practice Question: Is troubleshooting a performance issue in a…
A cloud engineer is troubleshooting a performance issue in a virtualized environment. A critical application is running slowly, and the engineer suspects resource contention. The host server has 32 vCPUs and 256 GB of RAM, running four VMs. Which tool should the engineer use to determine if CPU ready time is causing the performance degradation?
⚠ Common exam trap
Test-takers frequently assume guest OS tools like 'top' or Performance Monitor can detect all CPU-related bottlenecks, but they cannot see hypervisor-level metrics like CPU ready time, which requires the hypervisor's own monitoring console.
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
✓
Use the hypervisor's monitoring console to view CPU ready time
CPU ready time is a hypervisor-level metric that measures the time a VM is ready to execute but must wait for a physical CPU core to become available. Since the engineer suspects resource contention among VMs on the same host, the hypervisor's monitoring console is the only tool that can expose this metric directly. Guest OS tools like 'top' or Performance Monitor cannot see CPU ready time because it occurs at the virtualization layer, not inside the VM.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Run the 'top' command inside the affected VM
Why it's wrong here
CPU ready time is a hypervisor-level metric measuring how long a vCPU waited for a physical core; the guest's 'top' command sees only its own processes and cannot observe host scheduling contention. It is tempting because it is readily available inside the VM, but host-side tools such as esxtop are required.
- ✗
Deploy a network analyzer to capture traffic between VMs
Why it's wrong here
A network analyser captures packet flows, not hypervisor scheduling metrics such as CPU ready time, so it cannot expose vCPU contention on the host. It is tempting because packet capture genuinely diagnoses latency between VMs, and would be the right tool if the slowdown were network-bound rather than CPU-scheduling-bound.
- ✗
Check the performance monitor in the guest operating system
Why it's wrong here
Guest performance monitor counters reflect the operating system's view and cannot measure hypervisor scheduling delay, so CPU ready time remains invisible. It is tempting because the tool is already installed and familiar, but ready time must be read from the host, for example through esxtop or vSphere performance charts.
- ✓
Use the hypervisor's monitoring console to view CPU ready time
Why this is correct
CPU ready time measures how long a vCPU waited in the hypervisor's run queue for a physical core, which is the precise metric for CPU contention on an overcommitted host. Only the hypervisor console exposes it; guest tools cannot see scheduling delay.
Go deeper
Related to this question
About these practice questions
This CV0-004 question is part of Courseiva's 834-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CV0-004 practice question is part of Courseiva's free CompTIA 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 CV0-004 exam.