Exams / SAP-C03 / Study guide / Choosing and scaling databases (Aurora, DynamoDB, global databases)
Choosing and scaling databases (Aurora, DynamoDB, global databases): SAP-C03 study notes and practice questions
What to know about Choosing and scaling databases (Aurora, DynamoDB, global databases) for the SAP-C03 exam, from the Architecture Design and Implementation Built for the Cloud domain (25% of the exam guide), then 1 free question to test it. Part of the SAP-C03 study guide.
SAP-C03 gives you a workload’s queries, data shape, growth and recovery targets and asks for the database and the replication design that meet them with the least operational effort.
Choosing by access pattern
Need
Choose
Relational, joins, transactions, existing SQL app
RDS (engine compatibility) or Aurora (higher throughput, up to 15 low-lag replicas, fast failover, storage auto-growth)
Key-value or known access patterns at any scale, single-digit millisecond latency
DynamoDB
Analytics over large data sets
Redshift
Documents with MongoDB compatibility
DocumentDB
Highly connected data (fraud rings, recommendations)
Neptune
Cassandra workloads
Keyspaces
Time series (metrics, telemetry)
Timestream
Durable in-memory primary database
MemoryDB
Variable or unpredictable relational load
Aurora Serverless v2
High availability within a Region
RDS Multi-AZ DB instance: synchronous standby, not readable, automatic failover.
RDS Multi-AZ DB cluster: a writer and two readable standbys with faster failover.
Read replicas (RDS and Aurora) scale reads; RDS replicas are asynchronous and can be promoted.
Aurora keeps six copies of data across three AZs; a replica is promoted on failure. RDS Proxy pools connections and shortens failover impact.
Across Regions
Option
Behavior
Aurora Global Database
Storage-level replication to up to several secondary Regions, typically under a second of lag; switchover (planned, no data loss) or failover (unplanned); write forwarding lets secondaries send writes to the primary
RDS cross-Region read replica
Asynchronous replica you can promote
DynamoDB global tables, MREC
Multi-active writes in any Region, asynchronous replication, last writer wins
DynamoDB global tables, MRSC
Strong consistency across Regions and zero RPO; exactly three Regions (or two replicas plus a witness); no transactions or TTL
How to choose
Scenario wording
Choose
“Read-heavy relational app, reads slowing the writer”
Read replicas or Aurora replicas
“Low RPO and RTO in another Region for a relational database”
Aurora Global Database
“Users in several Regions write locally, eventual consistency OK”
DynamoDB global tables (MREC)
“Multi-Region writes, every read must see the latest write, RPO zero”
DynamoDB global tables (MRSC)
“Thousands of Lambda connections exhaust the database”
RDS Proxy
“Spiky relational workload, idle at night”
Aurora Serverless v2
Common traps
Multi-AZ to scale reads; a Multi-AZ DB instance standby serves no traffic.
Read replicas as the HA answer when automatic failover is required.
DynamoDB for ad hoc joins and reporting; design access patterns first or export to analytics.
Expecting MREC global tables to give strongly consistent reads across Regions.
Cross-Region read replicas when the RPO needs Aurora Global Database’s speed.
A car maker runs a dealer inventory system with dealers in North America, Europe and Asia-Pacific. Each dealer updates its own stock records, and those updates must finish in under 20 milliseconds in the dealer's Region, without a cross-Region round trip.
Every Region must be able to read the other Regions' stock records within about a second. If a Region fails, the other two must keep accepting updates for their own dealers. The team does not want to manage database replication software itself.
Which solution meets these requirements?
Choose one answer.
AA. Use an Amazon Aurora Global Database with its primary cluster in North America and read-only secondary clusters in the other Regions. Dealers in other Regions send writes through the secondary clusters.
BB. Create an Amazon RDS for MySQL instance with Multi-AZ in North America, and add cross-Region read replicas in Europe and Asia-Pacific that serve dealer reads.
CC. Deploy self-managed MySQL on EC2 instances in each Region and configure bidirectional replication between them, with the team running the replication software and failover scripts.
DD. Create an Amazon DynamoDB global table that replicates across the three Regions, with each dealer's items written in its local Region. Each Region keeps accepting writes if another Region fails.
Show the answer and explanation
Answer: D
A. Wrong: Writes from the secondary Regions are forwarded to the primary cluster, which adds a cross-Region round trip and misses the 20-millisecond requirement. A failed primary also stops writes until a failover is done.
B. Wrong: Cross-Region read replicas accept no writes, so dealers in Europe and Asia-Pacific would send updates to North America. That breaks the local-write requirement.
C. Wrong: Bidirectional replication can accept local writes, but the team would run and tune the replication and failover itself. That is the operational work the team wants to avoid.
D. Right: Correct. Global tables accept writes in every replica Region and replicate changes between them without the team managing replication, and dealer-specific items avoid most conflicting updates. A failed Region does not stop writes in the other two.
Explanation
DynamoDB global tables accept local writes in every Region and replicate them without operator effort. An Aurora global secondary forwards writes across Regions, read replicas accept no writes, and self-managed bidirectional replication adds operating work.
Every Region accepts writes for its own dealers and keeps working if another Region fails.
Want more on Choosing and scaling databases (Aurora, DynamoDB, global databases)? The 5 full-length practice sets have 5 more Choosing and scaling databases (Aurora, DynamoDB, global databases) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Choosing and scaling databases (Aurora, DynamoDB, global databases)