Diagnosing high I/O wait on a database volume

WHAT THIS TESTS The interviewer wants a structured diagnosis of an I/O bottleneck and knowledge of the specific block-storage levers, rather than a reflexive resize.

A GOOD ANSWER COVERS First measure. Use tools like iostat to see IOPS, throughput, average queue depth, and latency, and compare them to the volume's provisioned limits. A general-purpose SSD has a baseline tied to its size plus a burst credit balance; sustained load can exhaust those credits, causing throttling that looks like a sudden slowdown. Also check the instance type's own EBS or storage bandwidth ceiling, since a small instance caps aggregate throughput regardless of the volume. Look at the database for missing indexes or unnecessary full scans amplifying I/O. To resolve, switch to a provisioned-IOPS volume for guaranteed sustained performance, increase the volume size to raise the baseline IOPS, choose an instance with higher storage bandwidth, or add an in-memory cache to absorb reads.

COMMON WRONG ANSWERS Immediately upgrading CPU or RAM when the bottleneck is disk, fixing nothing. Ignoring burst-credit exhaustion on general-purpose SSDs. Overlooking the instance-level bandwidth cap. Skipping the query layer, where a missing index can multiply I/O needlessly.

LIKELY FOLLOW-UPS How do burst credits work on general-purpose SSD volumes. When do you choose provisioned IOPS versus a larger gp volume. How does the instance type limit storage throughput. How can read replicas or caching reduce the I/O load.

ONE CONCRETE EXAMPLE A reporting database slows every afternoon. iostat shows queue depth climbing and latency spiking while IOPS plateau at the volume's baseline. The team finds the general-purpose SSD has burned through its burst credits under sustained load. They migrate to a provisioned-IOPS volume sized for the steady-state demand and add an index that eliminated a heavy full scan, after which I/O wait drops and the afternoon stall disappears.