5V0-2121 Sample Questions & Answers

Modern CPUs with the AES-NI instruction set significantly accelerate encryption/decryption operations, making the performance impact of vSAN native encryption negligible for most workloads. vSAN is highly optimized to leverage this. RAID-6 (Erasure Coding) is the most space-efficient method for achieving FTT=2. While RAID-1 offers better performance for write-intensive workloads, the combination of a well-designed all-flash cluster and AES-NI acceleration makes the RAID-6 and native encryption combination a valid and efficient design that meets all stated requirements without significant compromise.

Once a host boots, it retrieves the Key Encryption Key (KEK) from the KMS and uses it to decrypt the Host Encryption Key (HEK), which in turn decrypts the Disk Encryption Keys (DEKs). The KEK is then cached in memory. As long as the host is running, it does not need to contact the KMS for normal I/O. Therefore, existing VMs run without issue. However, operations that require a new key or re-authentication with the KMS, such as powering on a new encrypted VM or rebooting a host (which would require fetching the KEK again), will fail until KMS connectivity is restored.

Upgrading the on-disk format is necessary to enable the features and optimizations introduced in the newer version of vSAN. While the cluster can operate in a mixed mode with an older on-disk format for backward compatibility, you cannot use new capabilities (like larger capacity device support, enhanced checksums, or certain performance algorithms) until the format is upgraded across the cluster.

In a hybrid vSAN architecture, the cache tier (comprised of flash devices) serves two functions: it acts as a write buffer to acknowledge writes quickly and destage them to the capacity tier (magnetic disks) later, and it serves as a read cache to store frequently accessed data blocks, improving read performance. This is crucial for VDI workloads which can have bursty I/O patterns, especially during boot storms.

vSAN uses a quorum-based system to prevent split-brain scenarios. To be active, a VM object must have access to more than 50% of its components. In a network partition, only the partition containing the majority of a VM's components will keep the object active. The two-host partition does not have a majority of the cluster nodes, and therefore any objects within it will lose quorum and become inaccessible, even if all their components reside on those two hosts. The larger four-host partition will retain ownership of the objects.

VMware has a strict requirement for vSAN stretched clusters that the round-trip time (RTT) latency between the two main data sites must be 5ms or less. A latency of 7ms exceeds this maximum supported threshold and would result in an unsupported configuration that is prone to performance issues, timeouts, and potential data inconsistency. Therefore, the design is invalid and the network latency must be addressed before proceeding.

The Object Repair Timer is a configurable setting (defaulting to 60 minutes) that dictates the delay before vSAN initiates a rebuild for an absent or degraded component. This delay is designed to prevent unnecessary resynchronization traffic during transient events, such as a host reboot or a brief network outage. If the component becomes available again before the timer expires, no rebuild is necessary.

Changing the failure tolerance method from RAID-1 (mirroring) to RAID-5/6 (erasure coding) requires a complete change in the object's component layout. vSAN will initiate a resynchronization task to create the new RAID-5/6 components and remove the old RAID-1 components.

RAID-1 (mirroring) for FTT=1 consumes 2x the storage of the source data. RAID-5 (erasure coding) for FTT=1 consumes only 1.33x the storage. Therefore, changing from RAID-1 to RAID-5 will result in a significant reduction in the overall storage consumption for that object once the resynchronization is complete.

This is true. The primary purpose of the vSAN iSCSI Target Service is to provide block-level storage from the vSAN datastore to external, non-vSphere workloads. This includes physical servers (e.g., for Microsoft Clustering) or other hypervisors that require shared block storage and have an iSCSI initiator.

A single vSAN Witness Appliance can be configured as a 'Shared Witness' to provide witness components for multiple 2-node vSAN clusters. As of vSAN 7.0 U1, a single shared witness can support up to 64 2-node clusters. While this doesn't cover all 80 sites, the most efficient first step is to enable this feature and add as many new sites as possible. Since the case states they need to support all 80, this implies deploying a second shared witness would be the ultimate solution, but enabling the existing one is the correct, most efficient first action. A single shared witness is far more resource and management efficient than deploying one witness per ROBO site.