RDS read replicas: SAA-C03 read-scaling scenarios

The exam's read-scaling feature, taken apart: asynchronous replication and lag, cross-Region replicas, promotion, and the Aurora reader endpoint. Seven scenarios, SAA-C03, 2026 edition.

Try 7 free RDS read replica scenarios in the exam's own style — every answer explained, no sign-up.

Straight to the 7 free questions ↓

Read replicas are the SAA-C03’s answer whenever a scenario says scale reads or read throughput. The exam tests whether you can separate that job — performance — from the availability job that Multi-AZ owns, and whether you understand the trade-off replicas make to get their scale. The diagram above captures the shape: one primary takes every write and replicates asynchronously to several readers that soak up the read traffic, with one replica sitting in a second Region for local latency. Reads scale across the replicas; writes still go to the primary.

Asynchronous by design

A read replica is fed by asynchronous replication. A write commits on the primary first and reaches the replicas afterwards, which is exactly why replicas can serve reads without slowing the primary’s write path. The cost is replica lag: for a short window a replica may not yet hold the newest row, so its reads are eventually consistent. That is expected behaviour, not a fault — and it is the detail behind many distractors. When a scenario demands that a read reflect the latest committed write, that read belongs on the primary.

How far replicas scale

RDS for MySQL, MariaDB and PostgreSQL allow up to 15 read replicas per source instance. That is a lot of read fan-out, but it is a ceiling, and the exam likes candidates who know it exists: when a workload needs to scale beyond it, the design moves toward Aurora or chained replicas. Knowing the number is finite is what makes “migrate to Aurora at scale” a defensible answer rather than a guess.

Reads where the users are

Replicas can cross Regions. A cross-Region read replica places a readable copy near a distant user base, so their reads are local and low-latency while writes still travel to the single primary. The same mechanism doubles as a migration tool: replicate into the target Region, let the replica catch up, then promote it. Promotion breaks the replication link and turns the replica into an independent, writable primary — the deliberate cutover step, and the reason a replica is not writable until you take it.

The Aurora shape

Aurora reshapes the question. Its replicas share the cluster’s distributed storage, and the reader endpoint load-balances read connections across all available Aurora Replicas automatically. Pair it with Aurora Replica Auto Scaling and the replica fleet grows and shrinks with demand, with no per-replica endpoints hardcoded in the application. When a stem describes swinging read load and asks for a hands-off answer, the reader endpoint plus Auto Scaling is the pattern being tested.

The line the exam draws

The recurring trap sets read replicas against Multi-AZ. They are not alternatives. Multi-AZ keeps a synchronous, non-readable standby and fails over automatically behind the same endpoint — that is availability. Read replicas add readable capacity and are promoted manually to a new endpoint — that is performance. Map the requirement word: “automatic failover” is Multi-AZ, “scale reads” is a read replica. For the availability side of that contrast, see Multi-AZ RDS scenarios; for the wider domain, see Design High-Performing Architectures.

Using the seven scenarios

Answer each one before opening the explanation, and when you miss, find the requirement word that decided it — “scale reads”, “latest write”, “second Region”, “automatically”. Every explanation names that constraint and takes the plausible-but-wrong options apart.

A read-scaling topology for RDS. A single primary instance in one Region takes all writes and replicates asynchronously to several read replicas that serve read traffic. One replica sits in a second Region for low-latency local reads. A caption notes that reads scale across the replicas while every write still goes to the primary.

7 free SAA-C03 practice questions

Answers and explanations — no email wall

SAA-C03 Question 1 of 7

A product-catalog service on RDS for PostgreSQL is CPU-bound: thousands of concurrent shoppers issue SELECT queries against the primary while a small stream of writes updates inventory. The team needs to raise read throughput without re-architecting the data model. What should a solutions architect recommend?

Answer: A — Add one or more read replicas and route catalog SELECT traffic to them.

Read replicas are purpose-built to scale reads: each is a separate, readable instance fed asynchronously from the primary, so directing SELECT-heavy catalog traffic to replicas relieves the primary's CPU without touching the schema. Why not the others: a Multi-AZ standby is a passive failover target and is not readable, so it cannot take shopper reads and there is no standby read endpoint to enable; raising IOPS helps storage-bound workloads but this bottleneck is CPU on the read path, which more read instances address directly. Read scaling is the replicas' job, not Multi-AZ's.

SAA-C03 Question 2 of 7

After adding read replicas to an RDS database, a reporting query run against a replica occasionally returns a row a user just wrote against the primary as missing. The behaviour is intermittent. What is the correct explanation to give the team?

Answer: A — Replication to read replicas is asynchronous, so replicas can lag the primary and reads are eventually consistent.

RDS read replicas use asynchronous replication: a write commits on the primary and propagates to replicas afterwards, so under replica lag a very recent write may not yet be visible on a replica — reads there are eventually consistent, which is expected, not a fault. Why not the others: nothing here indicates corruption, so rebuilding is unwarranted; replica replication is asynchronous, not synchronous, so this is not a network error; and no failover occurred — the write is safely on the primary and simply has not reached the replica yet. When strong consistency is required for a given read, send it to the primary.

SAA-C03 Question 3 of 7

A team wants to know the ceiling on how far a single RDS for MySQL primary can be scaled out with native read replicas before a different approach is needed. What is the correct guidance?

Answer: A — A single RDS for MySQL instance supports up to 15 read replicas; beyond that, consider Aurora or replicas of replicas.

RDS for MySQL, MariaDB and PostgreSQL support up to 15 read replicas per source instance, so read fan-out is generous but bounded — when a workload needs to scale past that, Aurora (up to 15 low-latency replicas over shared storage) or chained replicas are the usual next step. Why not the others: the count is capped, not unlimited; it is far more than one; and read replicas are a standard RDS feature, not exclusive to Aurora. Knowing there is a finite ceiling is what steers the design toward Aurora at scale.

SAA-C03 Question 4 of 7

A database lives in eu-west-1, but a fast-growing user base in Australia complains that read latency for their dashboards is high. Writes remain modest and centralised. Which approach gives Australian users low-latency reads with the least change to the write path?

Answer: A — Create a cross-Region read replica in ap-southeast-2 and serve local reads from it.

A cross-Region read replica places a readable copy near the users: Australian dashboards read locally from the ap-southeast-2 replica while writes still flow to the single primary in Europe — low read latency with the write path untouched. Why not the others: relocating the primary just moves the latency problem onto European writers; Multi-AZ operates within one Region and does nothing for cross-continent read latency; and CloudFront caches HTTP content, not live relational query results, so it is the wrong layer for dynamic dashboard reads. Cross-Region replicas are the read-locality answer.

SAA-C03 Question 5 of 7

A company is migrating an application from eu-central-1 to us-east-1 and wants to cut over to a full read/write database in the new Region with minimal downtime. They have been replicating via a cross-Region read replica in us-east-1. What is the final cutover step?

Answer: A — Promote the cross-Region read replica to a standalone primary, which breaks replication and makes it writable.

Promoting a read replica severs its replication link with the source and turns it into an independent, writable primary — exactly the low-downtime cutover for a Region migration, since the replica is already caught up before promotion. Why not the others: a read replica rejects writes while it is still replicating, so you cannot simply point writes at it; a snapshot-restore adds a slower copy step when promotion is instant and in place; and Multi-AZ adds a standby for availability but never makes a read replica writable. Promotion is the deliberate step that ends the replica's read-only life.

SAA-C03 Question 6 of 7

An Aurora cluster serves a read-heavy analytics workload whose volume swings sharply through the day. The team wants reads spread across replicas automatically and replica capacity to grow and shrink with demand, without hardcoding replica endpoints. Which Aurora features meet this?

Answer: A — Send reads to the cluster's reader endpoint and enable Aurora Replica Auto Scaling.

The Aurora reader endpoint load-balances connections across all available Aurora Replicas, and Aurora Replica Auto Scaling adds or removes replicas in response to load — together they spread reads and track demand with no endpoint changes in the application. Why not the others: the cluster (writer) endpoint always points at the primary, so it does not distribute reads; hand-maintaining per-replica instance endpoints breaks whenever Auto Scaling changes the fleet; and Aurora does not use a passive RDS-style standby as a read target. The reader endpoint plus Auto Scaling is the managed read-scaling pattern.

SAA-C03 Question 7 of 7

In a design review, two RDS features are proposed for the same database: read replicas and Multi-AZ. A stakeholder asks which one delivers automatic failover if the primary's Availability Zone fails, and which one scales read throughput. What is the correct framing?

Answer: A — Multi-AZ provides automatic failover for availability; read replicas scale read throughput for performance — they solve different problems.

These features answer different requirements: Multi-AZ keeps a synchronous standby that is promoted automatically behind the same endpoint when an AZ fails — availability — while read replicas are asynchronous, readable instances that add read capacity — performance. Why not the others: read replicas are not automatic failover targets (promotion is a manual step that creates a new endpoint) and Multi-AZ does not scale reads because its standby is not readable; only one feature covers each requirement, so they are complementary, not interchangeable. Match 'automatic failover' to Multi-AZ and 'scale reads' to replicas.

That is exactly how every question in the course works — answer, explanation, why-not. The real set continues in the practice player: 10 free questions, no sign-up.

Continue with the 10 free questions →

Those 7 questions were the start.

The exam does not test whether you recognise a term — it tests whether you can rule out three plausible answers under time pressure. That is what the explanations above are for, and there are 780 more questions built exactly like them.

Collecting questions yourself

Scattered across forums, of unknown age
Answer keys without reasoning
No idea which domain you are weak in

Practising with a system

780 questions in 12 full tests, SAA-C03 (2026)
Every option explained — including the wrong ones
Readiness per exam domain, and drills for your weakest

Start free — 10 questions

Straight into the player. No account, no email.

Frequently asked questions

Read replica or Multi-AZ — which does the exam want?

It depends on the requirement word. If the scenario asks to scale reads or add read throughput, the answer is read replicas. If it asks for automatic failover when an Availability Zone fails, the answer is Multi-AZ. Read replicas are asynchronous, readable and promoted manually; a Multi-AZ standby is synchronous, not readable and promoted automatically.

Is replication to a read replica synchronous?

No. RDS read replicas replicate asynchronously, so a replica can lag the primary and its reads are eventually consistent — a very recent write may not appear immediately. When a read must reflect the latest committed data, send it to the primary. Only the Multi-AZ standby uses synchronous replication, and it is not readable.

Are these real exam questions?

No. They are original scenarios written for this page in the exam's style and difficulty. Reproducing real exam items violates the AWS certification agreement and can cost a candidate their certification — ours come with the full reasoning attached instead.

Updated for SAA-C03 (July 2026). The sample questions above are our own work in the style of the exam — not real exam items. The exam itself is set and marked by the certification body.