Free SAA-C03 practice scenarios: Multi-AZ RDS

Availability versus scaling, and the line the exam draws between them — synchronous standby, failover and cross-Region DR. Six scenarios, SAA-C03, 2026 edition.

Try 6 free Multi-AZ RDS scenarios in the exam's own style — every answer explained, no sign-up.

Straight to the 6 free questions ↓

Multi-AZ is the resilience feature the SAA-C03 returns to most, and its scenarios almost always turn on one line: availability versus scaling. Get that line right and the distractors — usually a read replica or a resize offered where availability belongs — fall away.

Standby is not a read node

A Multi-AZ standby is a passive failover target. It is not readable, it accepts no traffic, and it exists solely to take over if the primary’s Availability Zone fails. So when a scenario asks you to offload reads onto the standby, the answer is no — add read replicas, which are separate, readable instances built for exactly that. The exam plants this because “there’s a whole second instance sitting there, why not read from it?” feels reasonable. It is the wrong copy.

What failover is — and is not

Multi-AZ fails over on availability events: an AZ outage, a primary instance or storage failure, or a maintenance operation like patching. It does not fail over because the database is busy. Sustained read load is a performance problem, and the answer to a performance problem lives in replicas or caching, never in Multi-AZ. Watching for “failure” versus “load” in the stem tells you which family of answers to reach for.

Why it protects committed data

Replication to the standby is synchronous — a transaction commits only once it is written to both instances — so a failover loses essentially no committed data. That near-zero RPO is why Multi-AZ is the right call for finance and other data-sensitive workloads. Contrast it with a read replica’s asynchronous replication, which can lag and is therefore about scaling and DR, not zero-loss availability.

The Region line

Multi-AZ lives entirely inside one Region — it survives an AZ loss, not a Region loss. When the requirement is to bring the database up in a second Region, the answer is a cross-Region read replica you promote during a disaster. Adding AZs or resizing keeps you inside the Region that failed. Single-Region availability is Multi-AZ; multi-Region DR is a cross-Region replica.

Two managed helpers

Two services round out the common scenarios. RDS Proxy pools connections and holds them steady through a failover — the answer when a serverless or spiky app suffers connection storms and slow recovery. And Aurora changes the shape of the question: its Replicas are readable and are failover targets at the same time, sharing distributed storage, so Aurora delivers read scaling and automatic failover from the same instances instead of a separate idle standby.

How to use the six scenarios below

Answer each one before opening the explanation, and when you miss, find the requirement word that decided it — “automatic”, “readable”, “least data loss”, “second Region”. Every explanation names that constraint and takes the distractors apart. The recurring trap is a mechanism that genuinely works but answers scaling when the question asked for availability, or the reverse. For the domain overview, see Design Resilient Architectures.

A side-by-side contrast of two RDS features. On the left, Multi-AZ for availability: a primary instance replicating synchronously to a standby in another Availability Zone, the standby not readable, failover automatic behind the same DNS endpoint, and the recovery point objective near zero. On the right, read replicas for scaling and disaster recovery: asynchronous replication, the replicas readable, promotion a manual step that creates a new endpoint, and replicas deployable across Regions.

6 free SAA-C03 practice questions

Answers and explanations — no email wall

SAA-C03 Question 1 of 6

A team runs RDS with Multi-AZ enabled and, seeing read latency climb, proposes directing some read queries to the standby instance to share the load. What should a solutions architect tell them?

Answer: A — The Multi-AZ standby cannot serve reads; add read replicas to scale read traffic.

A Multi-AZ standby is a passive failover target — it is not readable and accepts no traffic until a failover promotes it. Read scaling is the job of read replicas, which are separate, readable instances. Why not the others: there is no standby endpoint to query and no 'Multi-AZ read routing' toggle, because the standby serving reads would compromise the synchronous, availability-only role it plays. Resizing it changes nothing about that role. Availability is Multi-AZ; read scaling is read replicas — the exam keeps these two jobs strictly apart.

SAA-C03 Question 2 of 6

Which event does NOT trigger an automatic Multi-AZ failover to the standby?

Answer: A — Sustained high read query volume on the primary.

Multi-AZ fails over on availability events — an AZ outage, a primary instance or storage failure, or a maintenance operation like patching that briefly takes the primary down — but a heavy read workload is a performance problem, not a failure, so it triggers nothing. Why not the others each name a genuine availability event that does cause failover. The trap is assuming failover is a load-balancing mechanism: it is not. When the stem describes load rather than failure, the answer lives in replicas or caching, not in Multi-AZ.

SAA-C03 Question 3 of 6

A finance application on RDS must lose as little committed data as possible if the primary's Availability Zone fails. Why does Multi-AZ suit this requirement?

Answer: A — Replication to the standby is synchronous, so the recovery point objective is near zero.

Multi-AZ replicates synchronously: a transaction is acknowledged only once it is written to both the primary and the standby, so a failover loses essentially no committed data — a near-zero RPO, exactly what a finance workload needs. Why not the others: the replication is synchronous, not asynchronous; snapshots are point-in-time backups taken on a schedule, not a per-second data feed; and the standby is kept strongly consistent through synchronous writes, not 'eventually consistent'. Synchronous replication is precisely why Multi-AZ protects committed data.

SAA-C03 Question 4 of 6

A company needs its RDS database to survive the loss of an entire AWS Region, with the ability to bring the database up in a second Region. Multi-AZ alone does not meet this. What should a solutions architect add?

Answer: A — A cross-Region read replica that can be promoted in the second Region.

Multi-AZ protects against the loss of an Availability Zone, but everything stays in one Region. Surviving a Region loss needs a cross-Region read replica, which you promote to a standalone primary in the disaster Region. Why not the others: a Multi-AZ standby is always within the same Region, so it cannot span Regions. Adding Availability Zones still leaves you inside the failed Region. A larger instance improves performance, not geographic resilience. Single-Region availability is Multi-AZ; multi-Region disaster recovery is a cross-Region read replica.

SAA-C03 Question 5 of 6

A serverless application opens and closes many short-lived database connections, and during Multi-AZ failovers it suffers connection storms and slow recovery. Which managed service best addresses this?

Answer: A — Amazon RDS Proxy, which pools connections and speeds up failover handling.

RDS Proxy sits between the application and the database, pooling and reusing connections and holding them steady through a failover — it reduces failover-perceived downtime and absorbs the connection churn of serverless callers. Why not the others: a bigger instance raises the connection ceiling but does not manage churn or smooth failover. An Application Load Balancer is for HTTP/TCP application traffic, not database connection pooling. CloudFront caches web content and has no role in database connections. Connection pooling plus faster failover for spiky callers is RDS Proxy.

SAA-C03 Question 6 of 6

An Amazon Aurora cluster must both scale read traffic and fail over automatically if the writer's Availability Zone fails, with minimal wasted capacity. How does Aurora achieve both?

Answer: A — Aurora Replicas serve read traffic and double as automatic failover targets for the writer.

Aurora Replicas are readable and are also failover targets: they share the cluster's distributed storage, so one can be promoted to writer automatically while all of them serve reads — read scaling and high availability from the same instances, with no idle standby. Why not the others: Aurora does not need a separate passive standby the way RDS Multi-AZ does — that is a key difference between them. It provides both capabilities together, not one or the other, and failover is a fast promotion over shared storage, not a snapshot restore. Aurora folds availability and read scaling into the same 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 6 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

Multi-AZ or read replica — what is the exam really testing?

The distinction between availability and scaling. Multi-AZ is synchronous, automatic and not readable — it keeps the database running through an AZ failure. Read replicas are asynchronous and readable, promoted manually, and can span Regions — they scale reads and support disaster recovery. Match the requirement word (automatic, readable, cross-Region) to the right one.

Does Aurora work the same way as RDS Multi-AZ?

Not quite. Aurora Replicas are readable and act as automatic failover targets at once, sharing distributed storage, so Aurora gives you read scaling and high availability from the same instances rather than a separate passive standby. It is a common exam distinction.

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 reasoning attached instead.

What is the one-line takeaway?

Multi-AZ for surviving an AZ failure automatically with near-zero data loss; read replicas for scaling reads and cross-Region DR; RDS Proxy for connection pooling and faster failover; Aurora Replicas do reads and failover together.

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.