Free VMware 2V0-21.23 Practice Test Questions 2026

Add a new permission on the virtual machine object selecting the user and the new custom role.

Create a new custom role with the Virtual Machine Snapshot Management privileges.

Summary
This question tests the principle of least privilege and granular permission management in vSphere. The goal is to grant a specific snapshot privilege to a single user without altering the existing access of their group (VM_Viewers) or another group (VM_Users). The solution requires creating a highly specific permission entry for that user, which necessitates a custom role with the exact right needed.

Correct Option

B. Add a new permission on the virtual machine object selecting the user and the new custom role.
This step directly applies the specific, limited access to the individual user. By adding a new permission entry on the VM object itself for this user, it grants them the additional rights without changing the group's permissions.

D. Create a new custom role with the Virtual Machine Snapshot Management privileges.
This is the prerequisite for step B. Since no built-in role provides only the snapshot privilege, a custom role must be created. This role should include the "Create snapshot", "Remove snapshot", and "Revert to snapshot" privileges to fulfill the requirement.

Incorrect Option

A. Add the user to the VM_Users group and leave the permissions on the virtual machine object unchanged.
This would grant the user excessive permissions. The Virtual Machine Power User role includes many privileges beyond taking snapshots, such as configuring device settings and interacting with CD/DVD media, violating the principle of least privilege.

C. Edit the Read Only role to add the Virtual Machine Snapshot Management privileges.
This would impact all other members of the VM_Viewers group. Granting snapshot privileges to the entire group gives four other users more access than they require or should have, which is against the requirement.

E. [Add a] new permission on the virtual machine object selecting the VM_Viewers group and the new custom role.
This is incorrect for the same reason as option C. Applying the new custom role to the VM_Viewers group would grant snapshot privileges to all five members, not just the one user who needs it.

Reference
VMware vSphere Documentation: vSphere Permissions and User Management (This covers creating custom roles and assigning permissions to users and groups on specific inventory objects.)

VMware vSAN

vSphere Virtual Volumes (vVols)

Summary
This question tests the understanding of modern, object-based storage paradigms in vSphere versus traditional block and file storage. Traditional datastores (VMFS, NFS) store VM files within a monolithic volume. Object-based storage abstracts VM components (config, vmdk, swap) into individual, policy-driven objects, enabling more granular management and integration with storage arrays.

Correct Option

B. VMware vSAN:
vSAN is a hyper-converged, object-based storage system. It abstracts the local storage of ESXi hosts into a distributed datastore and stores each VM disk (vmdk), its swap file, and other components as separate, self-contained storage objects that are distributed and replicated across the cluster.

D. vSphere Virtual Volumes (vVols):
vVols is an object-based storage framework that integrates external storage arrays with vSphere. It virtualizes the storage array's capacity into a pool of storage and represents each virtual disk, configuration file, and snapshot as an independent "Virtual Volume" (object) on the array, managed directly by vSphere.

Incorrect Option

A. VMware Virtual Machine File System (VMFS):
VMFS is a traditional, shared block storage file system. It presents a monolithic volume where all VM files (.vmx, .vmdk, etc.) are stored as files within this single volume structure. It does not use an object-based model.

C. Network File System (NFS) 3:
NFS is a network file sharing protocol. An NFS datastore mounts a remote file system from a NAS device. VMs are stored as a set of files within directories on this shared file system, not as discrete, managed objects.

E. Network File System (NFS) 4.1:
While NFS 4.1 includes advanced features like parallel I/O (pNFS), it is still fundamentally a file-sharing protocol from vSphere's perspective. A VM on an NFS 4.1 datastore is still comprised of files (.vmx, .vmdk) on a remote file system, not native vSphere storage objects.

Reference
VMware vSphere Documentation: vSphere Storage Concepts (This guide explains the architecture of different datastore types, highlighting the object-based models of vSAN and vVols.)

The administrator attempted to boot with a bootloader that is unsigned or has been tampered with.

Summary
This question addresses troubleshooting a Secure Boot failure on an ESXi host. Secure Boot is a UEFI feature that ensures only trusted, digitally signed software is loaded during the boot process. A "Secure Boot Failed" error indicates a violation of this trust chain, meaning an unsigned or improperly signed component has attempted to load, preventing the system from starting.

Correct Option

C. The administrator attempted to boot with a bootloader that is unsigned or has been tampered with.
This is the most direct and common cause of a "Secure Boot Failed" (error 39). The UEFI firmware verifies the digital signature of each component in the boot chain, starting with the bootloader. If the ESXi bootloader itself is not signed with a key trusted by the platform, or if its signature is invalid due to tampering, the boot process will halt with this fatal error.

Incorrect Option

A. The kernel has been tampered with.
While a tampered kernel would also cause a Secure Boot failure, the error would typically occur later in the boot process after the bootloader has already been verified and executed. The specific error message points to a failure at the initial boot stage, which is governed by the bootloader.

B. The Trusted Platform Module chip has failed.
A TPM failure is unrelated to a Secure Boot error. The TPM is used for measuring system integrity (as part of vSphere Trust Authority) and key storage, but it is not responsible for verifying the digital signatures of boot components; that is the role of the UEFI Secure Boot firmware.

D. A package (VIB or driver) has been tampered with.
A tampered VIB would be detected by the Image Profile and VIB acceptance level checks during installation or boot, but it would not typically cause the specific "Secure Boot Failed" fatal error at the initial boot stage. Unsigned VIBs would fail to load after the kernel has booted, not prevent the bootloader from starting.

Reference
VMware vSphere Documentation: Secure Boot Troubleshooting (The vSphere documentation for Secure Boot explains that it verifies the bootloader and kernel, and a failure indicates a component is not properly signed.)

Large

Summary
This question tests knowledge of vCenter Server Appliance (VCSA) sizing guidelines. The administrator must select a deployment size that meets both the current host count (75) and the future growth (up to 100 hosts). The sizing must align with the official maximum host limits for each VCSA size to ensure performance and stability, with room for future expansion.

Correct Option

C. Large:
This is the correct deployment size. A "Large" vCenter Server Appliance is designed to support a maximum of 200 hosts. This size perfectly accommodates the current environment of 75 hosts and provides ample headroom for the planned growth to 100 hosts, all while staying well within its supported limit.

Incorrect Option

A. Medium:
A "Medium" deployment has a maximum supported limit of 50 hosts. Since the current environment already has 75 hosts, this size is insufficient and would be unsupported, leading to potential performance issues and instability.

B. Tiny:
A "Tiny" deployment is the smallest size, supporting a maximum of only 10 hosts. It is intended for very small lab or proof-of-concept environments and is completely inadequate for the scale described.

D. Small:
A "Small" deployment supports a maximum of 25 hosts. Like the "Tiny" and "Medium" sizes, it is too small for an environment that currently has 75 hosts and is expected to grow.

Reference
VMware vSphere Documentation: vCenter Server Appliance Sizing Guidelines (This official documentation provides the maximum host and VM counts for each VCSA deployment size, confirming that a Large deployment is required for 75-100 hosts.)

vCenter Server Update Planner

Summary
This question focuses on the pre-upgrade planning process for a vCenter Server that is part of a larger ecosystem. Before a major version upgrade, it is critical to check for compatibility with integrated solutions like Aria Automation and Cloud Director. The administrator needs a tool specifically designed to generate these third-party interoperability reports, not just a tool for applying updates.

Correct Option

C. vCenter Server Update Planner:
This is the correct tool. The vCenter Server Update Planner is a web-based service (accessible via the VMware Product Interoperability Matrices portal) designed specifically for pre-upgrade planning. It allows administrators to generate detailed reports that analyze the current vCenter environment and its integrated products, identifying any compatibility issues before starting an upgrade to a new version like vSphere 8.

Incorrect Option

A. vSphere Update Manager (VUM):
VUM (now integrated as a component within vSphere Lifecycle Manager) is used for scanning and remediating ESXi hosts and VMs for compliance against baselines. It is not designed to generate interoperability reports for integrated VMware products like Aria Automation and Cloud Director.

B. VMware Aria Suite Lifecycle:
This tool manages the lifecycle (deployment, configuration, upgrade) of the Aria Suite products (Operations, Logs, Automation, etc.) themselves. It is not used for generating pre-upgrade interoperability reports for vCenter Server and its external integrations.

D. vSphere Lifecycle Manager (vLCM):
vLCM is used for centralized lifecycle management of ESXi hosts, including image-based management and firmware/driver updates. While it handles host upgrades, it does not provide interoperability reporting for vCenter Server's integrated solutions.

Reference
VMware vSphere Documentation: vCenter Server Upgrade Planning (This guide directs users to the vCenter Server Update Planner for pre-upgrade interoperability checks with products like Aria Automation and Cloud Director.)

Create a 'Should run Virtual Machines to Hosts' anti-affinity rule.

Summary
This question involves configuring high availability for critical VMs (domain controllers) in a small cluster. The goal is to keep the VMs on separate hosts for fault tolerance while allowing vSphere DRS the flexibility to perform maintenance tasks like vMotion or placing a host into maintenance mode. The solution requires an anti-affinity rule that provides a strong recommendation but is not absolute.

Correct Option

D. Create a 'Should run Virtual Machines to Hosts' anti-affinity rule.
This is the optimal configuration. A "Should" rule instructs DRS to try to keep the two domain controller VMs on separate hosts under normal conditions. However, it provides the flexibility for DRS to temporarily violate the rule if necessary to perform a critical operation, such as evacuating a host for maintenance, without causing an error. This balances availability with operational practicality.

Incorrect Option

A. Create a 'Must run Virtual Machines to Hosts' anti-affinity rule.
A "Must" rule is too restrictive. It would prevent the two VMs from ever running on the same host. If an administrator attempted to place one of the hosts into maintenance mode, DRS would be unable to vMotion both VMs to the single remaining host without violating the rule, thus blocking the maintenance operation.

B. Create a 'Virtual Machines to Virtual Machines' anti-affinity rule.
This option is incomplete and does not specify the rule type ("Must" or "Should"). More importantly, the standard and correct practice for separating VMs across hosts is to use a "Virtual Machines to Hosts" rule in a specific host group, not a "Virtual Machines to Virtual Machines" rule, which is less common for this specific use case.

C. Create a 'Virtual Machines to Virtual Machines' dependency rule.
A dependency rule is used to define startup/shutdown order for VMs, not to control their placement across hosts for availability. It is unrelated to the requirement of keeping VMs on separate physical servers.

Reference
VMware vSphere Documentation: Creating DRS VM-Host Rules (This guide explains the difference between "Must" and "Should" rules, noting that "Should" rules provide a recommendation that DRS can violate if necessary.)

Storage Policy Based Management

Summary
This question focuses on the mechanism for automating VM storage placement based on custom criteria, such as tags. The goal is to have vCenter automatically select an appropriate datastore for a virtual disk based on a tag assigned to the VM or the disk itself, rather than the administrator manually choosing a datastore. This is a core function of the software-defined storage management framework.

Correct Option

A. Storage Policy Based Management (SPBM):
This is the correct framework. SPBM allows an administrator to create storage policies that define requirements for a VM's storage (e.g., performance, availability, tags). These policies can include rules based on datastore tags. When deploying a VM, the administrator selects the policy, and vSphere automatically places the VM on a datastore whose tags match the policy's rules, achieving tag-based placement.

Incorrect Option

B. Storage I/O Control (SIOC):
SIOC is a feature for managing storage I/O congestion on a datastore. It dynamically allocates I/O resources to VMs during periods of high latency. It does not control initial VM placement or interact with tags for placement decisions.

C. vSphere Storage APIs for Storage Awareness (VASA):
VASA is an enabling technology for SPBM, not the user-facing tool. Storage arrays use VASA Providers to expose their capabilities (e.g., replication, deduplication) to vCenter. SPBM then consumes this information to create more advanced policies, but the administrator uses the SPBM interface, not VASA directly, to create tag-based rules.

D. vSphere Distributed Resource Scheduler (DRS):
DRS is responsible for balancing CPU and memory load across a cluster of ESXi hosts. It manages compute resources, not storage placement. While it integrates with storage DRS (which can use SPBM), DRS itself does not handle tag-based disk placement.

Reference
VMware vSphere Documentation: VMware Storage Policy-Based Management (This guide explains how to use SPBM to create tag-based placement rules for virtual machines.)

Mount the ISO update file to the CD-ROM drive of the vCenter instance
Use the vCenter Management Interface to select the CD-ROM as the source for the update

Summary
This question tests the procedure for performing an offline (air-gapped) patch or update of the vCenter Server Appliance when it cannot access the internet. The administrator must use the VCSA's built-in Management Interface to mount the update ISO file directly, as the vSphere Client is not used for this specific VCSA lifecycle operation.

Correct Option

B. Mount the ISO update file to the CD-ROM drive of the vCenter instance.
Use the vCenter Management Interface to select the CD-ROM as the source for the update. This is the correct and documented procedure for an offline update. The administrator must first make the ISO file available to the vCenter VM, typically by uploading it to a datastore and mounting it as a CD-ROM device. Then, they must log in directly to the vCenter Management Interface (port 5480) to run the update and select the mounted CD-ROM as the repository source.

Incorrect Option

A. Place the update ISO file in a Virtual Machine File System (VMFS) datastore.
Use the vSphere Client to select the update ISO file as the source for the update. This is incorrect. The vSphere Client (HTML5 client) is not used to apply patches or updates to the vCenter Server Appliance itself. This operation is exclusively performed through the vCenter Management Interface.

C. Place the ISO update file in a folder accessible to the vCenter instance over HTTPS.
Use the vCenter Management Interface to select the update file as the source for the update. While the VAMI can use an HTTP/HTTPS URL as a source, this requires setting up a web server. The more direct and common method for a single file is to mount it as a CD-ROM, as described in option B. This option adds unnecessary complexity.

D. Place the ZIP update file in a folder accessible to the vCenter instance over HTTPS.
Use the vSphere Client to select the update file as the source for the update. This is incorrect for two reasons. First, the update file for the VCSA is an ISO, not a ZIP file. Second, as stated in option A, the vSphere Client is not the tool used for updating the VCSA; the VAMI is.

Reference
VMware vSphere Documentation: Update vCenter Server Appliance in an Air-Gapped Environment (This guide outlines the exact steps, which involve mounting the ISO and using the VAMI to perform the update.)