Free VMware 3V0-23.25 Practice Test Questions and Answers (2026)

In VMware vSAN, a portion of the raw capacity must be kept free (historically referred to as "slack space") to ensure cluster health and performance. This unusable capacity is primarily required for two reasons. First, the Operational Reserve is necessary for internal vSAN operations, including storage policy changes, data rebalancing, and background data movement. Second, even if the explicit "Host Rebuild Reserve" is deactivated in the UI, space must still be architecturally reserved for host upgrade overhead. During host maintenance or upgrades, data must be evacuated to other hosts in the cluster to maintain compliance with the Failures to Tolerate (FTT) policy. Together, these operational and maintenance requirements account for the capacity that cannot be safely consumed by virtual machine workloads.

A. Encryption overhead: vSAN encryption requires minimal metadata space per disk and does not consume a significant percentage (e.g., 20%) of the cluster's raw capacity.

B. RAID Overhead: RAID-1 (mirroring) requires 100% overhead (consuming half the raw space for replicas), which dictates consumed capacity rather than a ~20% cluster-level unusable reserve.

E. VM swap overhead: VM swap space is considered actively consumed capacity allocated to running virtual machines, not a cluster-level reserve or unusable raw capacity.

1. VMware by Broadcom. VMware vSAN 8.0 Planning and Deployment Guide. Section: "About vSAN Capacity Reserves" and "Designing and Sizing vSAN Hosts". Document ID: vsan-80-planning-deployment-guide.

2. VMware Core Tech Zone. vSAN Design Guide. Section: "Capacity Planning" (Slack Space Requirements for Operations and Host Maintenance). Available at: https://core.vmware.com/resource/vsan-design-guide

In a vSAN Data-at-Rest Encryption architecture, the Key Management Server (KMS) provides the Key Encryption Key (KEK) used to wrap the Disk Encryption Keys (DEKs). If a host is rebooted, it must retrieve the KEK to unlock its storage devices. While hosts with a Trusted Platform Module (TPM) can securely persist the KEK across reboots, a host without a TPM must request the KEK directly from the KMS. If the KMS is unavailable during the reboot, the host will successfully boot into ESXi, but it will be unable to decrypt and mount its vSAN storage devices until KMS connectivity is restored.

A: The host does not automatically enter maintenance mode; it boots normally but cannot mount the encrypted disks.

B: The ESXi hypervisor itself is not encrypted by vSAN encryption and will boot successfully from its boot device.

D: Without a TPM, the host cannot securely cache the KEK across reboots, preventing it from mounting disks.

VMware vSAN 8.0 Administration Guide

Chapter 11: vSAN Security

Section: "vSAN Encryption and Key Management Server".

VMware vSphere 8.0 Security Guide

Chapter 4: Securing ESXi Hosts

Section: "Trusted Platform Module".

To enable vSAN Data-at-Rest Encryption, vCenter Server must be able to communicate with a Key Management Server (KMS) or a vSphere Native Key Provider (NKP). For both the Original Storage Architecture (OSA) and the Express Storage Architecture (ESA), a fundamental prerequisite is establishing a trusted KMS identity (or Key Provider) within vCenter before encryption can be activated at the cluster level. This trust ensures that the ESXi hosts can securely retrieve the Key Encryption Keys (KEKs) required to encrypt the Data Encryption Keys (DEKs). Neither architecture strictly requires Trusted Platform Modules (TPMs) for basic data-at-rest encryption, although TPM 2.0 is highly recommended for advanced security features like vSphere Trust Authority and secure host attestation.

B: ESA does not strictly require TPMs to enable standard vSAN Data-at-Rest Encryption; a trusted key provider is the primary requirement.

C: OSA fully supports external KMS integration via the Key Management Interoperability Protocol (KMIP).

E: OSA does not strictly require TPMs for basic vSAN encryption, similar to the ESA architecture.

1. VMware vSAN 8.0 Documentation

"Administering VMware vSAN" -> "vSAN Encryption Prerequisites".

2. VMware vSphere 8.0 Security Guide

Section: "Key Management Server (KMS) and vCenter Server Trust".

In the vSAN Express Storage Architecture (ESA), the concept of disk groups with dedicated cache and capacity tiers is removed. Instead, all NVMe storage devices within an ESXi host are aggregated into a single, flat storage pool. Because there is no caching drive that dictates the availability of a disk group, the failure domain is reduced to the individual storage device itself. In this scenario, the host has 12 storage devices of 4 TB each contributing to the storage pool. If a single storage device fails, only the capacity of that specific device is impacted. Therefore, the loss of one out of 12 devices results in an 8.3% (1/12) reduction in the overall storage capacity of that specific host, making the architecture highly resilient.

A. 50%: Incorrect because this would imply a failure domain of half the host's drives, which applies to OSA with two disk groups where a cache drive fails, not ESA.

B. 25%: Incorrect because this implies a failure of 3 out of 12 drives or a 4-disk group OSA architecture, which does not apply to the single storage pool in ESA.

D. 0%: Incorrect because the failure of a 4 TB storage device physically removes its capacity from the host's storage pool, reducing the available raw capacity.

- VMware vSAN 8.0 Express Storage Architecture (ESA) Design Guide

Section: "Storage Pool Architecture and Failure Domains".

- VMware vSAN 8.0 Administrator Guide

Chapter: "Managing vSAN ESA Storage Pools".

vSAN Express Storage Architecture (ESA) utilizes a single-tier storage architecture, eliminating the concept of dedicated cache and capacity drives. When vertically scaling a vSAN ESA cluster by adding drives, using the same model and capacity ensures balanced storage consumption across all hosts, preventing capacity bottlenecks. It also guarantees improved predictability of storage performance, as all I/O operations are serviced by drives with identical performance characteristics. Furthermore, standardizing on the same hardware components leads to consistent maintenance procedures, simplifying troubleshooting, firmware updates, and hardware replacements.

A: vSAN ESA uses a single-tier architecture; there are no dedicated cache drives.

D: vSAN ESA does not use disk groups with cache and capacity tiers.

F: vSAN File Services configuration has no bearing on the physical drive models or capacities required for scaling.

VMware vSAN 8.0 Documentation

"vSAN Express Storage Architecture (ESA) Concepts

" Section: Single-Tier Architecture.

VMware vSAN Design Guide

"Scaling vSAN Clusters

" Section: Vertical Scaling Best Practices.

VMware Kubernetes Service (VKS) leverages the vSphere Container Storage Interface (CSI) plug-in to manage and provision persistent volumes (PVs). The vSphere CSI officially supports creating Static Persistent Volumes from pre-provisioned infrastructure storage. It enables dynamic resizing through both Online Volume Expansion (expanding a volume currently attached to a running pod) and Offline Volume Expansion (expanding a detached volume). Recent VCF updates also introduce 4kn Support for advanced format drives on VMFS-local, vSAN, and NFS datastores, and the ability to provision a Full Clone from Volume Snapshot. Conversely, Storage DRS and Flash Read Cache are not supported for CSI persistent volumes, and Storage vMotion with attached persistent volumes is natively restricted.

Broadcom TechDocs: "Storage for VKS Clusters." VMware Cloud Foundation 9.0 Documentation: vSphere Supervisor Concepts. (Document Identifier: storage-for-tanzu-kubernetes-grid-clusters.html). This document confirms that the vSphere CSI supports "Full Clone from Volume Snapshot", "4kn Support", "Static Persistent Volume", "Offline Volume Expansion", and "Online Volume Expansion".

Broadcom TechDocs: "Persistent Volume Expansion for TKG Service Clusters." VMware vSphere 8.0 Documentation: Managing Storage. (Document Identifier: persistent-volume-expansion-for-tkg-service-clusters.html). This section validates that Supervisor clusters natively support both offline and online volume expansions for block volumes.

Broadcom TechDocs: "Dynamic Storage." Tanzu Kubernetes Grid 2.5 Documentation: Workload Clusters Storage. (Document Identifier: workload-clusters-storage.html). This documentation explicitly confirms the architectural limitation that "vSphere CSI does not support Storage DRS."

The official VMware procedure for manually restarting a vSAN cluster involves several distinct phases. The three valid steps from your provided image are:

1. Exit all hosts from maintenance mode so they can actively participate in forming the cluster.
2. Run the python reboot helper script only on one ESXi host (reboot_helper.py recover) to safely orchestrate the rebuild from a single node and prevent multi-host conflicts.
3. Enable cluster member updates from vCenter Server on all ESXi hosts. After the cluster has successfully recovered, you must run esxcfg-advcfg -s 0 /VSAN/IgnoreClusterMemberListUpdates on every host. This is the mandatory final step to re-enable normal vCenter updates across the cluster.

VMware vSphere 8.0 Documentation, vSAN Administration Guide, Section: "Restart the vSAN Cluster Manually". (Details the exact procedure, including the final instruction to re-enable vCenter cluster member list updates on all hosts once recovery is complete).

VMware vSphere 7.0 Documentation, vSAN Administration Guide, Chapter: "Shut Down and Restart the vSAN Cluster", Section: "Manually Restart the vSAN Cluster".

VMware Cloud Foundation (VCF) categorizes storage configurations into principal storage (required during workload domain or cluster creation) and supplemental storage (provisioned post-deployment). vSAN ESA is fully supported as the principal storage for the Management Workload Domain (WLD) default cluster, additional management clusters, and Virtual Infrastructure (VI) WLDs. A disaggregated vSAN Storage Cluster is not supported for the initial Management WLD default cluster since the initial cluster mandates a localized standard principal storage architecture, but it operates as principal storage for subsequent Management WLD clusters and VI WLDs. Fibre Channel uniquely acts as both principal and supplemental storage across all three domain categories. NFS v4.1 functions strictly as supplemental storage across all domains.

Broadcom TechDocs, VMware Cloud Foundation Concepts, "Storage Models" (v9.1), August 2026. (Backs the distinction between principal and supplemental storage configurations).

Dell/VMware InfoHub, Architecture Guide—VMware Cloud Foundation 5.1 on VxRail, "Storage Options," Table 15. (Backs vSAN ESA support as principal storage across Management and VI WLDs).

VMware Docs, vSAN FAQs, May 2026. (Backs the limitation that vSAN Storage Clusters are not supported as principal storage for the initial management domain cluster).

McDonald, Jonathan. "Converging VMware vSphere to VMware Cloud Foundation 9.0: The Top 10 Questions Answered," VMware Cloud Foundation Blog, April 16, 2026. (Backs Fibre Channel as a dual-role storage option and NFS restrictions).

In a VMware vSAN Stretched Cluster, Site A (Production) and Site C (New Hardware) serve as the active Data Sites, housing the ESXi hosts. Site B, having no capacity for large physical hardware, serves as the Witness Site to maintain quorum.

To achieve the requirement of "minimal disruption from issues with Spanning Tree Protocol (STP)," Layer 3 routing is deployed across all site links. Layer 3 isolates fault domains and prevents Layer 2 broadcast storms and STP loops from spanning across data centers.

For latency, data-to-data links (Site A to C) require less than 5 ms RTT. For data-to-witness links, because the cluster is deploying exactly 10 hosts total (5 per site), it qualifies for the VMware specification allowing up to 500 ms RTT (clusters with 10 or fewer hosts per site).

VMware by Broadcom. (n.d.). vSAN Planning and Deployment Guide: vSAN Stretched Cluster Network Requirements. Retrieved from VMware Official Documentation. (Specifies the RTT latency limits: < 5 ms for data sites, and up to 500 ms for witness sites with 10 or fewer hosts per site).

VMware by Broadcom. (n.d.). vSAN Network Design Guide: Layer 2 vs Layer 3. Retrieved from VMware Official Documentation. (Details the strong recommendation for Layer 3 topologies between data sites to mitigate STP complexities and isolate broadcast domains).

To stretch a vSAN cluster in a VMware Cloud Foundation (VCF) Workload Domain, specific architectural conditions apply.

• The default management vSphere cluster must already be stretched to ensure centralized management components are highly available across both availability zones.
• The cluster cannot include hosts originating from different subnets or networks (L3) within an individual availability zone.
• VCF does not support stretching clusters that incorporate Data Processing Unit (DPU)-backed hosts.
• The cluster being stretched must not share a vSAN Storage Policy with any other cluster. Options such as SSH activation requirements or the use of host Self-Signed certificates are not explicit blocking constraints for the stretched cluster preparation workflow.

Broadcom TechDocs, VMware Cloud Foundation, "Stretching vSAN Clusters in VMware Cloud Foundation," Section: Prerequisites and Limitations.

Broadcom TechDocs, VMware Cloud Foundation, "Stretch a vSAN ESA or OSA Cluster Using the SDDC Manager API," Section: Prerequisites.