A municipal database volume cannot keep up with transaction writes even though the VM CPU has free headroom. What bottleneck class should the team investigate first?
Select an answer to reveal the explanation.
Short Explanation
The CPU is sitting there with free time, but the disk cannot swallow the write flood — like a kitchen with plenty of cooks and a clogged sink. Check storage IOPS and throughput before you buy more vCPU. Wrong bottleneck, wrong fix.
Full Explanation
When a municipal database volume cannot keep up with transaction writes while VM CPU still has free headroom, the bottleneck class is storage IOPS or throughput rather than a pure compute shortage. Teams should investigate volume performance limits, queue depths, burst credits, and storage-tier ceilings before upsizing vCPU counts that will not relieve write latency. DNS cache size on citizen home routers is unrelated to database write throughput inside the city’s VPC. Color profiles on the public website theme do not throttle database volumes. Idle GPU drivers on a machine-learning notebook that is not in the transaction path are a distraction from diagnosing storage performance. Exam caveat: Cloud+ troubleshooting items reward identifying the constrained resource—CPU, RAM, network, or storage—using evidence rather than upgrading every tier indiscriminately. Operational check: review volume IOPS and throughput metrics plus throttling events, compare against provisioned limits, move the database to a higher-performance disk tier or increase provisioned IOPS, retest write latency under payroll or permitting load, and only then reconsider compute size if CPU becomes saturated after storage is fixed.