vSphere Architecture, Products and Solutions practice questions

Enable vSphere DRS and set the migration threshold to the most aggressive setting.

Why it fails: DRS balances workloads across hosts but does not restart VMs after a host failure; that is vSphere HA's function. It tempts because aggressive migration thresholds tune placement responsiveness, yet without HA enabled no failover occurs, and the aggressive setting also increases migration churn rather than protecting availability.

Enable vSphere Fault Tolerance on all VMs in the cluster.

Why it fails: Fault Tolerance maintains a live shadow copy per protected VM, consuming a full host's resources for each pair, so four hosts cannot protect many VMs without waste. It tempts for maximum availability, but the requirement to minimise resource waste points to vSphere HA admission control instead.

Configure vSphere Replication for all VMs to replicate to a secondary site.

Why it fails: vSphere Replication provides asynchronous replication to a secondary site for disaster recovery, not host-failure protection within the cluster. It tempts because replication addresses site-level outages, but the scenario concerns host failures in one four-host cluster, where vSphere HA restarts VMs with reserved capacity.

Increase the size of the VCSA virtual disk using vSphere Web Client.

Why it fails: This does not reclaim space; it only adds more space.

Use the Windows Disk Cleanup utility on the VCSA.

Why it fails: VCSA runs on Linux, not Windows.

Manually delete files from the /storage/archive directory using SSH.

Why it fails: Manual deletion may risk removing essential files and is not recommended.

Use a single VMkernel port for NFS and configure it with the highest priority.

Why it fails: Single port can become a bottleneck; multiple ports with load balancing are better.

Enable jumbo frames on the NFS VMkernel port and the physical switches.

Why it fails: Jumbo frames can improve performance but require end-to-end support and may not resolve latency issues.

Increase the disk queue depth on the VM's virtual SCSI controller.

Why it fails: This might increase throughput but does not address network latency.

Deploy a single VCSA with embedded PSC on a standalone host.

Why it fails: A single VCSA on a standalone host has no redundancy, so host or appliance failure takes down every vCenter service. Standalone embedded deployments suit labs or non-critical environments; the HA policy requires vCenter High Availability or a vSphere cluster.

Deploy a VCSA with an external PSC, and install the PSC on a separate VM.

Why it fails: An external PSC on a separate VM adds a second appliance whose failure breaks authentication, and it does not make vCenter services highly available. External PSC topologies suit environments needing shared SSO across multiple vCentres, not single-site HA requirements.

Deploy two VCSAs in separate vCenter Single Sign-On domains and configure multi-site.

Why it fails: Two separate Single Sign-On domains cannot provide high availability for a single vCenter's services; they isolate independent management domains instead. Multi-site replication suits geographically dispersed sites needing cross-domain visibility, not protecting one embedded-PSC appliance. High availability here requires a second PSC and vCenter behind a load balancer within one SSO domain.

A VM that has a snapshot for backup purposes.

Why it fails: FT does not support VMs with snapshots.

A VM with a physical RDM (Raw Device Mapping) attached.

Why it fails: FT does not support physical RDMs.

A VM with 16 vCPUs that requires high availability.

Why it fails: FT supports only up to 8 vCPUs.

Decrease the DRS migration threshold to level 1 to minimize migrations.

Why it fails: Lowering the threshold to level 1 makes DRS less aggressive, so it will tolerate the 90% versus 50% memory imbalance rather than remediate it. The threshold governs how aggressively DRS corrects imbalance. A conservative threshold suits stable clusters where minor imbalance is acceptable, not one host averaging 90% memory.

Create an affinity rule to keep VMs on Host A, as they are critical.

Why it fails: An affinity rule pins the VMs to Host A, directly preventing DRS from migrating them off the overloaded host and cementing the 90% memory pressure. Affinity rules exist to keep interdependent VMs together for licensing or latency reasons, not to protect critical workloads, which HA and resource reservations address instead.

Disable DRS and manually migrate VMs from Host A to Host B and C during a maintenance window.

Why it fails: Disabling DRS removes automated load balancing entirely, so the imbalance recurs after each manual migration and no ongoing remediation occurs. Manual migration suits one-off maintenance or environments without shared storage and vMotion, but here DRS is already licensed and enabled, making automation the intended mechanism.

All Paths Down: The device or resource is currently in use.

Why it fails: Incorrect — this definition belongs to 'Device or Resource Busy', not 'All Paths Down'.

Permission Denied: All storage paths to a LUN are unavailable.

Why it fails: Incorrect — this definition belongs to 'All Paths Down', not 'Permission Denied'.

The VM needs to be powered off and back on to reset the vNIC.

Why it fails: Incorrect: Power cycle is not a permanent fix.

The E1000 vNIC is not supported in ESXi 7.0; VMXNET3 must be used.

Why it fails: Incorrect: E1000 is supported; VMXNET3 is recommended but not required.

The E1000 driver is incompatible with ESXi 7.0.

Why it fails: Incorrect: E1000 is still supported in ESXi 7.0.

DRS automation level is set to 'Manual'.

Why it fails: Incorrect. DRS is described as fully automated, so the automation level is not set to Manual.

The cluster has DRS set to manual mode.

Why it fails: Incorrect. DRS is set to fully automated, not manual mode.

The vMotion network is not configured.

Why it fails: Incorrect. While a missing vMotion network would prevent migrations, the question states DRS is fully automated, implying vMotion is configured and functional. The most probable cause is the threshold setting.

Use Clone Host functionality in vSphere Client.

Why it fails: Incorrect: Clone Host is for manual deployment.

Use Host Profiles to attach the profile to the cluster.

Why it fails: Incorrect: Host Profiles require the host to be added first.

Use vCenter Server to add the host manually.

Why it fails: Incorrect: Manual addition does not automate profile application.

The VM's virtual disks must be stored on shared storage.

Why it fails: Incorrect: vMotion does not require shared storage.

Both hosts must be in the same cluster.

Why it fails: Incorrect: Cross-cluster vMotion is possible.

Both hosts must be in the same vCenter Server instance.

Why it fails: Incorrect: Cross-vCenter vMotion is possible.

Storage vMotion

Why it fails: Incorrect: Storage vMotion is available in Standard.

vSphere HA

Why it fails: Incorrect: HA is included in Standard.

vSphere vMotion

Why it fails: Incorrect: vMotion is available in Standard.

The datastore is formatted with VMFS version 6.82.

Why it fails: Incorrect: 6.82 is the minor version; major version is 6.

The datastore supports ESXi 6.5 and later.

Why it fails: Incorrect: VMFS-6 supports ESXi 6.0+.

The datastore has 1 TB capacity.

Why it fails: Incorrect: Capacity is 2 TB (2097152 MB).

vSphere DRS is set to partially automated.

Why it fails: Incorrect: 'drs_automation_level' is 'fullyAutomated'.

The cluster can tolerate two host failures.

Why it fails: Incorrect: 'ha_failover_host_slots' refers to slots, not hosts.

The cluster has admission control disabled.

Why it fails: Incorrect: 'ha_admission_control_enabled' is true.

1000

Why it fails: 1000 was the limit in vSphere 6.x.

500

Why it fails: 500 is not a standard limit.

4000

Why it fails: 4000 is the limit for enhanced linked mode, not a single vCenter.

5.12 TB

Why it fails: This is with FTT=1 RAID-1.

2.56 TB

Why it fails: This assumes no replication overhead.

10.24 TB

Why it fails: This is overestimated; would be for FTT=3.

Both vCenter Servers become unavailable.

Why it fails: They do not depend on each other for local management.

One vCenter Server takes over management of both data centers.

Why it fails: No automatic takeover occurs.

vSphere HA on both clusters reactivates the link.

Why it fails: vSphere HA does not manage network links between vCenter Servers.

Use a host profile to apply the configuration.

Why it fails: Host profiles are separate from vLCM.

Replace the host hardware to match the baseline.

Why it fails: Unnecessary; can manage with different images.

Manually install the same ESXi version on the host before adding to the cluster.

Why it fails: vLCM should manage installation if host is compatible.

MTU configuration

Why it fails: MTU configuration is available on both standard and distributed switches, so it is not exclusive to vDS.

VLAN support

Why it fails: VLAN support is available on both standard and distributed switches, though vDS offers additional VLAN capabilities. It is not exclusive.

Port mirroring (NetFlow)

Why it fails: Port mirroring (NetFlow) is also a vDS-only feature, but the question requires choosing exactly two; LACP and Network I/O Control are the more commonly tested features.

Storage I/O latency

Why it fails: Storage DRS considers this, not DRS.

VM power state

Why it fails: Power state is known but not a balancing factor.