Free SAA-C03 practice scenarios: RDS, Aurora & DynamoDB

Relational or NoSQL, and which engine within each — the database choice the exam tests through access patterns. Seven scenarios, SAA-C03, 2026 edition.

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

Straight to the 7 free questions ↓

Database selection is a signature SAA-C03 pattern, and it resolves in two steps: relational or NoSQL, then which engine or feature within that family. The stem’s access pattern decides both — never a vague claim that one “scales better”.

Step one: relational or NoSQL

Relational (RDS / Aurora) — structured data, joins across normalized tables, multi-table ACID transactions. If the stem describes joins or transactions, stop here.
NoSQL (DynamoDB) — key-value access, flexible schema, single-digit-millisecond latency at essentially unlimited scale. If the stem describes key lookups at scale, this is your family.

The exam’s favourite trap is offering DynamoDB “because NoSQL scales better” on a join-heavy workload. Scaling is not the deciding factor; the data model is.

Step two, relational: RDS, Aurora, or Aurora Serverless

RDS — the standard managed engines (MySQL, PostgreSQL, and others).
Aurora — MySQL/PostgreSQL-compatible with higher throughput, auto-growing distributed storage, and up to fifteen low-latency read replicas. The answer when a MySQL/Postgres app wants more performance without leaving SQL.
Aurora Serverless — capacity scales automatically for variable or intermittent relational workloads, so you stop paying for always-on capacity while idle.

And to scale reads on a relational database, add read replicas — not the Multi-AZ standby, which is not readable. That confusion is the single most tested relational trap.

Step two, NoSQL: DynamoDB and its accelerators

DynamoDB answers key-value at scale, and two features extend it:

DAX (DynamoDB Accelerator) — an in-memory cache giving microsecond reads for hot items.
Global tables — multi-Region, multi-active replication so users on every continent read and write locally.

Watch the wording: DynamoDB does not have “read replicas” — global tables are its multi-Region mechanism, and a “DynamoDB read replica” option is a distractor.

How to use the seven scenarios below

Answer each one before opening the explanation, and when you miss, name the access pattern that decided it — “joins and transactions”, “key-value at scale”, “MySQL-compatible with more throughput”, “variable load”, “microsecond reads”, “multi-Region active-active”. Every explanation states that pattern and dismantles the distractors, which are usually a real database answering a different one. For the domain overview, see Design High-Performing Architectures.

A decision view of AWS databases. Relational choices for structured data with joins and transactions: Amazon RDS for standard managed engines, Amazon Aurora for MySQL and PostgreSQL compatibility with higher throughput, distributed storage and up to fifteen read replicas, and Aurora Serverless for variable workloads that scale capacity automatically. The NoSQL choice for key-value access at any scale with single-digit-millisecond latency is Amazon DynamoDB, accelerated by DynamoDB Accelerator for microsecond reads and replicated by global tables for multi-Region active-active.

7 free SAA-C03 practice questions

Answers and explanations — no email wall

SAA-C03 Question 1 of 7

A relational workload runs intermittently: busy for a few hours, then idle for long stretches. The company wants to stop paying for always-on database capacity while keeping a relational engine. Which option fits best?

Answer: A — Amazon Aurora Serverless, which scales capacity automatically with demand.

Aurora Serverless scales relational database capacity up and down automatically with demand, so an intermittent workload does not pay for capacity while idle — matching 'relational engine, no always-on cost'. Why not the others: a large always-on RDS instance is exactly the always-on cost the requirement wants to avoid. DynamoDB is NoSQL, so it abandons the relational requirement. Self-managing the database on EC2 adds operational burden and still runs continuously. Variable relational workloads point to Aurora Serverless.

SAA-C03 Question 2 of 7

An application needs a key-value data store delivering single-digit-millisecond reads and writes at essentially unlimited scale, with a flexible schema. Which database should a solutions architect choose?

Answer: A — Amazon DynamoDB.

DynamoDB is a managed NoSQL key-value store built for single-digit-millisecond performance at any scale with a flexible schema — the requirement described almost word for word. Why not the others: RDS for PostgreSQL and Aurora MySQL are relational engines with fixed schemas and join-oriented access, not schemaless key-value stores that scale horizontally without limit. Redshift is a data warehouse for analytical queries, not low-latency operational lookups. Key-value at scale with millisecond latency is DynamoDB.

SAA-C03 Question 3 of 7

A globally used application must offer low-latency reads and writes to users on multiple continents, with each Region able to serve local writes. Which DynamoDB capability provides this?

Answer: A — DynamoDB global tables (multi-Region, multi-active replication).

DynamoDB global tables replicate a table across Regions with multi-active writes, so users on every continent read and write to a local copy with low latency. Why not the others: DynamoDB does not use 'read replicas' — global tables are the multi-Region mechanism, and naming a replica is the trap. An RDS cross-Region replica is relational and read-only until promoted, not multi-active. CloudFront caches content and cannot serve local database writes. Multi-Region active-active for DynamoDB is global tables.

SAA-C03 Question 4 of 7

A team runs a MySQL database on RDS and wants higher throughput, storage that grows automatically, and up to fifteen low-latency read replicas — while staying MySQL-compatible. What should they migrate to?

Answer: A — Amazon Aurora MySQL-Compatible Edition.

Aurora's MySQL-Compatible Edition delivers substantially higher throughput than standard MySQL, storage that auto-grows, and up to fifteen low-latency read replicas — all while remaining MySQL-compatible, so the migration is straightforward. Why not the others: DynamoDB is NoSQL and would abandon MySQL compatibility and SQL entirely. Self-managing MySQL on EC2 reintroduces the operational burden a managed service removes and does not deliver Aurora's architecture. Redshift is an analytics warehouse, not a transactional MySQL replacement. MySQL-compatible with more throughput is Aurora.

SAA-C03 Question 5 of 7

A read-heavy reporting feature is overloading the primary of an RDS relational database with SELECT queries. The company wants to scale read capacity without changing the relational model. What should a solutions architect recommend?

Answer: A — Add read replicas and direct read traffic to them.

Read replicas are readable copies that offload SELECT traffic from the primary, scaling reads while keeping the same relational database. Why not the others: Multi-AZ's standby is not readable — it is an availability feature, not a read-scaling one, and this is the most common confusion the exam tests. Migrating to DynamoDB changes the data model the requirement says to keep. More storage does not address read throughput. Scaling relational reads is read replicas.

SAA-C03 Question 6 of 7

A DynamoDB-backed application has read-heavy access to popular items and needs microsecond read latency to relieve pressure on the table. Which addition meets this?

Answer: A — DynamoDB Accelerator (DAX), an in-memory cache for DynamoDB.

DynamoDB Accelerator (DAX) is a purpose-built in-memory cache for DynamoDB that brings read latency down to microseconds and absorbs hot-item traffic — the native accelerator for this exact case. Why not the others: ElastiCache in front of RDS caches a relational database, not DynamoDB. Raising provisioned capacity increases throughput and cost but does not deliver microsecond caching. CloudFront caches web content at the edge and does not sit in front of a DynamoDB table. Microsecond caching for DynamoDB is DAX.

SAA-C03 Question 7 of 7

A new application stores highly relational data with complex joins across many normalized tables and needs ACID transactions across them. Which database category fits, and why not the alternative?

Answer: A — A relational database (RDS or Aurora), because it supports joins and multi-table ACID transactions.

Complex joins across normalized tables with ACID transactions is the defining relational workload, so RDS or Aurora is correct. Why not the others: DynamoDB is optimised for key-based access and does not perform relational joins across many tables — scaling well does not make it fit a join-heavy transactional model. S3 is object storage, not a transactional database. Redshift is a columnar analytics warehouse for large aggregate queries, not low-latency transactional joins. Relational joins and transactions mean RDS or Aurora.

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

How do I choose relational versus DynamoDB on the exam?

Read the access pattern. Joins across normalized tables and multi-table ACID transactions mean a relational engine — RDS or Aurora. Key-based access at massive scale with millisecond latency and a flexible schema means DynamoDB. 'Scales better' is never the deciding factor; the data model and access pattern are.

RDS or Aurora — when does Aurora win?

When the stem asks for MySQL or PostgreSQL compatibility plus higher throughput, auto-growing storage, up to fifteen low-latency replicas, or Serverless scaling for variable load. Aurora is the higher-performance managed relational option; RDS covers the standard engines.

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?

Joins and transactions → RDS/Aurora; key-value at scale → DynamoDB; variable relational load → Aurora Serverless; microsecond DynamoDB reads → DAX; multi-Region active-active → global tables.

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.