AWS Certified Solutions Architect – Professional — Question 337

An ecommerce website running on AWS uses an Amazon RDS for MySQL DB instance with General Purpose SSD storage. The developers chose an appropriate instance type based on demand, and configured 100 GB of storage with a sufficient amount of free space.
The website was running smoothly for a few weeks until a marketing campaign launched. On the second day of the campaign, users reported long wait times and time outs. Amazon CloudWatch metrics indicated that both reads and writes to the DB instance were experiencing long response times. The CloudWatch metrics show 40% to 50% CPU and memory utilization, and sufficient free storage space is still available. The application server logs show no evidence of database connectivity issues.
What could be the root cause of the issue with the marketing campaign?

Answer options

• A. It exhausted the I/O credit balance due to provisioning low disk storage during the setup phase.
• B. It caused the data in the tables to change frequently, requiring indexes to be rebuilt to optimize queries.
• C. It exhausted the maximum number of allowed connections to the database instance.
• D. It exhausted the network bandwidth available to the RDS for MySQL DB instance.

Correct answer: A

Explanation

Amazon RDS General Purpose SSD (gp2) storage volumes under 1 TB receive a baseline performance of 3 IOPS per GB, meaning a 100 GB volume has a baseline of only 300 IOPS but can burst up to 3,000 IOPS using an I/O credit balance. During a sustained high-traffic event like a marketing campaign, these burst credits are eventually depleted, causing performance to drop to the low baseline and resulting in high read/write latency. Other options are incorrect because the application logs show no connection issues (ruling out connection limits) and CPU/memory utilization remains low (ruling out query/indexing bottlenecks and network-driven CPU exhaustion).