A+ Core 1 PBQ Lab: Fix the VM Network

The correct fix is to move the VM from the host-only virtual network to the Shared NAT network, renew the guest DHCP lease, and then verify gateway, DNS, and repository access.

The key clue is that the VM was cloned from a snapshot used for private host-only testing. A host-only network allows communication between the VM and the host-side virtual adapter, but it does not provide a normal outbound path to the office network or internet-based resources. That explains why the VM can reach a private virtual address but cannot reach the office gateway, DNS, or the update repository. The virtual NIC is connected and the guest has an IP address, so this is not a disconnected adapter problem. The issue is the type of virtual network the VM is attached to.

Shared NAT is the minimum appropriate fix because it gives the VM outbound connectivity through the host while keeping the VM off the office LAN as a directly bridged device. After changing the VM network mode, renewing DHCP is necessary because the guest still has addressing from the old host-only subnet. Once the VM receives the NAT subnet address, gateway, and DNS settings, the technician should verify that the VM can reach the gateway, resolve the update repository name, and connect to the repository.

Changing only DNS would not solve the problem because the VM still lacks a usable route out of the host-only network. DNS can translate a name to an IP address, but it cannot create a default gateway or provide internet access by itself.

Bridging the VM directly onto the office LAN could restore connectivity, but it is broader than necessary. A bridged adapter places the VM directly on the physical network, which may be inappropriate for a cloned training VM and exposes it like another office device. Since the scenario asks for the minimum appropriate configuration change, Shared NAT is the better fit.

Disabling the guest firewall is not supported by the evidence. The VM cannot reach the gateway or update repository because of its network attachment, not because outbound traffic is being blocked by a local firewall. Turning off the firewall would weaken security and still would not correct the missing route from the host-only network.

Leaving the hypervisor attachment unchanged and forcing static guest settings is also the wrong direction. The original problem is that the VM is attached to a network that is not meant to provide outbound access. Static IP settings on the wrong virtual network would either fail outright or create an unstable configuration. The clean fix is to put the VM on the correct virtual network and let DHCP provide the correct address, gateway, and DNS values.