Free 2V0-18.25 practice test: 30 questions with answers

vCenter Server must be at the same or a later release than the ESXi hosts it manages, so it is upgraded first and the hosts follow. Upgrading the hosts first, or upgrading everything at once, leaves vCenter behind the hosts for part of the work.

The Broadcom Compatibility Guide lists which hardware, drivers and ESXi releases are supported together, so it is the correct check before an upgrade. Performance charts, boot logs and virtual machine hardware versions do not show whether the server hardware is supported for the target release.

A file-based backup of the vCenter Server appliance holds its configuration and inventory, which is what is needed to recover from a failed vCenter upgrade. It does not contain guest disks or host memory, and it is not created automatically after an upgrade.

A VIB must be certified for the target release, so it is either updated or removed before the upgrade and reinstalled in a supported version. Ignoring the warning or downgrading vCenter Server does not fix the incompatibility, and vCenter must not be older than its hosts.

ESXi keeps the previous release in an alternate boot bank, which allows the host to be rolled back without a reinstall. Re-adding the host, a fresh installation with restores, or deleting vSAN disk groups do not return the host to its earlier image.

Maintenance mode evacuates the virtual machines from the host through vMotion, so they keep running while the host is removed. Disabling HA and DRS, powering off the host or removing the vMotion adapter would either disrupt running workloads or prevent evacuation.

Enhanced vMotion Compatibility masks CPU features in the cluster down to a common baseline, which lets hosts with different processor generations exchange virtual machines. MTU size, DRS settings and BIOS updates do not change which CPU features an older host can expose.

Scaling out a vSAN cluster means adding hosts that contribute storage, which adds capacity and more fault domains for placing replicas. Hosts do not need virtual machines powered off, storage policies are not deleted, and a stretched cluster is not a prerequisite.

With a cluster image, every host in the cluster is expected to run the same desired image, so the new host must be remediated to it. Keeping a different image, disabling lifecycle management or installing components only on vCenter would not make the host consistent.

Admission control reserves enough capacity to cover the host failures the cluster is configured to tolerate, so a power-on that would consume that reserve is refused. DRS mode, a vMotion fault on one host and the hardware version are not the cause of this message.

A host stays in evaluation mode until a license key from the license inventory is assigned to it. Reinstalling, joining a DRS cluster or changing EVC does not apply a license key to the host.

A license key carries an edition, and the features of that edition are enabled on the host or vCenter Server it is assigned to. Virtual machine counts, hardware generations and boot-time checks are not what a license key controls.

The vSAN feature is controlled by the license edition, so the hosts need a key whose entitlement includes vSAN. An extra VMkernel adapter, a larger appliance disk and a different switch type do not add the missing entitlement.

License keys are assigned from the license inventory to hosts and vCenter Server instances, and each key has an edition and an entitlement quantity that must cover the hosts. Reassigning a key does not remove virtual machines, and a lower edition key does not unlock features of a higher edition.

A virtual machine's hardware version must be supported by the ESXi release on the host where it runs, so it has to be moved to a supported host. VMware Tools updates, memory reservations and snapshot deletion do not change hardware version compatibility.

When vCenter Server cannot resolve the host's name, it cannot establish the management connection, so the host shows as not responding. DRS automation levels, snapshot depth and tool versions do not affect the connection between vCenter and the host.

Certificates have validity periods and Kerberos authentication rejects requests when clocks differ too much, so time synchronization is needed for login and secure connections. Clock differences do not control DRS, and they are not limited to vSAN or to log timestamps.

Consolidation merges the snapshot redo logs back into the base disk, which clears the warning. Deleting virtual disks or removing a datastore would lose data, and adding vCPUs does not merge the snapshot chain.

A stretched cluster uses a witness host at a third site to hold witness components and to break ties when a data site fails. Extra vCenter instances, NFS datastores and Fibre Channel fabrics are not required by the stretched design.

The failures to tolerate setting in a vSAN storage policy determines how many component failures an object can survive, which is what keeps virtual machines running after a failure. Disk group layout, VMFS block size and snapshot retention do not set that tolerance.

Port binding ties VMkernel ports to the software iSCSI adapter so that multipathing uses those specific network ports. It does not create datastores, encrypt traffic or replace zoning, which are separate functions.

Permanent Device Loss means the array has signaled that the device is gone, while all-paths-down means no path responds and access can return. The other statements describe responding paths, an NFS conversion or a reformat, none of which match this condition.

A vSphere Distributed Switch is defined once in vCenter Server and applied to all hosts attached to it, so the settings stay consistent. Standard switches are configured host by host, while VMkernel adapters carry host traffic and host-local bridges have no shared definition.

Hosts keep forwarding frames using the last configuration they received, but changes to a distributed switch are made through vCenter Server. Immediate connection loss, an automatic switch conversion and disabled vMotion are not behaviours of this outage.

Ephemeral binding creates a distributed port when a virtual machine powers on and removes it at power-off, so no port is held while the machine is off. Static binding reserves a port when the virtual machine is connected, and the other options describe behaviours that ephemeral binding does not have.

Nested hypervisors send frames with source MAC addresses that do not match the adapter, which requires forged transmits and MAC address changes to be accepted. Network I/O Control shares and load-based teaming do not control whether those frames are allowed.

VCF Operations collects vCenter data through an adapter instance, so an authentication or connectivity fault there stops metrics from arriving. Log retention, the Orchestrator workflow engine and DRS settings do not control metric collection from vCenter.

Operations for Logs ingests log messages, indexes them and provides search and dashboards over them. Metric collection and forecasting belong to VCF Operations, workflow automation belongs to Operations Orchestrator, and license management is done in the license inventory.

ESXi hosts send their syslog messages to a remote target, so each host's syslog forwarding must point at the Operations for Logs endpoint. VMware Tools, vMotion and vSAN disk groups do not forward host log messages.

Workflows authenticate to vCenter Server through the plug-in endpoint, so the account and password there must be valid and must hold the permissions the workflow uses. Deleting run history or adding hosts does not change how Orchestrator authenticates.