Free 3V0-21.23 Practice Test Questions 2026

Explanation:

To make NFS-based shared storage secure in a vSphere environment, the architect must focus on network-level isolation and access control. NFS is an IP‑based protocol (TCP/UDP 2049) and does not support block‑storage authentication methods like CHAP, nor does it run over Fibre Channel.

A. Create a dedicated storage network – Correct.
A physically or logically separate network (dedicated NICs, switches, or subnets) for NFS storage traffic prevents interference from management, vMotion, and VM traffic. It also reduces attack surface by limiting which hosts can reach the NFS server.

B. Create a dedicated VLAN – Correct.
Even when physical infrastructure is shared, a dedicated VLAN for NFS provides Layer 2 isolation. This prevents ARP spoofing, IP conflicts, and unauthorized access from other VLANs, and simplifies firewall rules and storage access control lists (e.g., allowing NFS only from the storage VLAN).

Why other options are incorrect:

C. Create a CHAP password – Incorrect.
CHAP (Challenge Handshake Authentication Protocol) is used exclusively for iSCSI authentication, where it provides mutual or one-way authentication between the initiator (ESXi host) and target (storage array). NFS does not support CHAP. NFS security relies on IP-based export rules (exports file), UNIX file permissions, or Kerberos authentication (krb5/krb5i/krb5p). Configuring a CHAP password would have no effect on NFS connectivity.

D. Create dedicated volumes for sensitive data – Incorrect.
While creating dedicated volumes or datastores for sensitive data is a valid security and data governance practice, it is not a design decision related to the storage connectivity or protocol security for the NFS environment. The question specifically asks about design decisions for the shared storage environment in the context of NFS connectivity. Dedicated volumes address data segregation, not network or authentication security for the NFS protocol itself.

E. Create a dedicated Fibre Channel network – Incorrect.
NFS is an IP‑based protocol that requires TCP/IP networking. Fibre Channel (FC) is a separate, lossless transport protocol used for block-level storage access (e.g., FCP, FCoE, NVMe/FC). NFS cannot traverse a Fibre Channel network unless it is first encapsulated over IP (which is not standard or supported in vSphere). Therefore, creating a dedicated FC network would not serve NFS connectivity at all.

Reference

VMware vSphere Security Configuration Guide – Network segmentation: Dedicated storage networks and VLANs for NFS, iSCSI, and vMotion are recommended to isolate traffic and reduce risk.

VMware vSphere Storage Guide – NFS best practices: Use dedicated VLANs/subnets, separate physical NICs (or VMkernel ports on isolated networks), and restrict NFS access by IP address. CHAP is documented only under iSCSI authentication.

Explanation:

The workshop requirements specify three key constraints:
ESXi hosts can only be configured via vCenter (no local configuration)
DCUI service must be disabled
SSH service must be disabled

These requirements collectively mean that no direct, interactive access to the ESXi host console (DCUI) or remote command-line access (SSH) is permitted. Only vCenter Server should manage the host configuration.

A. Strict Lockdown Mode – Correct.
In Strict Lockdown Mode, the DCUI service is completely stopped, and SSH access is disabled by default. Even the default "root" account cannot access the ESXi host directly via DCUI or SSH. The only way to manage the host is through vCenter Server. This matches all three workshop requirements exactly.

Why other options are incorrect:

B. Normal Lockdown Mode – Incorrect.
In Normal Lockdown Mode, the DCUI service is still available for the root user (or other users in the DCUI Access group). While SSH is disabled by default, the DCUI remains accessible, which violates the requirement that "the Direct Console User Interface (DCUI) service must be disabled."

C. Normal Lockdown Mode with a defined Exception User list – Incorrect.
Adding exception users does not change the fact that Normal Lockdown Mode still allows DCUI access. The requirement explicitly states the DCUI service must be disabled, not just restricted. Exception users are typically added to allow specific accounts (e.g., a backup user) to access the host directly, which contradicts the requirement that "any configuration can only be completed via vCenter."

D. Strict Lockdown Mode with a defined Exception User list – Incorrect.
While Strict Lockdown Mode does disable DCUI and SSH, adding exception users creates a security exception that allows specific user accounts to access the DCUI or SSH. This violates the requirement that no direct configuration (DCUI or SSH) should be possible. The workshop explicitly requires these services to be disabled, not selectively enabled for exception users.

Reference
VMware vSphere Security Configuration Guide (vSphere 8.x) – Lockdown Modes:
Normal Lockdown Mode – DCUI available for root/DCUI Access group; SSH disabled by default.

Explanation:

The customer needs to reduce manual reconfiguration after an ESXi host failure. They cannot back up ESXi hosts due to backup software limitations but want to automate the restoration of host settings.

B. Configure a host profile per cluster – Correct.
A Host Profile captures all ESXi configuration settings (networking, storage, security, services) from a reference host. After a failed host is reinstalled with a basic ESXi image, the administrator attaches the host to the cluster and applies the Host Profile. This automatically reapplies the complete configuration without any manual intervention, directly addressing the requirement to reduce manual effort.

Why other options are incorrect:

A (CLI backups) – Incorrect.
The customer’s backup software does not support ESXi. Relying on unsupported manual CLI scripts increases complexity and maintenance burden, not reducing manual effort.

C (Custom ISO) – Incorrect.
A custom ISO only standardizes the ESXi installation image. It does not apply post-install configuration settings. Manual reconfiguration would still be required after installation.

D (RAID1 boot volumes) – Incorrect.
RAID1 protects against a single boot disk failure but does not help when a host fails completely (e.g., motherboard failure) or needs replacement. Manual reconfiguration would still be necessary.

Reference

VMware vSphere Host Profiles (vSphere 8.x) – Automates host configuration and reduces recovery time after host failure.

VMware vSphere Configuration Management – Host Profiles are the recommended method for consistent, repeatable ESXi configuration without backup software dependencies.

Explanation:

In design methodologies, technical (non-functional) requirements describe how a system performs its functions — focusing on qualities like scalability, security (as a system property), performance, reliability, and maintainability. Functional requirements describe what the system does (specific features or behaviors).

C. SIEM system must be scalable to 20,000 events per second – Correct (technical/non-functional). Scalability is a classic non-functional requirement, defining performance and capacity under load.

D. Storage must be configured with data-at-rest encryption – Correct (technical/non-functional). Encryption at rest is a security attribute and system property (confidentiality, compliance), not a specific user-visible function.

E. The hosting platform limits access to authorized users – Correct (technical/non-functional). This describes a security property (authentication and authorization), not a specific feature. It defines how the platform controls access.

Why other options are incorrect:

A. Clustered firewall at perimeter with all traffic routing via it – Incorrect
(functional). This specifies a particular solution component and its behavior — what the firewall does (routes all ingress/egress traffic). It describes a feature or architecture component, not a quality attribute.

B. Distributed firewall securing traffic for all virtualized workloads – Incorrect
(functional). This describes a specific security feature that must be present and what it secures (workload traffic). It is a functional capability.

F. System events from workloads, hypervisor, firewall, management components must be monitored – Incorrect
. This defines a specific activity (monitoring) and scope. It is a functional requirement for logging and oversight.

Reference

VMware Design Methodology (VCAP-DCV Design) – Functional requirements define what the solution does (features, actions). Non-functional (technical) requirements define how well it does it (performance, scalability, security properties, availability).

ISO/IEC 25010 – Quality Models– Scalability, confidentiality (encryption), and access control (authorization) are classified as non-functional quality attributes.

Explanation:

C. The different processor architecture within a single site will remediate against a single vSphere Lifecycle Manager image. – Correct. vLCM images are assigned per cluster. A cluster cannot contain hosts with different CPU vendors (Intel vs. AMD) if using a single vLCM image because the image includes vendor‑specific drivers and firmware. However, within a single site (or single cluster with homogeneous CPUs), all hosts share the same vLCM image. Different sites with different CPU architectures require separate clusters and separate vLCM images.

Why other options are incorrect:

A – Incorrect. A shared vLCM baseline across both sites with different processor architectures is not supported. Baselines/images are vendor‑specific.

B – Incorrect. Different processor architectures cannot be in the same cluster when using vLCM images. The cluster would fail compliance checks.

D – Incorrect. A single vLCM image cannot be used across different CPU architectures (Intel vs. AMD) across sites. Separate clusters and images are required.

Reference

VMware vSphere Lifecycle Manager (vLCM) Documentation (vSphere 8.x) – vLCM images are cluster‑specific and require homogeneous CPU vendor (Intel or AMD) across all hosts in the cluster.

VMware Compatibility Guide – Different processor architectures require separate clusters and separate vLCM images.

Explanation:

Performance design considerations focus on how the system behaves under load, including resource ratios, hardware selection for speed/latency, and proactive scaling based on utilization thresholds.

B. vCPU to pCPU ratio may not exceed 5:1 – Correct.
This is a performance constraint that controls CPU overcommitment. Exceeding this ratio can lead to CPU contention, scheduling delays, and increased ready time, directly impacting VM performance.

E. CPU purchases will favor clock speed and last level cache over cores per socket – Correct.
Clock speed and cache size directly affect per-core performance, which is critical for latency‑sensitive or single‑threaded workloads. This is a hardware selection decision made specifically for performance.

F. Additional ESXi hosts will be added when CPU or memory exceeds 70% for 3 consecutive business days – Correct.
This is a proactive performance‑based scaling policy. Adding hosts before sustained high utilization prevents resource contention and maintains performance headroom.

Why other options are incorrect:

A. Path Selection policy round robin with every SCSI command – Incorrect.
This is a storage availability or load balancing setting, not directly a performance design consideration in this context. While round robin can improve throughput, the customer statement is about configuration detail, not a high‑level performance design principle.

C. Capacity planning not exceed 70% peak‑average utilization on deployment – Incorrect.
This is a capacity planning / risk management constraint (ensuring headroom for growth or spikes), not a performance design factor. Performance is about latency, throughput, and responsiveness, not just utilization ceilings.

D. All ESXi hosts must have four paths to the storage array – Incorrect.
This is an availability and redundancy requirement (multipathing for fault tolerance), not a performance design consideration. Performance can be achieved with fewer paths if bandwidth is sufficient.

Reference

VMware vSphere Performance Design Guide (VCAP-DCV Design) – Defines performance considerations: vCPU:pCPU ratios, CPU selection (clock speed/cache), and scaling policies based on sustained utilization.

VMware Performance Best Practices for vSphere 8.x – CPU overcommitment limits; adding hosts proactively to avoid contention

Explanation:

The customer is asking for the ability to easily identify and apply patches or updates to ESXi hosts, including pre‑staging files on the hosts. This directly relates to how easily the system can be operated, maintained, and updated over its lifecycle.

B. Manageability – Correct.
Manageability refers to the ease with which administrators can monitor, configure, update, and maintain the system. Features like patch identification, automated remediation, and pre‑staging updates are core manageability capabilities. vSphere Lifecycle Manager (vLCM) and Update Manager are examples of tools that provide this quality.

Why other options are incorrect:

A. Recoverability – Incorrect.Recoverability is the ability to restore service after a failure (backups, snapshots, disaster recovery). Patching and updates are preventative maintenance, not recovery.

C. Performance – Incorrect.Performance focuses on throughput, latency, and responsiveness of workloads. Patching processes do not directly define performance.

D. Availability – Incorrect. Availability is the percentage of time a service is operational. While patching can affect availability (e.g., maintenance mode), the customer is referencing the ease of patching, not the uptime itself.

Reference

VMware Design Methodology (VCAP-DCV Design) –Manageability is a non‑functional requirement that includes patch management, lifecycle operations, and administrative ease.

vSphere Lifecycle Manager Documentation – Pre‑staging ESXi updates and image‑based remediation are manageability features.

Explanation:

A business outcome is a measurable result that directly contributes to the organization's strategic goals, competitive advantage, or long-term value creation. It goes beyond project execution details (timelines, quality, relationships) and focuses on what the business gains from the investment.

A. Build a strong foundation for future projects, including cloud infrastructures
– Correct. This describes a strategic, long-term business benefit — enabling future initiatives, reducing future costs, or supporting cloud adoption. It directly impacts the organization's ability to grow or transform.

Why other options are incorrect:

B. Ensure project timelines and milestones are met – Incorrect. This is a project management outcome (on-time delivery). While important, it does not itself deliver business value; it is a means to an end.

C. Maintain high standards of quality and professionalism – Incorrect. This is a project quality or governance requirement, not a business-level result. Quality supports outcomes but is not the outcome itself.

D. Develop and maintain strong relationships with key stakeholders – Incorrect. This is an organizational or collaboration enabler, not a direct business outcome. Good relationships facilitate success but are not measured as business value delivered.

Reference

VMware Design Methodology (VCAP-DCV Design) – Business outcomes are strategic benefits (e.g., enabling cloud, reducing TCO, supporting growth). Project outcomes include timelines, budgets, and quality standards.

ITIL 4 – Business Value – Business outcomes relate to value, risk reduction, and capability enablement, not internal project metrics.

Explanation:

An assumption in a design document is a statement believed to be true but not yet verified. If an assumption is incorrect, it creates a risk to the project. The architect must document risks that directly stem from unverified assumptions.

D. The customer may not have an existing licensing subscription that covers features the architect intends to use
– Correct. The assumption states that the customer will provide licensing. However, the architect may be assuming the license edition (e.g., Enterprise Plus vs. Standard) or features (e.g., vSAN, DRS, NIOC) are available. If the customer’s actual license lacks required features, the design cannot be implemented as intended.

E. The customer may not have sufficient data center cooling, power, and physical rack space available
– Correct. The assumption states these resources are sufficient for scale. If this is false, the environment cannot grow as planned, leading to capacity failures or hardware installation delays.

Why other options are incorrect:

A. The assumptions must be approved by the customer, architect and the architect’s company
– Incorrect. This is a process or governance requirement, not a risk. Approval is a project management activity, not a consequence of an unverified assumption.

B. The storage may not have capacity to accommodate 20% year over year virtual machine growth
– Incorrect. The assumption said storage has sufficient capacity for future workload scale, but it did not specify 20% growth. This introduces a new, unstated condition. However, the risk should be that the assumption itself is false, not a specific growth rate unless agreed upon.

C. The licenses provided by the customer only have support entitlement for one year
– Incorrect. The original assumption said nothing about support duration. This introduces an extra condition not derived from the stated assumption. If support length is critical, it should have been captured as an assumption or constraint first.

Reference

VMware VCAP Design Methodology – Assumptions must be validated; unvalidated assumptions create risks. Common risks include missing license features, insufficient power/cooling/space.

Risk Management for vSphere Designs – Risks are uncertain events that, if realized, negatively impact the project. Likelihood and impact should be documented alongside each assumption.

Explanation:

The requirements demand centralized network security policy enforcement, default deny between workloads, support for containers, and integration with network monitoring — all of which point to an overlay‑based, software‑defined networking and security platform.

D. VMware NSX, Distributed Firewalls and Port Mirroring – Correct.
VMware NSX provides centralized policy management, segmentation, and supports both VMs and containers (via NSX Container Plugin).

Distributed Firewalls enable per‑workload firewall rules with default‑deny posture, applied consistently across virtual machines and containers.

Port Mirroring (SPAN/ERSPAN) allows traffic to be copied to the security team’s network monitoring solution.

Why other options are incorrect:

A. VMware Standard Switches (VSS), Access Lists, Promiscuous mode – Incorrect.
VSS is host‑local, not centralized. Access lists are primitive and not scalable for default‑deny micro‑segmentation. Promiscuous mode is for sniffing, not policy enforcement. No container support.

B. Distributed Virtual Switches (VDS), Access Lists, Promiscuous mode – Incorrect.
VDS provides centralized networking but not advanced security. Access lists on VDS are limited and do not provide default‑deny or container security. Promiscuous mode does not enforce policies.

C. VMware Carbon Black, Distributed Virtual Switches, Traffic Filtering – Incorrect.
Carbon Black is an endpoint detection and response (EDR) tool, not a network security policy engine. It does not provide default‑deny network segmentation between workloads or container networking security.

Reference

VMware NSX Documentation (vSphere 8.x) – NSX Distributed Firewall provides per‑workload micro‑segmentation with default‑deny posture, supporting VMs and containers.

VMware NSX Port Mirroring – Enables traffic replication for monitoring, troubleshooting, and security analytics tools.

Explanation:

C: Dedicated vSphere Cluster
In vSphere 8.x, a cluster must be consistent in its use of DPUs. To ensure that the latency-sensitive application utilizes the hardware offloading capabilities of the AMD DPUs, these hosts should be placed in a dedicated cluster. This avoids compatibility issues with non-DPU hosts and ensures that Distributed Resource Scheduler (DRS) and High Availability (HA) only move the workload between hardware-compatible nodes.

D: Network Offloads Compatibility
To leverage the DPU, the Network Offloads property must be enabled on the vSphere Distributed Switch. This setting allows the ESXi networking stack to offload services (like UPT, filtering, or encryption) to the DPU hardware, significantly reducing CPU overhead and decreasing latency for the stock trading application.

E: vSphere Distributed Switch (VDS) 8.0.0
vSphere Distributed Services Engine (which manages DPUs) is a new feature that requires VDS version 8.0.0. The existing VDS version 7.0.0 or even 7.0.3 cannot recognize or manage DPU offloading. Deploying a new VDS at version 8.0 specifically for the DPU-enabled hosts is a requirement to enable the "Network Offloads" mode.

Why Other Options are Incorrect

A & F: Version 7.0.3 switches do not support the vSphere Distributed Services Engine. While upgrading existing switches (Option F) is possible, it is often safer in a brownfield environment to deploy a new 8.0 switch specifically for the new DPU hardware to isolate the mission-critical traffic and ensure dedicated configuration.

B: While NTP is a best practice for any vSphere environment, it is not a specific requirement for enabling DPU hardware or resolving the latency/offloading needs described in this scenario.

References

VMware vSphere 8.0 Documentation: Introducing vSphere Distributed Services Engine.

VMware vSphere Advanced Design Guide: Networking Design for Latency-Sensitive Workloads.

Explanation:

The goal is to ensure that application dependencies are respected during recovery after a host failure. vSphere HA uses Restart Priority to control the order in which VMs are restarted. Higher priority VMs start first. Dependencies are:

Application A (Workloads 1 & 2) depends on Workload 3
Application B (Workloads 2 & 4) depends on Workload 3
Application C (Workload 5) depends on Workload 4

From this dependency tree:

Workload 3 is required by Applications A and B — must start first.

Workload 4 is required by Application C and also depends on Workload 3 (since App B includes Workload 4 and depends on 3) — must start after Workload 3.
Workloads 1, 2, and 5 depend on 3 or 4 — start last.

Thus:
High priority: Workloads 3 and 4
Medium priority: Workload 5 (depends on 4)
Low priority: Workloads 1 and 2 (depend on 3)

C. Set vSphere HA to Restart VMs in response to a Host Failure – Correct. This is the standard HA action for host failure. The Restart Priority settings match the dependency analysis exactly: 3 & 4 = High, 5 = Medium, 1 & 2 = Low.

Why other options are incorrect:

A – Incorrect. Workload 4 is set to Medium, but it should be High because Workload 5 depends on it, and Workload 4 itself depends on Workload 3. Medium priority would delay Workload 5 unnecessarily.

B – Incorrect. It uses "Shut Down and Restart VMs in response to a Host Isolation" instead of Host Failure. Host isolation is a different scenario (network partition). The question specifies recovery from a host failure. Also, priority settings are incorrect.

D – Incorrect. Uses the wrong HA response (Host Isolation) and places Workload 4 in Medium instead of High. Workload 4 must be High priority because Workload 5 depends on it and it must follow Workload 3.

Reference

VMware vSphere Availability Guide (vSphere 8.x) – vSphere HA Restart Priority determines startup order based on dependencies. Higher priority VMs are restarted before lower priority ones.

VMware Design Best Practices – For dependent workloads, set the dependency root to High priority, direct dependents to Medium, and leaves to Low.