DBS-C01 · Question #71
An ecommerce company has tasked a Database Specialist with creating a reporting dashboard that visualizes critical business metrics that will be pulled from the core production database running on…
The correct answer is D. Add an automatic scaling policy to the DB cluster to add Aurora Replicas to the cluster based on. Aurora Replica Auto Scaling for Reporting Dashboards Adding an automatic scaling policy to add Aurora Replicas addresses all requirements: replicas handle read traffic from the reporting dashboard without impacting write performance on the primary instance, data is available…
Question
An ecommerce company has tasked a Database Specialist with creating a reporting dashboard that visualizes critical business metrics that will be pulled from the core production database running on Amazon Aurora. Data that is read by the dashboard should be available within 100 milliseconds of an update. The Database Specialist needs to review the current configuration of the Aurora DB cluster and develop a cost-effective solution. The solution needs to accommodate the unpredictable read workload from the reporting dashboard without any impact on the write availability and performance of the DB cluster. Which solution meets these requirements?
Options
- ATurn on the serverless option in the DB cluster so it can automatically scale based on demand.
- BProvision a clone of the existing DB cluster for the new Application team.
- CCreate a separate DB cluster for the new workload, refresh from the source DB cluster, and set
- DAdd an automatic scaling policy to the DB cluster to add Aurora Replicas to the cluster based on
How the community answered
(37 responses)- A3% (1)
- B11% (4)
- C5% (2)
- D81% (30)
Explanation
Aurora Replica Auto Scaling for Reporting Dashboards
Adding an automatic scaling policy to add Aurora Replicas addresses all requirements: replicas handle read traffic from the reporting dashboard without impacting write performance on the primary instance, data is available within 100 milliseconds because replicas are kept in sync with the primary via shared storage (typically under 100ms lag), and auto scaling ensures cost-effectiveness by only provisioning replicas when the unpredictable read workload demands it.
Why the distractors fail:
- Option A (Serverless): Aurora Serverless is designed to scale compute for intermittent or unpredictable overall workloads, but it doesn't specifically isolate read workloads from writes, and it doesn't add read replicas to distribute read traffic.
- Option B (DB Cluster Clone): Cloning creates a separate, independent cluster - data changes on the source won't be reflected within 100ms, violating the freshness requirement.
- Option C (Separate DB Cluster with Refresh): A periodic refresh approach would introduce significant data lag, making it impossible to meet the 100-millisecond data availability requirement.
Memory Tip: Think "Reads = Replicas, Scale = Auto" - whenever a question involves isolating unpredictable read workloads from writes in Aurora while keeping costs dynamic, Aurora Replicas with Auto Scaling is your go-to pattern.
Topics
Community Discussion
No community discussion yet for this question.