220-1201 Practice Question: A technician is troubleshooting a VM that…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The host's ECC RAM has detected a memory error

  Why it's wrong here

  ECC (Error-Correcting Code) RAM is designed to detect and correct single-bit memory errors, preventing system crashes due to minor data corruption. While uncorrectable multi-bit errors can cause system instability, a host-level memory issue would typically impact the entire hypervisor and all running virtual machines, not just a single VM, and certainly not in a manner directly correlated with a virtual CPU configuration change within one specific VM. Therefore, this is an an unlikely cause for a single VM's crashes after a vCPU modification.

• ✗

  The VM's virtual disk is fragmented

  Why it's wrong here

  Virtual disk fragmentation occurs when files on the virtual disk are stored in non-contiguous blocks, leading to increased read/write head movement and slower I/O performance. While severe fragmentation can degrade a VM's responsiveness and application loading times, it is highly improbable to cause kernel panics or blue screen crashes within the guest operating system. Such crashes are typically indicative of deeper system instability, often related to hardware, drivers, or core OS components, rather than disk organization.

• ✓

  The guest OS does not support symmetric multiprocessing (SMP) properly

  Why this is correct

  When a virtual machine is configured with multiple virtual CPUs (vCPUs), the guest operating system must be designed to handle symmetric multiprocessing (SMP). If the guest OS, or its installed drivers, lacks proper SMP support or has an outdated kernel, adding a second vCPU can introduce race conditions, deadlocks, or incorrect interrupt handling between the processors. This fundamental incompatibility often manifests as immediate and frequent kernel panics, blue screen errors, or unexpected reboots, directly correlating with the change in vCPU configuration.

• ✗

  The hypervisor's CPU scheduler is overloaded

  Why it's wrong here

  A hypervisor's CPU scheduler manages the allocation of physical CPU resources among all running virtual machines. If this scheduler becomes overloaded, it indicates that the host's physical CPU capacity is insufficient to meet the collective demands of all VMs. This scenario would typically result in a general performance degradation across all virtual machines, characterized by sluggishness and high CPU readiness times, rather than causing specific kernel-level crashes within a single VM. The issue would be widespread performance throttling, not isolated system instability.

Go deeper

Related to this question