VCP-DCV common mistakes
VCP-DCV · Understand the traps and how to avoid them.
When a scenario asks for guaranteed failover capacity, the candidate selects a DRS rule or migration threshold instead of checking the vSphere HA admission-control policy and slot size.
The candidate conflates HA, which reserves capacity for restarts, with DRS, which balances running workloads.
What to do instead
Separate the two features: use HA admission control and slot/percentage policy for failover reserve, and use DRS rules/thresholds for placement and balance. Calculate the reserve before choosing an answer.
The candidate assumes vSphere Distributed Switch is required for vMotion and that standard switches support LACP, NIOC, or private VLANs.
Many networking features have similar names, and the candidate memorizes product labels without mapping each feature to vDS or vSS.
What to do instead
Build a compare list: vDS provides centralized configuration, LACP, NIOC, private VLANs, and port mirroring; vSS is per-host and lacks those vDS-specific capabilities. vMotion can run on either if network requirements are met.
The candidate recommends DRS, HA, vDS, or another advanced capability without confirming that the stated vSphere edition and licensing include it.
The candidate focuses on technical possibility and ignores licensing constraints, which are common in scenario questions.
What to do instead
Check the edition/feature matrix before selecting a solution. If licensing is not stated, choose the answer that satisfies the requirement without assuming an unlicensed feature.
The candidate sizes a cluster by summing configured VM memory or CPU and comparing it directly with physical host capacity.
Simple arithmetic ignores vSphere overhead, VM overhead, HA admission-control reserve, and the need to tolerate host maintenance or failure.
What to do instead
Include VM overhead, hypervisor overhead, reserved capacity, and N+1 or maintenance capacity. Validate with real utilization and growth assumptions, not just configured VM sizes.
The candidate treats resource-pool shares as hard limits or as guaranteed reservations, and designs many nested pools to partition CPU and memory.
The vSphere UI presents shares, reservations, and limits together, and the candidate does not distinguish relative priority from absolute guarantees.
What to do instead
Remember that shares are relative only when contention exists, reservations provide guaranteed resources, and limits cap usage. Avoid unnecessary nested pools and use reservations only for workloads that truly need guarantees.
During installation or configuration, the candidate changes vCenter certificates or the SSO identity source without first checking dependent services, trust relationships, and rollback steps.
Certificate and identity-source changes appear to be isolated settings but can break vCenter services, SSO, and integrated components.
What to do instead
Plan the change: back up vCenter, document trust relationships, verify service dependencies, use the certificate management workflow, and test authentication after each change.
The candidate treats VM snapshots as a backup method or leaves snapshots in place for days and then ignores consolidation warnings.
Snapshots are fast and easy to create, so they are mistaken for long-term protection even though they grow with delta disk usage and degrade performance.
What to do instead
Use snapshots only for short-term rollback. Use a backup product for data protection, monitor snapshot age and datastore growth, and consolidate or delete snapshots promptly.
While troubleshooting, the candidate changes several network, storage, or HA settings at once and does not collect vCenter events, VM logs, or ESXi logs first.
Under time pressure, the candidate guesses at fixes instead of isolating the failing layer, which makes cause and effect impossible to determine.
What to do instead
Collect evidence first: vCenter events/alarms, VM logs, vmkwarning/vobd logs, and relevant esxcli output. Change one variable at a time and verify the result before proceeding.
The candidate confuses vSphere Lifecycle Manager desired-state images with baselines and applies an upgrade without checking interoperability, firmware, or driver compatibility.
Upgrade tooling and terminology overlap, and the candidate focuses on the update button rather than the compatibility matrix.
What to do instead
Distinguish baseline-based updating from image-based vLCM. Verify the interoperability matrix, HCL, firmware/driver support, and cluster image compliance before upgrading.
The candidate chooses VMFS, NFS, or iSCSI for a workload without validating array support, multipathing policy, queue depth, or protocol-specific requirements.
Storage questions often emphasize capacity, so the candidate ignores the path and array configuration that determine availability and performance.
What to do instead
Match the protocol to array capabilities and requirements, verify multipathing and PSP settings, confirm supported queue depth and block size, and check the storage HCL before recommending a design.