Scenario practice questions

An enterprise storage architect is designing a VMware vSAN datastore within a vSphere Foundation 9.0 cluster using a 2-node direct-connect topology at a remote site. Which architectural component is mandatory to provide a tie-breaker vote and prevent split-brain scenarios?

Trap 1: An active-active dual-controller hardware Fibre Channel bridge.

A Fibre Channel bridge provides block storage connectivity, not quorum arbitration, and vSAN's witness appliance supplies the tie-breaker vote. The bridge tempts architects familiar with shared-storage quorum disks, which suit traditional FC clusters, but vSAN 2-node designs require a witness host instead.

Trap 2: An external physical quorum disk connected via USB to both ESXi…

vSAN's witness is a virtual appliance hosted on a separate ESXi host, not a USB-attached physical quorum disk; USB also cannot be shared between two hosts. The physical disk tempts architects from traditional clustering, where shared quorum LUNs are standard, but vSAN 2-node requires the witness appliance.

Trap 3: A secondary vCenter Server Appliance running in linked mode.

A second vCenter in linked mode provides management redundancy, not quorum arbitration; the vSAN witness appliance casts the tie-breaker vote. Linked-mode vCenter tempts administrators seeking resilience, and it is correct for cross-site management failover, but it cannot resolve vSAN split-brain because it holds no witness role.

A
An active-active dual-controller hardware Fibre Channel bridge.
Why it fails: A Fibre Channel bridge provides block storage connectivity, not quorum arbitration, and vSAN's witness appliance supplies the tie-breaker vote. The bridge tempts architects familiar with shared-storage quorum disks, which suit traditional FC clusters, but vSAN 2-node designs require a witness host instead.
B
An external physical quorum disk connected via USB to both ESXi hosts.
Why it fails: vSAN's witness is a virtual appliance hosted on a separate ESXi host, not a USB-attached physical quorum disk; USB also cannot be shared between two hosts. The physical disk tempts architects from traditional clustering, where shared quorum LUNs are standard, but vSAN 2-node requires the witness appliance.
C
A remote vSAN Witness Node deployed at a separate third failure domain.
In a 2-node direct-connect topology, neither host can hold quorum alone, so a Witness Node in a third failure domain supplies the tie-breaker vote. Without it, a network partition between the two hosts risks split-brain, with both sides claiming the vSAN datastore.
D
A secondary vCenter Server Appliance running in linked mode.
Why it fails: A second vCenter in linked mode provides management redundancy, not quorum arbitration; the vSAN witness appliance casts the tie-breaker vote. Linked-mode vCenter tempts administrators seeking resilience, and it is correct for cross-site management failover, but it cannot resolve vSAN split-brain because it holds no witness role.

Question 2mediummulti select

An enterprise architect is planning vCenter Server 9.0 High Availability (VCHA) in a vSphere Foundation environment. Which THREE nodes comprise a fully configured VCHA deployment? (Choose three.)

Trap 1: Database Replica Node

A Database Replica Node is not a VCHA component; VCHA comprises active, passive and witness nodes, with replication handled by vCenter's built-in PostgreSQL streaming replication. It is tempting because database replication genuinely underpins resilience in deployments using external databases, but VCHA's witness node provides the quorum function instead.

Trap 2: Proxy Controller Node

A Proxy Controller Node does not exist in VCHA; the third node is a witness, which holds the tie-breaking vote and stores no workload data. The tempting confusion arises from NSX-T, where a proxy node forms part of a three-node management cluster, so that term would fit an NSX Manager deployment instead.

A
Active Node
The Active Node runs the live vCenter Server services and holds the active database, serving all management traffic. It is one of the three required VCHA nodes, pairing with the Passive and Witness nodes to form the fault-tolerant cluster.
B
Passive Node
The Passive Node maintains a synchronised replica of vCenter Server state, ready to take over if the Active Node fails. It is the second of the three required VCHA nodes, providing the standby role in the cluster.
C
Database Replica Node
Why it fails: A Database Replica Node is not a VCHA component; VCHA comprises active, passive and witness nodes, with replication handled by vCenter's built-in PostgreSQL streaming replication. It is tempting because database replication genuinely underpins resilience in deployments using external databases, but VCHA's witness node provides the quorum function instead.
D
Witness Node
The witness node provides the quorum tie-breaker in a VCHA cluster, residing at a third site to arbitrate split-brain scenarios between the active and passive nodes. It satisfies the stem's requirement for a fully configured three-node deployment, completing the active, passive and witness topology.
E
Proxy Controller Node
Why it fails: A Proxy Controller Node does not exist in VCHA; the third node is a witness, which holds the tie-breaking vote and stores no workload data. The tempting confusion arises from NSX-T, where a proxy node forms part of a three-node management cluster, so that term would fit an NSX Manager deployment instead.

Question 3mediummulti select

An administrator is managing user access and permissions within a vSphere Foundation vCenter Server environment. Which TWO best practices should be followed when assigning privileges? (Choose two.)

Trap 1: Disable the Administrator@vsphere.local account permanently…

Permanently disabling Administrator@vsphere.local removes the break-glass account needed for recovery when SSO or identity sources fail. Disabling it suits hardening after alternative emergency access exists, but doing so immediately after installation leaves no fallback path for vCenter recovery.

Trap 2: Assign all administrators the Global Administrator role to prevent…

Granting Global Administrator to all administrators violates least privilege and multiplies the blast radius of any compromised account. Broad administrative rights suit a single trusted break-glass identity, not routine operator accounts, which should receive scoped roles at the appropriate inventory level.

Trap 3: Assign permissions directly to individual user accounts for easier…

Direct per-user permission assignment becomes unmanageable at scale and complicates auditing; vCenter best practice assigns permissions to groups and manages membership. Per-user assignment suits very small environments with a handful of stable accounts, not a governed multi-user vSphere Foundation deployment.

A
Assign permissions to Active Directory groups rather than local vCenter users when integrating directory services.
Directory groups centralise authorisation: permissions bind to the group object, so membership changes in Active Directory propagate automatically without editing vCenter roles per user. This satisfies the best-practise requirement for scalable, auditable privilege assignment across the integrated identity source.
B
Apply the principle of least privilege by assigning custom or built-in roles with only necessary access rights.
Least privilege limits each user or group to only the rights their role genuinely requires, reducing accidental or malicious changes. Assigning built-in or custom roles scoped to specific objects satisfies the stem's access-control best practice, rather than granting broad administrative privileges across the vCenter inventory.
C
Disable the Administrator@vsphere.local account permanently immediately after installation.
Why it fails: Permanently disabling Administrator@vsphere.local removes the break-glass account needed for recovery when SSO or identity sources fail. Disabling it suits hardening after alternative emergency access exists, but doing so immediately after installation leaves no fallback path for vCenter recovery.
D
Assign all administrators the Global Administrator role to prevent lockout scenarios.
Why it fails: Granting Global Administrator to all administrators violates least privilege and multiplies the blast radius of any compromised account. Broad administrative rights suit a single trusted break-glass identity, not routine operator accounts, which should receive scoped roles at the appropriate inventory level.
E
Assign permissions directly to individual user accounts for easier tracking.
Why it fails: Direct per-user permission assignment becomes unmanageable at scale and complicates auditing; vCenter best practice assigns permissions to groups and manages membership. Per-user assignment suits very small environments with a handful of stable accounts, not a governed multi-user vSphere Foundation deployment.

Question 4hardmultiple choice

An administrator is designing a multi-cluster vSphere Foundation 9.0 architecture and wants to implement Enhanced vMotion Compatibility (EVC) across clusters containing both Intel Xeon Scalable (Ice Lake) and AMD EPYC (Milan) processors. What is the design limitation regarding EVC in this scenario?

Trap 1: Cross-vendor EVC requires vCenter Server to be deployed on a…

EVC operates purely at the CPU feature-mask level within a vCenter cluster; it has no dependency on vCenter's own host platform or nested virtualisation, so this requirement is fabricated. It is tempting because vCenter deployment topologies and hardware virtualisation settings are genuine design considerations elsewhere, but they do not govern EVC compatibility.

Trap 2: EVC automatically emulates AMD instruction sets on Intel hosts…

EVC masks CPU features presented to VMs; it does not perform binary translation or instruction emulation, which is not how vMotion compatibility is achieved. It is tempting because emulation and translation are real virtualisation techniques, but they belong to other products and cannot reconcile Intel and AMD hosts for live migration.

Trap 3: Cross-vendor EVC is supported as long as the lowest common…

EVC cannot mask the fundamental Intel-versus-AMD instruction-set divergence; SSE4 is a shared subset but the CPUs' differing architectures and feature flags still block cross-vendor vMotion, so no BIOS setting enables it. It is tempting because EVC baselines do expose selectable CPU feature sets for masking within a single vendor.

A
Cross-vendor EVC between Intel and AMD physical processors is architecturally unsupported.
EVC masks CPU feature differences within a single vendor's processor family by presenting a common baseline; it cannot reconcile the fundamentally different instruction sets of Intel and AMD. Cross-vendor EVC is therefore architecturally unsupported, making this the design limitation for the mixed Ice Lake and EPYC clusters.
B
Cross-vendor EVC requires vCenter Server to be deployed on a physical Windows Server with hardware virtualization enabled.
Why it fails: EVC operates purely at the CPU feature-mask level within a vCenter cluster; it has no dependency on vCenter's own host platform or nested virtualisation, so this requirement is fabricated. It is tempting because vCenter deployment topologies and hardware virtualisation settings are genuine design considerations elsewhere, but they do not govern EVC compatibility.
C
EVC automatically emulates AMD instruction sets on Intel hosts using binary translation vCPUs.
Why it fails: EVC masks CPU features presented to VMs; it does not perform binary translation or instruction emulation, which is not how vMotion compatibility is achieved. It is tempting because emulation and translation are real virtualisation techniques, but they belong to other products and cannot reconcile Intel and AMD hosts for live migration.
D
Cross-vendor EVC is supported as long as the lowest common denominator SSE4 instruction set is enabled in the BIOS.
Why it fails: EVC cannot mask the fundamental Intel-versus-AMD instruction-set divergence; SSE4 is a shared subset but the CPUs' differing architectures and feature flags still block cross-vendor vMotion, so no BIOS setting enables it. It is tempting because EVC baselines do expose selectable CPU feature sets for masking within a single vendor.

Question 5mediummultiple choice

An administrator is configuring an alert in vSphere Foundation 9.0 to notify them when an ESXi host loses its connection to primary storage (datastore heartbeat loss). Which type of default alarm in vCenter covers this condition?

Trap 1: Host power state change alarm

Host power state change alarms fire on transitions such as shutdown, standby or reboot, driven by the host's own power management. They suit tracking planned maintenance or unexpected reboots, not loss of connectivity to a datastore.

Trap 2: Virtual machine high availability failover event

A HA failover event fires after the host has already been declared isolated and its VMs restarted elsewhere. It suits tracking availability actions, but it does not alert on the datastore heartbeat loss itself, which precedes and triggers that failover.

Trap 3: Storage I/O control congestion threshold alarm

Storage I/O control congestion thresholds trigger on datastore latency and share throttling, not on heartbeat loss. That alarm is used to protect latency-sensitive workloads during contention, whereas heartbeat loss needs an alarm monitoring datastore connectivity to the host.

A
Host power state change alarm
Why it fails: Host power state change alarms fire on transitions such as shutdown, standby or reboot, driven by the host's own power management. They suit tracking planned maintenance or unexpected reboots, not loss of connectivity to a datastore.
B
Virtual machine high availability failover event
Why it fails: A HA failover event fires after the host has already been declared isolated and its VMs restarted elsewhere. It suits tracking availability actions, but it does not alert on the datastore heartbeat loss itself, which precedes and triggers that failover.
C
Storage I/O control congestion threshold alarm
Why it fails: Storage I/O control congestion thresholds trigger on datastore latency and share throttling, not on heartbeat loss. That alarm is used to protect latency-sensitive workloads during contention, whereas heartbeat loss needs an alarm monitoring datastore connectivity to the host.
D
Datastore accessibility alarm
The Datastore accessibility alarm fires when a host loses connectivity to a datastore, which is exactly the datastore heartbeat loss condition described. It is a default vCenter alarm, so no custom definition is needed to detect the storage disconnection.

Question 6mediummultiple choice

An administrator must guarantee that a business-critical virtual machine always has physical memory reserved so it is never reclaimed by the balloon driver or swapped to a datastore, regardless of host memory pressure. Which vSphere setting should be configured?

Trap 1: Configure a memory limit equal to the virtual machine's configured…

A memory limit caps how much host physical memory a virtual machine may consume; it does not reserve memory. In fact, a limit can cause the guest to reclaim its own memory and can interact badly with reservations. It does nothing to prevent the host from ballooning or swapping the virtual machine's pages, so it fails the stated requirement.

Trap 2: Set the virtual machine swap file location to a high-performance…

Relocating the swap file changes where swapped pages are stored, not whether swapping occurs. Disabling transparent page sharing reduces memory savings, which can increase pressure. Neither option reserves physical memory for the virtual machine, so ballooning and swapping remain possible and the guarantee is not achieved.

Trap 3: Enable memory compression on the host and set a high memory shares…

Shares influence which virtual machines win contention when memory is overcommitted, but they do not guarantee physical memory. Compression is itself a reclamation technique applied under pressure. Neither mechanism prevents ballooning or swapping of the virtual machine's pages, so they cannot provide the hard guarantee that is required here.

A
Configure a memory limit equal to the virtual machine's configured memory size
Why it fails: A memory limit caps how much host physical memory a virtual machine may consume; it does not reserve memory. In fact, a limit can cause the guest to reclaim its own memory and can interact badly with reservations. It does nothing to prevent the host from ballooning or swapping the virtual machine's pages, so it fails the stated requirement.
B
Set the virtual machine swap file location to a high-performance datastore and disable page sharing
Why it fails: Relocating the swap file changes where swapped pages are stored, not whether swapping occurs. Disabling transparent page sharing reduces memory savings, which can increase pressure. Neither option reserves physical memory for the virtual machine, so ballooning and swapping remain possible and the guarantee is not achieved.
C
Set the virtual machine's memory reservation equal to its configured memory size
A memory reservation guarantees that amount of physical host memory for the virtual machine. When the reservation equals the configured memory, the VMkernel cannot reclaim any of that memory through ballooning or swapping, because the full amount is protected. This directly satisfies the requirement that the virtual machine never lose physical memory to host pressure.
D
Enable memory compression on the host and set a high memory shares value for the virtual machine
Why it fails: Shares influence which virtual machines win contention when memory is overcommitted, but they do not guarantee physical memory. Compression is itself a reclamation technique applied under pressure. Neither mechanism prevents ballooning or swapping of the virtual machine's pages, so they cannot provide the hard guarantee that is required here.

Question 7mediummultiple choice

An IT architect is designing a new vSphere Foundation 9.0 environment that must support a 25 GbE storage network with end-to-end lossless Ethernet for iSCSI traffic. The physical switches are already configured for Priority Flow Control and Data Center Bridging. Which ESXi network construct should the architect design to meet this requirement?

Trap 1: A standard vSphere Standard Switch with a dedicated VMkernel…

A vSphere Standard Switch can carry iSCSI traffic and jumbo frames, but it cannot apply or negotiate Priority Flow Control or DCB exchange with the physical fabric, so the lossless end-to-end requirement would not be met. Jumbo frames only reduce per-packet overhead; they do not prevent frame drops during congestion, which is exactly what the design must guarantee.

Trap 2: A vSphere Distributed Switch with Network I/O Control version 3…

Network I/O Control provides bandwidth allocation and prioritization inside the host, but it does not perform Priority Flow Control or DCB exchange with the physical switch. High shares only influence contention among host traffic; they cannot make the external fabric lossless, so frames can still be dropped under congestion.

Trap 3: A vSphere Distributed Switch with a dedicated VMkernel adapter on a…

Removing the teaming policy does not create lossless behavior; the distributed switch still needs DCB configuration to signal PFC to the upstream switch. Without a DCB-capable configuration, congestion on the 25 GbE link can drop iSCSI frames, causing SCSI retries and latency spikes that violate the stated design goal.

A
A vSphere Distributed Switch with a dedicated VMkernel adapter and Data Center Bridging enabled for the iSCSI traffic class
The vSphere Distributed Switch supports DCB configuration, which lets ESXi participate in PFC and priority-based flow control with the upstream fabric. Combining that with a dedicated VMkernel adapter isolates iSCSI traffic and gives the lossless behavior the design requires, matching the switches that are already configured for PFC and DCB.
B
A standard vSphere Standard Switch with a dedicated VMkernel adapter and jumbo frames enabled
Why it fails: A vSphere Standard Switch can carry iSCSI traffic and jumbo frames, but it cannot apply or negotiate Priority Flow Control or DCB exchange with the physical fabric, so the lossless end-to-end requirement would not be met. Jumbo frames only reduce per-packet overhead; they do not prevent frame drops during congestion, which is exactly what the design must guarantee.
C
A vSphere Distributed Switch with Network I/O Control version 3 enabled and shares set to High for the iSCSI VMkernel adapter
Why it fails: Network I/O Control provides bandwidth allocation and prioritization inside the host, but it does not perform Priority Flow Control or DCB exchange with the physical switch. High shares only influence contention among host traffic; they cannot make the external fabric lossless, so frames can still be dropped under congestion.
D
A vSphere Distributed Switch with a dedicated VMkernel adapter on a VLAN that has no teaming policy applied
Why it fails: Removing the teaming policy does not create lossless behavior; the distributed switch still needs DCB configuration to signal PFC to the upstream switch. Without a DCB-capable configuration, congestion on the 25 GbE link can drop iSCSI frames, causing SCSI retries and latency spikes that violate the stated design goal.