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

Physical-to-virtual (P2V) conversion captures the existing operating system, application and data as a virtual machine that can run on new hosts without a rebuild. The containerized option requires rebuilding the application, dual-boot does not virtualize anything, and copying only data files leaves out the operating system and application configuration.

A Type 1 (bare-metal) hypervisor runs directly on the physical hardware and schedules the virtual machines itself. The first option describes a Type 2 hypervisor, while the second and fourth options misstate how ESXi is installed and used.

Snapshots are delta files kept alongside the VM and are not an independent backup, so they should be consolidated once the change is verified and a real backup solution should protect the VM. Keeping the snapshot as a backup, converting it to a template, or relying on vMotion to copy it are all incorrect because snapshots are not replicated or self-sufficient backups.

Hardware-assisted virtualization relies on CPU features such as Intel VT-x and AMD-V, which reduce the overhead of privileged guest operations. A hypervisor is still required, and the hypervisor still mediates device access except in specific, explicitly configured passthrough cases.

EVC masks CPU features down to a common baseline so that hosts with different processor generations present compatible CPUs for vMotion. Distributed Power Management saves energy, HA admission control reserves failover capacity, and Storage I/O Control arbitrates datastore I/O, so none of them solves CPU compatibility.

A content library stores and manages templates, OVF/OVA packages and ISO files, which members can then use for deployments. Storage DRS balances datastore placement, host profiles apply host configuration, and distributed port groups define networking, so none of them stores templates.

A subscribed content library synchronizes its items from a published library, which keeps templates consistent across sites. Manual file copies are error-prone and never sync, vSphere Replication protects VM disks rather than distributing library items, and a datacenter object cannot be used to share templates.

DRS balances CPU and memory demand across hosts in the cluster and, when fully automated, migrates VMs without administrator action. HA restarts VMs after failures, FT protects a single VM with a live secondary, and Storage DRS balances datastores rather than host load.

The failures to tolerate setting determines how many failures an object can survive while staying accessible, so a value of one protects against a single failure. Stripe width affects how data is spread, space reservation affects capacity commitment, and force provisioning only allows creation without meeting the policy, so none of them explains the tolerance.

RAID-5 erasure coding with one failure tolerated protects against a single failure with less raw capacity overhead than mirroring. Two-failure mirroring uses more copies, zero failures to tolerate gives no protection, and a space reservation adds capacity commitment without adding any protection.

The Express Storage Architecture (ESA) pools devices in a single tier, while the Original Storage Architecture (OSA) uses disk groups with separate cache and capacity tiers. Stretched clusters describe site topology and an NFS export is not a vSAN datastore, so neither describes a tier design.

Storage policy-based management defines storage requirements as policies and reports whether VM objects comply with them. Storage I/O Control prioritizes I/O, Storage DRS balances placement, and Network I/O Control manages network bandwidth, so none of these checks compliance.

A vSphere Distributed Switch is a single switch object managed through vCenter Server across all attached hosts, and it supports Network I/O Control. Standard switches are configured per host, internal-only switches have no uplinks, and standard switches do not inherit settings from a cluster.

vMotion traffic carries the memory and execution state of running VMs during live migration. Management traffic handles control communication, vSAN traffic replicates storage objects, and provisioning traffic is used for cold migrations and cloning rather than live moves.

Promiscuous mode and forged transmits both default to Reject, which blocks guests from receiving others' traffic or sending spoofed source addresses. Route based on originating virtual port is a load balancing method and Notify switches is a failover setting, so neither is a security policy.

Network I/O Control uses shares to prioritize traffic types such as VM, vMotion and vSAN when bandwidth is contended. Port mirroring and NetFlow only observe traffic, and load-based teaming spreads flows across uplinks without ranking traffic types.

The vSphere Supervisor runs a Kubernetes control plane inside vSphere, and the VKS service uses it to provision guest Kubernetes clusters on request. Replication, a container engine on each host, and Fault Tolerance do not provide self-service cluster provisioning.

A vSphere Namespace is the tenancy boundary in the Supervisor, where permissions, resource limits and storage policies are applied for a group. A port group, a single-host resource pool or a content library cannot provide that boundary on its own.

VKS clusters are described and requested through Kubernetes API objects, and their nodes are virtual machines placed by vSphere on ESXi hosts. A dedicated vCenter Server per cluster is not required, and VKS does not remove the need for DRS or HA in the infrastructure beneath the Supervisor.

A VM class specifies the compute profile, including vCPU, memory and reservations, that node VMs are created with. Storage policies control placement and encryption of disks, resource pools control share-based allocation, and port groups control networking, so none of them defines the VM size.

When adding by name fails but by IP succeeds, name resolution is the likely fault, so forward and reverse DNS records must exist and match. The browser language, the vMotion adapter and the datastore format do not affect whether a host name resolves.

Authentication tokens and certificates depend on consistent clocks, so vCenter Server and every host should synchronize to the same reliable NTP source. vCPU count, MTU and datastore free space have no effect on clock skew.

DNS and NTP should be working before vCenter Server is deployed, and hosts join a cluster only after ESXi is installed on them. Managing hosts by IP address only removes name-based reliability, and vSAN cannot be enabled on a cluster without hosts and disks.

vMotion and DRS rely on each host seeing the same port groups and VMkernel networking, so those must match across the cluster. Mixed ESXi builds, missing DNS names and disabling vMotion all work against the cluster's behavior.

A custom role that holds only the power and reset privileges, assigned on the folder, grants exactly what the group needs within that scope. The Administrator role at the root is far too broad, local root accounts sit outside vCenter role assignments, and Read-Only cannot power VMs on or reset them.

vCenter Single Sign-On authenticates users against configured identity sources such as Active Directory. The certificate authority issues certificates, the local root account is not directory based, and the Supervisor control plane has no role in vCenter sign-in.

vSphere licensing applies to hosts and vCenter Server instances, and the license edition determines which features are available. Virtual machines do not carry their own keys, and licenses can be reassigned rather than fixed permanently to a host.

A policy applied to a group of matching objects controls which alert definitions and thresholds apply to them, which scopes the alerting to that business unit. A report, a view and a dashboard display information but do not by themselves generate scoped alerts.

Dashboards arrange widgets that show selected metrics, alerts and summaries so operators can monitor quickly. Policies are configured separately, dashboards do not store vCenter event logs, and VCF Operations does not replace the vCenter inventory.

Reports are generated from templates, can run on a schedule, and can be shared as files, which suits a periodic summary for finance. Alerts signal conditions rather than summarize capacity, super metrics calculate a single value, and auto-refresh only changes how a dashboard displays data.