Vmware Vsphere Foundation Fundamentals practice questions

The cluster must contain no virtual machines powered on with a feature set higher than the baseline.

VMs running with CPU features higher than the EVC baseline will fail to power on or require migration/power-off.

The ESXi host memory usage has crossed the active reclamation threshold, requiring memory reclamation.

Ballooning activates only when the ESXi host's free memory falls below the active reclamation threshold. The host then instructs vmmemctl to reclaim guest pages, so 8 GB inflated confirms host-level pressure rather than guest-level demand.

HA executes the configured isolation response, such as powering off or shutting down VMs on that host.

When heartbeat datastores remain reachable but the management network is lost, HA classifies the host as isolated rather than failed, and applies the configured isolation response to its VMs. This satisfies the stem's isolated-host condition, where the host is alive but unreachable.

Cluster or ESXi host

Deploying from a local workstation OVF requires right-clicking a Cluster or ESXi host, since the wizard targets a compute resource rather than a folder or datastore. This satisfies the stem's requirement to select the correct inventory object that initiates the deployment wizard.

The ESXi hosts must be configured with dedicated high-speed vSphere FT logging networks.

Fault Tolerance replicates VM execution state continuously between hosts, which demands a dedicated, low-latency network for FT logging traffic. Verifying separate high-speed FT logging VMkernel adapters ensures the primary and secondary VMs stay synchronised without competing with management or vMotion traffic.

Configure a DRS automation override for the specific virtual machine to set its automation level to Disabled.

A per-VM automation override set to Disabled stops DRS generating migration recommendations for that virtual machine while cluster-wide fully automated mode continues for all others. This satisfies the constraint of suppressing recommendations for one VM without disabling DRS for the entire cluster.

Datastore heartbeating and VM component protection (VMCP) settings.

Datastore heartbeating detects when a host has failed but its storage remains reachable, letting vSphere HA distinguish network partitions from genuine host failure. VM component protection then handles inaccessible datastores and locked files, restarting the affected virtual machine without waiting for the stale lock held by the surviving host.

Use the global search bar filter with the term 'power:off' or filter by power state in the VMs tab.

The global search bar accepts power-state filters such as 'power:off', returning every powered-off VM across the inventory in one query. This satisfies the requirement to locate these objects efficiently in a large environment, rather than browsing host by host.

Latency Sensitivity set to High on the virtual machine advanced settings.

High Latency Sensitivity disables CPU yielding and dedicates physical cores to the VM.

The processor must support 64-bit x86 execution with hardware virtualization (Intel VT-x or AMD-V) enabled in the BIOS.

ESXi 9.0 requires a 64-bit x86 CPU with Intel VT-x or AMD-V hardware virtualisation exposed and enabled in firmware; without it the hypervisor cannot run 64-bit guests or nested virtualisation, so this must be verified before installation proceeds.

A minimum of 8 GB of physical RAM is required for standard ESXi deployment.

ESXi 9.0 requires at least 8 GB of physical RAM for a standard deployment, so verifying this satisfies the stem's hardware prerequisite before installation. Falling below this threshold causes the installer to abort or the host to operate unsupported, making RAM capacity a mandatory check alongside CPU and storage.

vSphere High Availability (HA) enabled on the cluster.

HA is the cluster service that detects ESXi host failure via heartbeat monitoring and restarts affected virtual machines on surviving hosts, satisfying the automatic-restart requirement. Without HA enabled, host failure leaves VMs down; DRS alone only balances load and cannot restart them.

vSphere Distributed Resource Scheduler (DRS) enabled with automated placement.

DRS with automated placement supplies the resource-availability mechanism: after HA restarts VMs on surviving hosts, DRS balances and places them where capacity exists. It complements HA rather than replacing it, since DRS alone cannot detect host failure or trigger restarts.

Transparent Page Sharing (TPS) to de-duplicate identical memory pages across virtual machines.

Transparent Page Sharing de-duplicates identical memory pages across virtual machines, reclaiming host RAM when physical memory is constrained. ESXi scans for matching page content and maps multiple VMs to a single physical copy, directly satisfying the stem's requirement for a memory reclamation technique reported through esxtop.

Memory ballooning via the vmmemctl driver inside the guest operating system.

Memory ballooning reclaims host memory by inflating a driver inside the guest, forcing it to page out to its own swap file rather than the hypervisor swapping. The vmmemctl driver cooperates with ESXi, so the guest chooses which pages to release, avoiding unpredictable hypervisor-level swapping under the constrained-memory condition described.

Hypervisor-level swapping of virtual machine memory to ESXi swap space.

Hypervisor-level swapping moves virtual machine pages to the ESXi swap file on disk when host memory is exhausted; this reclaims physical RAM at the cost of latency, and is the last-resort reclamation technique esxtop reports.

The command-line utility 'esxtop' executed via an ESXi SSH session.

Running esxtop over an ESXi SSH session provides real-time, per-world CPU, memory, disk and network counters directly from the hypervisor, satisfying the requirement for a built-in method to monitor ESXi and virtual machine performance without additional licensed tooling.

Real-time and historical Performance Charts available directly in the vSphere Client interface.

Performance Charts in the vSphere Client provide both real-time and historical metrics for ESXi hosts and virtual machines, satisfying the requirement for built-in monitoring without extra tooling. They draw on vCenter's statistics database, letting the administrator review CPU, memory, storage and network utilisation directly in the interface.

VMware Aria Operations (formerly vRealize Operations) for advanced analytics and capacity planning.

Aria Operations provides enterprise-grade monitoring, forecasting, and analytics.

vSphere DRS Initial Placement

With DRS in fully automated mode, the initial placement of a newly powered-on VM is decided by vSphere DRS Initial Placement, which selects the host using cluster resource balance. This satisfies the stem's constraint about which component makes that decision.

Distributed Port Mirroring

Distributed Port Mirroring copies traffic from a distributed port group to a monitoring destination, so a packet analyser can inspect live frames. It operates non-disruptively on the VDS, satisfying the requirement to analyse traffic without altering topology.

It places the host into maintenance mode and uses DRS to evacuate virtual machines.

In Automated mode, Proactive HA reacts to a degraded hardware sensor by placing the host into maintenance mode, letting DRS evacuate its VMs before failure occurs. This satisfies the impending memory degradation scenario by proactively relocating workloads.

vSphere vMotion

vSphere vMotion allows live migration of a running VM's compute state and network port group association.

Both ESXi hosts must have access to vCenter Server to negotiate the encryption keys.

Encrypted vMotion across separate vCenter domains requires both ESXi hosts to reach vCenter Server, which negotiates and distributes the encryption keys. Without that vCenter connectivity, the hosts cannot establish the shared session keys the migration needs.

Cross-vCenter vSphere vMotion migration wizard

The cross-vCenter vMotion wizard natively handles migrating compute, network, and storage across disparate vCenter instances.

Key Provider to securely manage and store encryption keys

The Key Provider is a core vSphere Trust Authority architectural element; it securely manages and stores the encryption keys that Trust Authority attestation releases to trusted hosts, enabling encrypted virtual machines to be protected within the vSphere Foundation environment.

Attestation Service to verify the integrity and boot state of ESXi hosts

The Attestation Service is a core Trust Authority component: it validates ESXi host integrity by checking boot measurements against trusted references before hosts are admitted to the trusted state, directly satisfying the requirement to protect encrypted virtual machines.

Trust Cluster containing specialized hosts that manage trust services separately from workload clusters

The Trust Cluster is a core architectural element: it hosts the specialised ESXi hosts that run Trust Authority services, keeping attestation and key management isolated from workload clusters, which satisfies the requirement to protect encrypted virtual machines.