SOA-C02 · Question #569
Users of a company's internal web application recently experienced application performance issues for a brief period. The application includes frontend web servers that run in an Amazon Elastic…
The correct answer is A. Increase the size of the DB instance. Monitor the performance during the next scheduled run of. Increasing the DB instance size (vertical scaling) directly addresses the root cause - insufficient compute capacity on the single writer - by giving it more CPU and memory to handle the weekly report load without impacting application users. Option B is tempting but…
Question
Users of a company's internal web application recently experienced application performance issues for a brief period. The application includes frontend web servers that run in an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. The application also includes a backend Amazon Aurora PostgreSQL DB cluster that includes one DB instance. A SysOps administrator determines that the source of the performance issues was high utilization of the DB cluster. The single writer instance experienced more than 90% utilization for 11 minutes. The cause of the high utilization was an automated report that is scheduled to run one time each week. What should the SysOps administrator do to ensure that users do not experience performance issues each week when the report runs?
Options
- AIncrease the size of the DB instance. Monitor the performance during the next scheduled run of
- BAdd a reader instance. Change the database connection string of the report application to use the
- CAdd another writer instance. Change the database connection string of the report application to
- DConfigure auto scaling for the DB cluster. Set the minimum capacity units, maximum capacity
How the community answered
(27 responses)- A74% (20)
- B4% (1)
- C15% (4)
- D7% (2)
Explanation
Increasing the DB instance size (vertical scaling) directly addresses the root cause - insufficient compute capacity on the single writer - by giving it more CPU and memory to handle the weekly report load without impacting application users. Option B is tempting but misleading: while Aurora reader instances can offload read traffic, the question describes a single writer handling both application and report load; a reader replica is best suited when read traffic is the ongoing bottleneck, not a predictable once-weekly spike that a larger instance can absorb. Option C is incorrect because standard Amazon Aurora (single-master) does not support adding a second writer instance - only one writer exists at a time in a provisioned Aurora cluster. Option D is incorrect because "minimum/maximum capacity units" describes Aurora Serverless v2 auto scaling, which applies to serverless configurations, not a provisioned DB cluster; additionally, auto scaling has a ramp-up delay that would not respond fast enough to an 11-minute spike.
Memory tip: Think "single writer = single point of scale - scale UP (bigger instance) for CPU spikes, scale OUT (add reader) for sustained read volume." When a question mentions a provisioned Aurora cluster with one instance hitting CPU limits from a scheduled batch job, sizing up is the simplest, most direct fix.
Topics
Community Discussion
No community discussion yet for this question.