Quick Answer
The correct answer is %RDY and Co-Stop, as these two metrics directly measure CPU ready time contention in vSphere. %RDY captures the percentage of time a virtual machine is ready to execute instructions but must wait for the ESXi host’s CPU scheduler to allocate physical cycles, while Co-Stop tracks time lost when vCPUs within a single VM are forcibly co-scheduled and then descheduled due to contention on the same physical core. On the VCP-DCV exam, this question tests your ability to distinguish between CPU scheduling metrics and common red herrings like %CSTP or %WAIT; a frequent trap is confusing Co-Stop with general CPU ready time, but remember that Co-Stop specifically applies to SMP VMs with multiple vCPUs. For a quick memory tip, think “Ready waits for any core, Co-Stop waits for its twin.”
This VCP-DCV practice question tests your understanding of vsphere performance and scaling. The scenario asks you to isolate a root cause — eliminate options that address a different problem before choosing. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
An administrator is troubleshooting performance issues on a vSphere cluster. Which TWO metrics should be monitored to identify CPU ready time contention?
Disk Kernel Latency
Why wrong: Measures storage latency, not CPU.
Memory Swap In Rate
Why wrong: Indicates memory overcommitment, not CPU.
Co-Stop
Measures time vCPUs are co-scheduled but waiting due to HT.
Network Packet Drop Rate
Why wrong: Indicates network issues, not CPU.
%RDY (CPU Ready)
Directly measures CPU ready time.
Answer choices
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
Co-Stop
CPU ready time contention occurs when a virtual machine is ready to execute instructions but the ESXi host's CPU scheduler cannot immediately allocate physical CPU cycles. The %RDY metric directly measures the percentage of time a VM is waiting to be scheduled on a physical CPU, while Co-Stop specifically tracks time lost when vCPUs in a single VM are forcibly co-scheduled and then descheduled due to contention on the same physical core. Both metrics are primary indicators of CPU scheduling pressure.
Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Answer analysis
For each option: why learners choose it and why it is or isn't the right answer here.
Disk Kernel Latency
Why it's wrong here
Measures storage latency, not CPU.
Memory Swap In Rate
Why it's wrong here
Indicates memory overcommitment, not CPU.
Co-Stop
Why this is correct
Measures time vCPUs are co-scheduled but waiting due to HT.
Related concept
Read the scenario before looking for a memorised answer.
Network Packet Drop Rate
Why it's wrong here
Indicates network issues, not CPU.
%RDY (CPU Ready)
Why this is correct
Directly measures CPU ready time.
Related concept
Read the scenario before looking for a memorised answer.
Common exam traps
The trap here is that candidates confuse CPU ready time with memory or storage metrics, especially since high CPU ready time can manifest as general VM slowness, leading them to incorrectly select Disk Kernel Latency or Memory Swap In Rate instead of the correct CPU-specific counters.
Detailed technical explanation
CPU ready time (%RDY) is measured as a percentage over the collection interval and should ideally remain below 5% for acceptable performance; values above 10% indicate significant contention. Co-Stop occurs only in SMP VMs with multiple vCPUs, where the ESXi scheduler must simultaneously schedule all vCPUs on physical cores—if one vCPU is delayed, all are descheduled, wasting cycles. In real-world scenarios, oversubscribing vCPUs beyond physical cores (e.g., 4:1 ratio) often inflates both %RDY and Co-Stop, leading to application-level slowdowns that are misdiagnosed as storage or network issues.
Key takeaway
Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Real-world example
A practitioner preparing for the VCP-DCV exam encounters this exact type of scenario on the job. The correct answer here is not the most general option — it is the best answer for the specific constraint described. Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option. Real exam questions reward reading the full scenario before eliminating options, because the constraint defines which answer fits.
What to study next
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
vSphere Performance and Scaling — study guide chapter
Learn the concepts, then practise the questions
vSphere Performance and Scaling practice questions
Targeted practice on this topic area only
All VCP-DCV questions
511 questions across all exam domains
VMware Certified Professional Data Center Virtualization VCP-DCV study guide
Full concept coverage aligned to exam objectives
VCP-DCV practice test guide
How to use practice tests most effectively before exam day
Related practice questions
Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.
Practise VCP-DCV questions linked to vSphere Architecture, Products and Solutions.
Practise VCP-DCV questions linked to Configure and Manage vSphere Networking.
Practise VCP-DCV questions linked to Configure and Manage vSphere Storage.
Practise VCP-DCV questions linked to vSphere Lifecycle Management.
Practise VCP-DCV questions linked to vSphere Security.
Practise VCP-DCV questions linked to vSphere Performance and Scaling.
Practise VCP-DCV questions linked to VCP-DCV fundamentals.
Practise VCP-DCV questions linked to VCP-DCV scenario.
Practise VCP-DCV questions linked to VCP-DCV troubleshooting.
Practice this exam
Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.
FAQ
vSphere Performance and Scaling — This question tests vSphere Performance and Scaling — Read the scenario before looking for a memorised answer..
The correct answer is: Co-Stop — CPU ready time contention occurs when a virtual machine is ready to execute instructions but the ESXi host's CPU scheduler cannot immediately allocate physical CPU cycles. The %RDY metric directly measures the percentage of time a VM is waiting to be scheduled on a physical CPU, while Co-Stop specifically tracks time lost when vCPUs in a single VM are forcibly co-scheduled and then descheduled due to contention on the same physical core. Both metrics are primary indicators of CPU scheduling pressure.
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Read the scenario before looking for a memorised answer.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A vSphere administrator is troubleshooting a VM that hosts a critical database. The VM is configured with 8 vCPUs and 64 GB memory on an ESXi host with two 10-core CPUs (hyperthreading enabled). Performance charts show CPU ready time averaging 12% during peak hours, and the database application is experiencing high transaction latency. The administrator has verified that no other VMs are contending for CPU. Which action will most likely reduce CPU ready time without negatively impacting database performance?
mediumWhy D: Option C is correct because reducing the number of vCPUs to match the actual workload reduces scheduler overhead and improves cache locality. A VM with 8 vCPUs on a host with 40 logical CPUs should not normally have high ready time unless the vCPU count is excessive relative to the workload. Reducing to 4 vCPUs often resolves contention without degrading throughput because many database workloads do not scale linearly beyond 4 vCPUs. Option A is wrong because disabling hyperthreading reduces logical CPUs, potentially increasing contention. Option B is wrong because increasing memory does not affect CPU ready time. Option D is wrong because CPU affinity can lead to unbalanced load and is not a best practice for DRS clusters.
Last reviewed: Jun 11, 2026
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.