220-1201 Practice Question: A virtual machine running a database server…

Answer analysis

Option-by-option breakdown

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

• ✗

  Increase the virtual disk size

  Why it's wrong here

  Increasing the virtual disk size only allocates more storage capacity for the virtual machine; it does not inherently improve the disk's input/output operations per second (IOPS) or data transfer rates. I/O performance is primarily determined by the underlying physical storage hardware, the hypervisor's I/O scheduler, and the virtual disk format, not merely the allocated volume size. Therefore, this action would not mitigate frequent I/O bottlenecks experienced by a database server.

• ✗

  Use a virtual disk on a network-attached storage (NAS)

  Why it's wrong here

  Placing a virtual disk on Network-Attached Storage (NAS) would introduce significant network latency and overhead to every disk operation. Data requests would traverse the network, adding delays and potential congestion, which would further degrade the I/O performance of a database server. While NAS offers shared storage, it is generally unsuitable for high-performance, low-latency applications like databases due to the inherent network communication layer.

• ✓

  Configure a pass-through disk for the VM

  Why this is correct

  Configuring a pass-through disk, also known as Raw Device Mapping (RDM) in some hypervisors, allows the virtual machine to directly access a physical disk or LUN on the host. This bypasses the hypervisor's virtualized I/O stack, significantly reducing latency and CPU overhead associated with I/O operations. Consequently, the VM achieves near-native disk performance, which is crucial for I/O-intensive applications like database servers experiencing frequent bottlenecks.

• ✗

  Enable disk compression on the virtual disk

  Why it's wrong here

  Enabling disk compression on a virtual disk would attempt to save storage space by compressing data before writing and decompressing it upon reading. This process introduces substantial CPU overhead for every I/O operation, as the host or guest OS must perform real-time compression and decompression. For an I/O-intensive database server, this additional computational burden would severely degrade performance rather than improve it, exacerbating existing I/O bottlenecks.