220-1201 Practice Question: A technician is troubleshooting a server 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 replacement drive is of a different RPM.

  Why it's wrong here

  While a drive's RPM influences its raw sequential read/write speed, a slight difference in RPM for a single replacement drive is unlikely to be the primary cause of a significantly slow RAID 6 rebuild. The rebuild process is bottlenecked more by the extensive I/O operations across all remaining drives, the complex double parity calculations performed by the controller, and the sheer volume of data (4 TB) that must be read and written. The overall array performance and controller processing power are typically more critical factors than a minor RPM variation in one drive.

• ✗

  The RAID controller is faulty.

  Why it's wrong here

  A faulty RAID controller typically manifests with more severe symptoms than merely a slow rebuild. Common indicators of a failing controller include complete array failure, inability to detect drives, data corruption, system crashes, or persistent I/O errors. While a severely degraded controller could contribute to slowness, the primary and more definitive signs of a faulty controller are usually critical operational failures, making a slow rebuild alone an unlikely sole symptom.

• ✗

  The array is performing background consistency checks.

  Why it's wrong here

  Background consistency checks are distinct operations from a drive rebuild and are not automatically initiated by a drive replacement. Consistency checks verify the integrity of data and parity across the array, often scheduled periodically or run manually. A drive replacement triggers a rebuild to reconstruct the lost data onto the new drive. While both are resource-intensive, they are separate processes, and a rebuild's slowness is due to its inherent data reconstruction demands, not concurrent consistency checks.

• ✓

  The large capacity of the drives and the double parity overhead are causing the slow rebuild.

  Why this is correct

  RAID 6 rebuilds are inherently slow due to the necessity of calculating two independent parity blocks (P and Q) for each data stripe. This process requires reading data from all remaining operational drives to reconstruct the missing data, performing intensive computational parity calculations, and then writing the reconstructed data and updated parity to the new drive. With 4 TB drives, the immense volume of data amplifies these I/O and CPU demands, making the rebuild a prolonged and resource-intensive operation.

Go deeper

Related to this question