Free 2V0-21.23 Practice Test Questions 2026

Explanation:

A. Ensure that the source and destination vCenter instances share the same Key Management Server (KMS).
When migrating a virtual machine between vCenter instances that require encryption, both vCenter servers must use the same KMS or be part of a trusted KMS cluster. The destination vCenter needs access to the same encryption keys to decrypt and re-encrypt the VM during migration. If the KMS configurations differ, the migration fails because the destination cannot unlock the VM's encrypted disks.

C. Ensure that the VM is encrypted before attempting the migration.
The corporate security policy requires that all VMs be encrypted in the destination environment. To migrate successfully while maintaining encryption, the VM must already be encrypted before the migration begins. This allows the migration process to use Encrypted vMotion, which preserves the encryption state across vCenter instances. Migrating an unencrypted VM into a policy-requiring-encryption environment would violate security policy and would require post-migration encryption, which is not a supported migration workflow for cross-vCenter operations.

Why other options are incorrect

B. Ensure that Encrypted vMotion is turned off for the VM.
This is incorrect because Encrypted vMotion must be enabled, not turned off, when migrating encrypted VMs or when moving VMs between environments requiring encryption. Encrypted vMotion protects the VM's memory and disk data in transit over the network. Disabling it exposes sensitive data.

D. Ensure that the VM is powered off before attempting the migration.
While a powered-off migration is possible, it is not required for success. Cross-vCenter vMotion supports live migration of powered-on VMs, even encrypted ones. Powering off would cause unnecessary downtime and is not a prerequisite.

E. Ensure that the source and destination vCenter Servers have a different Key Management Server (KMS).
This directly contradicts step A. Different KMS servers cannot share encryption keys, making decryption at the destination impossible. The migration would fail with key access errors.

Reference

VMware vSphere 8.x Documentation: "Cross-vCenter vMotion with Encrypted VMs" – Requires same KMS or trusted KMS cluster on both source and destination vCenter Servers. VMware KB article 67371: "Migrating encrypted virtual machines between vCenter Server instances" – The VM must be encrypted before migration and Encrypted vMotion must be enabled.

Explanation:

B. Generate a separate log bundle for each ESXi host using the vSphere Host Client.
The vSphere Host Client (accessed directly via https:///ui) allows an administrator to generate a support bundle for that individual host. This is useful when vCenter is unavailable or when only specific hosts need troubleshooting. Navigate to Monitor > Support Logs and click Generate Support Bundle.

C. Generate a combined log bundle for all ESXi hosts using the vSphere Client.
The vSphere Client (connected to vCenter) provides an option to generate a combined support bundle for multiple ESXi hosts simultaneously. Select the hosts in the inventory, right-click, and choose Export System Logs. This creates a single .zip file containing diagnostic data from all selected hosts.

D. Generate a separate log bundle for each ESXi host using the vSphere Client.
The same Export System Logs feature in the vSphere Client also allows generating separate bundles per host. In the Export System Logs wizard, the option "Collect supporting logs for each host individually" can be selected, producing distinct zip files for each chosen ESXi host.

Why other options are incorrect

A. Generate a combined log bundle for all ESXi hosts using the vCenter Management Interface.
The vCenter Management Interface (port 5480) is for managing the vCenter Server Appliance itself, not for gathering ESXi host logs. It provides support bundles for the vCenter appliance, not for managed ESXi hosts.

E. Generate a separate log bundle for each ESXi host using the vCenter Management Interface.
Same as option A, the vCenter Management Interface does not have functionality to generate ESXi host log bundles. It only manages the vCenter appliance.

F. Generate a combined log bundle for all ESXi hosts using the vSphere Host Client.
The vSphere Host Client operates on a single ESXi host and cannot generate a combined bundle for multiple hosts. Each Host ZClient instance only has access to logs from its own host.

Reference

VMware vSphere 8.x Documentation: "Collect Diagnostic Information for ESXi Hosts" – Use vSphere Client (Export System Logs) or vSphere Host Client (Generate Support Bundle). VMware Knowledge Base article 1010705: "Collecting diagnostic information for ESXi hosts" – Describes multiple methods including Host Client and vSphere Client.

Explanation:

The company policy requires microsecond accuracy for time synchronization on physical servers. NTP typically provides only millisecond accuracy (1-10 milliseconds), while PTP delivers microsecond to sub-microsecond precision using hardware timestamping. Since vSphere 7.0 Update 3, ESXi hosts natively support PTP, and the physical server in a vSphere environment is the ESXi host itself. Therefore, each ESXi host must be configured with a PTP source to achieve microsecond-level compliance. PTP on ESXi requires a network adapter that supports hardware timestamping (e.g., Intel I210, Mellanox ConnectX).

Why other options are incorrect

A. NTP on vCenter provides millisecond accuracy only, failing the microsecond requirement. Also, vCenter is a virtual appliance, not a physical server, so policy does not apply directly.

C. NTP on ESXi still provides only millisecond accuracy, which does not meet the microsecond policy requirement.

D. PTP on vCenter is not supported by VMware. The vCenter Server Appliance cannot be configured as a PTP client; PTP is an ESXi host-level feature only.

Reference

VMware vSphere 8.x Documentation:
"Configuring Precision Time Protocol on ESXi Hosts" – PTP provides microsecond accuracy and is supported on ESXi 7.0 Update 3 and later. VMware Knowledge Base article 86458: "Precision Time Protocol in ESXi" – PTP must be configured on the ESXi host, not on vCenter.

Explanation:

To meet the requirements of using an Enterprise CA while minimizing management overhead, the most efficient architecture is the VMware Certificate Authority (VMCA) in Intermediate CA mode. Here is the breakdown of why these three actions are required:

Action D (VMCA as Intermediate CA):
By replacing the VMCA root certificate with one signed by your Enterprise CA, you establish a chain of trust. This satisfies the "Enterprise CA" requirement. Because the VMCA is now a trusted subordinate, any certificate it issues is automatically trusted by the enterprise.

Action B (Machine SSL Certificates):
Corporate policies for SDDCs often require that the primary interface (the Machine SSL certificate) be explicitly issued by the Enterprise CA or a custom certificate to ensure browser trust and high-security compliance for the external-facing management layer.

Action F (Solution User Certificates via VMCA):
This is the key to minimizing management overhead. "Solution user" certificates are used for internal communication between vSphere services (like vCenter to ESXi). Manually replacing these every time they expire (Option E) creates massive overhead. By letting the VMCA (which is already trusted via Action D) handle these automatically, the administrator ensures security without the manual labor of individual certificate lifecycle management.

Why the other options are incorrect:

Option A involves self-signed certificates, which contradicts the requirement for Enterprise CA trust.

Option C is redundant if you are already using a custom Enterprise CA approach for SSL.

Option Ewould maximize management overhead, as you would have to manually manage and rotate certificates for every service across the SDDC.

Reference
VMware vSphere 8.0 Security Guide: Section on "Certificate Management Profiles."
Exam Objective: Section 5.1 – Manage vSphere Certificates.

Explanation:

The administrator needs to monitor VM CPU performance for recurrence of a spike issue. Two primary tools are available for this task.

C. vSphere Performance Charts.
The vSphere Client provides built-in performance charts accessible from the Performance tab for any VM, host, or cluster. These charts display historical and real-time CPU usage data, allowing the administrator to identify spikes, track trends over time, and compare resource consumption across VMs. This is the standard graphical interface for ongoing performance monitoring.

D. vCenter Command Line Interface (or esxtop/resxtop).
Command-line performance tools provide detailed, real-time resource metrics. The esxtop command (run directly on an ESXi host via SSH or ESXi Shell) and resxtop (run remotely against a vCenter or ESXi host) offer granular CPU statistics including %USED, %RDY (ready time), and %WAIT. These tools are ideal for live troubleshooting when a spike is actively occurring, as they refresh every few seconds and show per-VM and per-host CPU consumption.

Why other options are incorrect

A. vCenter Management Interface.
The VAMI (port 5480) monitors the vCenter Server Appliance's own CPU and memory usage, not the CPU performance of individual VMs. This tool helps track vCenter resource health but cannot diagnose per-VM CPU spike issues.

B. Direct Console User Interface (DCUI).
The DCUI is the physical server console for emergency management when vCenter or network is unavailable. It displays basic host-level system logs and service status but does not provide detailed, real-time VM-level CPU performance charts needed for spike analysis.

E. ESXi Shell.
This is the command-line environment on an ESXi host, but it is the access method, not a specific performance tool. While useful for running esxtop, ESXi Shell itself is not a monitoring tool; it enables access to tools like esxtop, which is already covered under command-line options.

Reference

VMware vSphere 8.x Monitoring and Performance Documentation – Performance Charts for CPU monitoring. VMware TechDocs on esxtop for real-time CPU performance analysis.

Explanation:

Memory Reservation (B):
Reservations guarantee physical resources (in this case, memory) to workloads. By assigning a reservation to the Production resource pool, the administrator ensures that Production VMs always receive their full allocated memory even under contention.

Parent Resource Pool (C):
Resource pools allow administrators to logically separate workloads and enforce resource allocation policies. Creating a parent resource pool for Production VMs ensures they are isolated from Test workloads and can be assigned guaranteed resources (via reservations and shares).

❌ Distractor Analysis:


A. Assign a custom memory share value
→ Shares only apply when resources are overcommitted. Without a resource pool, Production VMs cannot be grouped for share assignment. Shares alone do not guarantee full allocation.

D. Create sibling resource pools for Production and Test VMs
→ This would allow relative prioritization but does not guarantee full allocation unless reservations are set.

E. Create a child resource pool for Test VMs
→ This indirectly reduces Test workload priority but does not guarantee Production VMs their full allocation.

🔗 References:
VMware vSphere 8.x Documentation – Resource Management Guide (Resource Pools, Shares, Reservations, Limits)

Explanation:

When configuring a new vSphere cluster using the Cluster Quickstart workflow, administrators are prompted to provide vMotion networking information. This is essential because both vSphere High Availability (HA) and Distributed Resource Scheduler (DRS) depend on vMotion to migrate workloads between ESXi hosts.

HA leverages vMotion to restart virtual machines on surviving hosts after a failure, ensuring service continuity.
DRS uses vMotion to dynamically balance workloads across hosts, optimizing performance and resource utilization.

Without vMotion networking configured, neither HA nor DRS can function properly, as they rely on the ability to move VMs seamlessly between ESXi hosts. Therefore, vMotion networking is a mandatory configuration step during Quickstart setup.

❌ Distractor Analysis:

B. Management networking → Already configured when ESXi hosts are added to vCenter; Quickstart does not prompt for this again.

C. vSAN networking → Only required if vSAN is explicitly enabled in the cluster. Since the scenario mentions only HA and DRS, vSAN networking is not prompted.

D. Virtual machine networking → VM networks are configured at the port group level and are unrelated to HA/DRS functionality. Not part of Quickstart cluster setup.

🔗 References:

VMware Docs – Cluster Quickstart Workflow in vSphere 8.x
VMware vSphere Resource Management Guide – vMotion Requirements for HA and DRS

Explanation:

The administrator must complete these four tasks in the Direct Console User Interface (DCUI) to meet the requirements and successfully access the vSphere Host Client via FQDN.

A. Set the value of the VMware ESXi Management Network VLAN ID to 10.
The provided configuration specifies Management VLAN ID 10. Configuring this in the DCUI ensures the management network traffic is correctly tagged, allowing the host to communicate on the correct VLAN and reach its gateway .

B. Configure at least two network adapters for the VMware ESXi Management Network.
The requirement states the management network must be fault tolerant. This is achieved by assigning at least two physical network adapters (vmnics) to the management vmkernel port in the DCUI. If one NIC or link fails, traffic fails over to the other, ensuring continuous management access .

C. Update the VMware ESXi Management Network IPv4 configuration to use a static IPv4 address.
The provided information states DHCP is not used. A static IPv4 address (172.16.10.101/24), subnet mask, and default gateway (172.16.10.1) must be manually entered in the DCUI to ensure the host receives a predictable, persistent IP address .

G. Update the VMware ESXi Management Network DNS configuration to use the corporate DNS servers for names resolution.
The host FQDN (esxi01.corp.local) and DNS servers (172.16.10.5, 172.16.10.6) are provided. Configuring these in the DCUI enables the host to resolve DNS names, which is required for accessing the host by FQDN through the vSphere Host Client .

Why other options are incorrect

D. Create a DNS A Record for the VMware ESXi host on the corporate DNS servers.
This is a critical step for FQDN resolution, but it must be performed on the external corporate DNS servers, not within the ESXi host's DCUI. The question specifically asks for tasks completed in the DCUI .

E. Disable IPv6 for the VMware ESXi Management Network.
While the requirement specifies using "only IPv4 network protocols," disabling IPv6 is not necessary. Configuring a static IPv4 address and leaving IPv6 unconfigured satisfies the requirement. The DCUI does not require explicit IPv6 disablement for the host to function correctly with IPv4 only .

F. Restore the original Management vSphere Standard Switch. This task is irrelevant for initial deployment configuration. Restoring the original switch is a recovery operation, not a standard configuration step when deploying a new host with provided parameters .

Reference

Broadcom TechDocs: "Configure the Network on VMware Cloud Foundation or vSphere Foundation Hosts" – DCUI configuration steps for VLAN, static IPv4, and DNS settings . ExamTopics 2V0-21.23 discussion confirms ABCG as the correct answer .

Explanation:

When the snapshot was taken with Snapshot the virtual machine’s memory = false, no memory state (RAM contents, CPU state) was captured. Without memory, vSphere cannot restore the VM to a running state because it has no record of what was actively in memory at snapshot time. Therefore, upon revert, the VM always powers off to ensure disk consistency.

The "Revert to Latest Snapshot" operation moves the VM back to the parent snapshot (the state just before the current snapshot was taken). In this scenario, the parent snapshot is the pre-upgrade application state. The child snapshot is the post-upgrade failed state, which is discarded during revert.

Why other options are incorrect:

A (powered on state) – Impossible because memory wasn't snapshotted. Reverting would leave no running process state to restore.

C (child snapshot, powered off) – Revert to latest snapshot goes to parent, not child. The child is the current state being abandoned.

D (child snapshot, powered on) – Combines two errors: wrong snapshot (child instead of parent) and wrong power state (on instead of off).

The Quiesce guest file system = false setting is irrelevant here—quiescing only pauses file system I/O for application‑consistent backups and does not affect power state after revert.

References

VMware vSphere 8.x Documentation– "Take a Snapshot of a Virtual Machine" "If you deselect Snapshot the virtual machine's memory, the snapshot does not capture the memory state. After reverting, the virtual machine will be in a powered off state."

Explanation:

The remote secure location has no network connectivity to the outside world, meaning the migration method must produce a portable image (e.g., to external storage) that can be physically transported. Additionally, the database has a high number of transactions—this is critical because hot cloning captures a system while it is running, and ongoing database writes during the clone can lead to an inconsistent or corrupt database state.

Cold cloning involves booting the source physical machine from a VMware Converter Boot CD (or ISO) that contains its own operating system and the Converter application. The source operating system is not running during the clone, so no changes occur on the disks during the process. This creates an exact, consistent replica of the guest OS, application, and database—ideal for transaction-heavy databases. The cloned virtual machine files can be written directly to external storage (USB drive, portable SSD) and then physically moved to the remote SDDC. Because the source OS is offline, cold cloning leaves no footprint on the original server.

Why option A (hot clone) is incorrect:
Hot cloning copies data while the OS is running and applications are active. For a database with high transaction volume, ongoing writes during the clone cause the resulting virtual machine to have a non‑consistent database state (some transactions partially captured). Additionally, hot clones do not produce an image that is easily transportable without network connectivity.

Why option C (restore from backup) is incorrect:
This assumes a recent, valid backup exists and that the backup software can restore directly to the remote SDDC format. The question does not specify that backups are available, and restoring requires network or media movement—but more importantly, the backup may not capture the exact pre‑migration state with all recent transactions.

Why option D (storage replication) is incorrect:
Storage replication requires network connectivity between source and destination to replicate data continuously. The remote location has no network connectivity to the outside world, making this impossible.

References:

VMware vCenter Converter User Manual – Hot and Cold Cloning Comparison:"Cold cloning, also called offline cloning, entails cloning the source machine when it is not running its operating system. This cloning method allows you to create the most consistent copy of the source machine because nothing changes on the source machine during conversion."

Explanation:

The administrator needs near real-time statistics for all VMs to diagnose intermittent short bursts of CPU contention. Both esxtop and resxtop provide live, refreshable (default 5-second interval) performance metrics directly from the ESXi host kernel.

C – resxtop – This is the remote version of esxtop. It runs from a remote machine (e.g., administrator's workstation or a vCenter-connected shell) and connects to an ESXi host over the network using authenticated API calls. It displays the same real-time CPU, memory, disk, and network statistics for all VMs on that host.

E – esxtop – This runs directly in the ESXi host's local console (DCUI shell or SSH session). It provides identical real-time statistics as resxtop but requires direct or SSH access to the host. Both tools show per-VM metrics like %RDY (CPU ready time), %USED, %CSTP (co‑stop), which are critical for diagnosing CPU contention bursts.

Why the other options are incorrect:

A – Advanced Performance Charts – These are historical, not near real-time. They aggregate data in intervals (e.g., 5 minutes to 1 day) and refresh every few minutes. They cannot capture sub‑minute intermittent bursts.

B – esxcli – This is a command-line management tool for configuration, troubleshooting, and basic stats gathering (e.g., esxcli vm process list). It does not provide continuous, refreshable real-time performance metrics across all VMs.

D – Overview Performance Charts – Similar to Advanced Charts, these are historical views with lower granularity (typically 20-second or 5-minute averages). They are not designed for near real‑time burst detection.

References:

VMware vSphere 8.x Documentation – "Using esxtop and resxtop for Real-Time Performance" "Both esxtop and resxtop provide real-time performance data for ESXi hosts. resxtop can be run remotely and connects to an ESXi host via vCenter Server or directly."

Ensure a DNS A Record Is created for the VMware ESXI host on the corporate DNS servers,

Update the VMware ESXI Management Network DNS configuration to use the corporate DNS servers for name, resolution,

Set the value of the VMware ESXI Management Network VLAN ID to 10.

Explanation:

The administrator installed ESXi but made no additional configuration changes. The error “Server Not Found” when using the FQDN (esxi101.corp.local) indicates a name resolution failure—the client cannot resolve the hostname to an IP address. Additionally, the physical network expects the management traffic to be on VLAN 10, but the ESXi Management Network defaults to VLAN 0 (untagged). These three tasks are required at a minimum:

A – Ensure a DNS A Record is created for the VMware ESXi host on the corporate DNS servers
Without an A record, the FQDN cannot resolve to 172.16.10.101. Even with correct client-side DNS settings, resolution fails if the DNS server lacks the record.

B – Update the ESXi Management Network DNS configuration to use the corporate DNS servers
ESXi needs to know which DNS servers to use for its own outbound name resolution (though this matters less for incoming connections, it is required for full FQDN functionality and for vCenter discovery later). More critically, the ESXi host must register its own name with DNS if dynamic DNS is used, and must be able to resolve other names.

E – Set the value of the ESXi Management Network VLAN ID to 10
The management network is on VLAN 10, but the default ESXi Management Network has no VLAN tag (VLAN ID 0). Without setting VLAN ID 10, the host's management traffic stays on the native VLAN and never reaches the correct subnet, making the IP address 172.16.10.101 unreachable from the rest of the network.

Why the other options are incorrect:

C – Update to use a static IPv4 address
– The installation already assigned 172.16.10.101/24 with gateway 172.16.10.1 (manually or via script). The problem is not DHCP vs. static; it's name resolution and VLAN misconfiguration. No change to IPv4 addressing is needed.

D – Configure at least two network adapters for the Management Network
– There is no requirement for NIC teaming or redundancy to achieve basic FQDN-based login. A single active management adapter is sufficient.

F – Disable IPv6 for the Management Network
– IPv6 being enabled does not prevent IPv4 FQDN resolution or access. Disabling it is unnecessary and unrelated to the error.

References

VMware vSphere 8.x Documentation – "Configure Management Network Settings" "To use FQDNs, you must configure DNS servers and ensure forward and reverse DNS records exist. For tagged management VLANs, you must set the VLAN ID on the Management Network."

VMware KB 1003926 – "Troubleshooting ESXi host management network connectivity" "Failure to set the correct VLAN ID on the Management Network results in no network connectivity to the host even with a correct IP address."