DBS-C01 · Question #346
An online bookstore uses Amazon Aurora MySQL as its backend database. After the online bookstore added a popular book to the online catalog, customers began reporting intermittent timeouts on the chec
The correct answer is A. Turn on Performance Insights for the Aurora MySQL database. Configure and turn on Amazon. Performance Insights is the purpose-built AWS tool for automatically detecting and diagnosing database performance issues - it visualizes database load, surfaces top SQL queries, and shows wait events like locking/row-level contention in a continuous, automated way, directly solv
Question
An online bookstore uses Amazon Aurora MySQL as its backend database. After the online bookstore added a popular book to the online catalog, customers began reporting intermittent timeouts on the checkout page. A database specialist determined that increased load was causing locking contention on the database. The database specialist wants to automatically detect and diagnose database performance issues and to resolve bottlenecks faster. Which solution will meet these requirements?
Options
- ATurn on Performance Insights for the Aurora MySQL database. Configure and turn on Amazon
- BCreate a CPU usage alarm. Select the CPU utilization metric for the DB instance. Create an
- CUse the Amazon RDS query editor to get the process ID of the query that is causing the database
- DUse the SELECT INTO OUTFILE S3 statement to query data from the database. Save the data
How the community answered
(25 responses)- A72% (18)
- B8% (2)
- C16% (4)
- D4% (1)
Explanation
Performance Insights is the purpose-built AWS tool for automatically detecting and diagnosing database performance issues - it visualizes database load, surfaces top SQL queries, and shows wait events like locking/row-level contention in a continuous, automated way, directly solving the checkout timeout problem.
Option B is wrong because a CPU utilization alarm only tells you the CPU is high - it cannot identify why (e.g., lock contention vs. a bad query), and lock waits don't necessarily spike CPU at all, making it the wrong metric for this scenario.
Option C is wrong because manually querying the RDS process list via the query editor is a reactive, one-time action - it does not automatically detect or diagnose issues, which is a key requirement.
Option D is wrong because SELECT INTO OUTFILE S3 is a data export command, not a monitoring or diagnostics tool - it has no relevance to detecting performance bottlenecks.
Memory tip: Think of Performance Insights as a "performance X-ray" - whenever an exam question asks for automatic detection + diagnosis of database slowdowns (locks, waits, slow queries), Performance Insights is almost always the answer. If the question says "manually investigate," think RDS process list or CloudWatch Logs instead.
Topics
Community Discussion
No community discussion yet for this question.