SOA-C02 Monitoring, Logging, and Remediation Practice Question
A SysOps administrator is troubleshooting a slow-running RDS MySQL instance. The administrator notices that the ReadIOPS metric is consistently high, but the WriteIOPS is low. The instance type is db.m5.large with 300 GB of General Purpose SSD (gp2). What is the most likely cause?
⚠ Common exam trap
Many candidates assume a slow database is always due to an undersized instance type, overlooking that gp2 volumes have a burst credit mechanism that can be exhausted by sustained high read I/O even with low write activity.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The gp2 volume is experiencing I/O credit exhaustion.
A db.m5.large instance with 300 GB of gp2 storage has a baseline IOPS of 900 (3 IOPS per GB) and a burst balance of 5.4 million I/O credits. With consistently high ReadIOPS and low WriteIOPS, the volume is likely exhausting its I/O credit balance, causing performance throttling. This is a classic symptom of gp2 I/O credit exhaustion, where read-heavy workloads deplete the burst bucket, leading to degraded performance.
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 instance type is too small for the workload.
Why it's wrong here
The RDS instance class determines vCPU and memory, but for gp2 storage, the baseline IOPS and burst capability are governed by the volume's size in GiB, not the instance type. Resizing the instance vertically would not raise the gp2 volume's baseline IOPS, so the I/O credit exhaustion — and resultant throttling — would persist unchanged.
- ✗
The database is experiencing write contention.
Why it's wrong here
Write contention occurs when multiple sessions compete for row or table locks, typically surfacing as elevated WriteIOPS, high lock wait time, or increased queue depth. Because the reported WriteIOPS is low, the database's write path is not saturated; the bottleneck is instead a read-heavy pattern that is depleting the gp2 burst balance, making write contention an implausible diagnosis.
- ✗
The network bandwidth is insufficient.
Why it's wrong here
Network bandwidth is the throughput of the connection between the application and the RDS endpoint, and it does not affect how EBS volumes deliver disk I/O. The throttling symptom is caused by the EBS volume's credit exhaustion, which is a storage-level constraint independent of network throughput; even with unlimited network bandwidth, the volume would still throttle to its baseline IOPS.
- ✓
The gp2 volume is experiencing I/O credit exhaustion.
Why this is correct
Correct: a gp2 volume has a baseline of 3 IOPS per GiB and can burst to 3,000 IOPS by consuming I/O credits stored in a bucket. Once the BurstBalance reaches zero, the volume is hard-throttled to the baseline rate, which would make the database appear 'slow running.' The fix is to increase volume size (raising baseline), migrate to gp3, or enable Provisioned IOPS.
Go deeper
Related to this question
About these practice questions
One of 1,169 original SOA-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.