An Aurora MySQL-Compatible cluster serves a reporting portal whose read traffic climbs sharply each weekday morning and falls away by mid-afternoon. The writer instance stays lightly loaded, but read latency rises during the peak, and the same popular dashboard queries run thousands of times an hour against rows that change only a few times a day. The team must absorb the morning read surge and cut repeated read pressure on the cluster while adding as little ongoing tuning as possible. Which two actions, taken together, meet this requirement? (Select TWO.)
- AEnable Aurora Replica Auto Scaling so reader instances are added and removed automatically against a target metric, with reads served from the cluster reader endpoint. Correct
- BConvert the cluster to a Multi-AZ deployment so a standby in a second Availability Zone serves the additional morning read traffic alongside the writer.
- CIncrease the writer instance class to a larger size so it has the capacity to handle the extra morning read queries without any replicas.
- DPlace an Amazon ElastiCache cache in front of the cluster and serve the popular dashboard query results from it so repeated reads are answered without touching Aurora. Correct
- ESwitch the cluster volume to Provisioned IOPS storage so the morning read queries complete faster under the higher disk throughput.
Why A is correct: Replica Auto Scaling grows and shrinks the reader fleet on its own to track the daily read surge, spreading read traffic with minimal tuning.
Why B is wrong: Multi-AZ delivers in-Region failover availability and the standby does not serve normal read traffic, so it does nothing to scale reads.
Why C is wrong: Scaling the writer up is manual vertical sizing for steady load, wasteful overnight, and it leaves repeated reads hitting the database directly.
Why D is correct: Caching the slow-changing hot query results offloads the bulk of repeated reads from the cluster, directly cutting read pressure during the peak.
Why E is wrong: Aurora manages its own distributed storage and does not use Provisioned IOPS volumes, so this setting does not exist and cannot scale reads.