VCP-VVF Admin (2V0-16.25) common mistakes
VCP-VVF Admin (2V0-16.25) · Understand the traps and how to avoid them.
Treats baselines and images as interchangeable per-host settings - for example, trying to remediate a cluster that is already managed by an image with a baseline, or assuming one host in the cluster can stay on an older ESXi build after the cluster image is upgraded.
vSphere Lifecycle Manager shows two separate management methods in the same UI, and candidates carry over baseline habits from older versions instead of recognizing the method as a cluster-level decision.
What to do instead
A cluster is either baseline-managed or image-managed, never mixed: an image (base ESXi version + vendor add-on + firmware add-on) is applied to every host in the cluster. Confirm which method the cluster is on before answering, watch the draft/commit state of the image, and remember the firmware add-on only exists when a hardware support manager is registered.
Designs a four-host vSAN cluster with RAID-6 erasure coding and FTT=2 because 'higher FTT means more resilient'.
Candidates memorize that FTT=1 is normal and FTT=2 is safer without memorizing the minimum host count each storage policy requires, and the UI lets you create the policy anyway.
What to do instead
Host minimums: RAID-1/FTT=1 needs 3 hosts, RAID-5/FTT=1 needs 4 hosts, RAID-6/FTT=2 needs 6 hosts. On four hosts the strongest option is RAID-5/FTT=1 (or RAID-1/FTT=1); erasure coding also requires an all-flash disk group, so check flash capacity as well as host count.
Expects VLAN ID 0 on a port group or dvPort to place VMs in an isolated VLAN, or types 4095 expecting a specific VLAN number.
0, 4095 and 1–4094 sit in the same field and look like ordinary values, but each selects a different tagging model rather than a VLAN.
What to do instead
0 = external switch tagging (the host adds no tag; the physical switch port decides), 4095 = virtual guest tagging (the tag is applied inside the guest OS), and 1–4094 = virtual switch tagging (the port group/dvPort imposes that tag). Choose the value that matches the tagging model in the design, not the one that looks like a VLAN number.
Sets MTU 9000 only on the vSAN or vMotion VMkernel adapter, leaves the vSwitch/dvSwitch uplink and physical switch at 1500, then cannot explain why vSAN health reports an MTU mismatch or vMotion throughput does not improve.
MTU is configured in several places, and candidates raise only the field the question happens to mention.
What to do instead
Jumbo frames must be consistent end to end: VMkernel adapter, vSwitch/dvSwitch MTU, physical switch ports, and any routed hop. Use the vSAN health check (or a test vMotion) to verify after the change instead of assuming the VMkernel setting alone is sufficient.
Sets DRS to Fully Automated on a cluster whose hosts have no vMotion-enabled VMkernel adapter, then is surprised when maintenance-mode evacuations and balancing recommendations never complete.
vCenter accepts the DRS/HA configuration without validating that a vMotion network exists; the gap surfaces later as a stalled task rather than a configuration error.
What to do instead
Create a VMkernel adapter on every host with the vMotion service enabled (separate from management), on the same subnet or routed with the correct gateway, then prove it with a manual migration or a DRS recommendation before relying on automation.
Assigns a role to a group at the datacenter level and assumes every VM below inherits it - without ticking 'Propagate to children' and without checking for an explicit permission on an intermediate folder or cluster.
It is easy to read the assignment as 'applies to everything under here', but inheritance only flows when propagation is enabled, and any explicit child assignment wins.
What to do instead
Tick Propagate to children on the parent assignment, keep explicit child assignments to a minimum, assign to groups rather than individual users, and verify effective permissions on a representative VM. Remember each object holds at most one role per user or group.
Replaces the VMCA root certificate by dropping a third-party CA root into the certificate store, or installs a leaf certificate without its intermediates, then finds vCenter services failing or browsers still reporting an untrusted chain.
Candidates treat the VMCA root as 'just another certificate to swap' and skip the supported certificate topologies and chain requirements.
What to do instead
Work through the supported designs: VMCA as root CA, or the enterprise CA as root with VMCA acting as a subordinate/intermediate CA that issues solution-user certificates, with the enterprise root distributed as a trusted root. Replace machine SSL with the full certificate chain and verify the chain end to end after each replacement.
Applies a guest OS customization specification to a Linux clone whose source has no open-vm-tools/perl, or to a Windows clone that was left powered on, and the resulting VM keeps the template's hostname or SID.
Customization happens inside the guest at first boot through VMware Tools; when the prerequisite is missing, vCenter still completes the clone and silently skips the guest-side steps.
What to do instead
Confirm VMware Tools (open-vm-tools with perl on Linux) is installed and running in the source, power off the source before cloning with customization, and match the spec's hostname/network settings to the guest OS type. Check the clone's events for 'customization of the guest operating system is not supported' style messages.
Removes [email protected] from the vCenter Single Sign-On Administrators group, or makes all administrative access depend on a single external AD group, then is locked out when that identity source is unreachable.
Candidates 'clean up' the default account or centralize everything in AD without planning a break-glass path for SSO or directory outages.
What to do instead
Keep a documented break-glass account - a vsphere.local SSO user in the Administrators group with a vaulted password - and grant AD users access through groups. The vsphere.local identity source cannot be deleted, and appliance-level access is the recovery path when SSO itself is misconfigured.
Places a vSAN host into maintenance mode with 'Ensure accessibility' or 'No data migration' before a multi-day hardware repair, then runs the cluster at reduced redundancy for the whole outage.
The three evacuation modes are worded similarly and candidates pick the fastest one without mapping it to the length of the outage and the free capacity available.
What to do instead
Full data evacuation moves all components off the host - slow, needs free capacity, safest for long outages. Ensure accessibility moves only what is needed to keep the policy compliant - faster, but redundancy drops. No data migration moves nothing - fastest and riskiest. For a planned long repair, verify capacity and choose full evacuation; reserve Ensure accessibility for short single-host events.