Database questions test whether you can separate two goals the exam deliberately blurs: availability (survive a failure) and scalability (handle more read/write load). Choosing the wrong feature for the wrong goal is the classic trap.

Every real architecture has a database, so this domain touches resilience, performance, and cost simultaneously.

Amazon RDS runs managed relational engines. Two features look similar but solve different problems. Multi-AZ maintains a synchronous standby in another AZ for high availability — on failure it fails over automatically; the standby does not serve reads. Read replicas are asynchronous copies used to scale read traffic (and can span regions), but they are not automatic failover targets.

Amazon Aurora is AWS's cloud-native relational engine (MySQL/PostgreSQL-compatible) with a shared storage layer replicated 6 ways across 3 AZs, faster failover, and up to 15 low-latency read replicas.

DynamoDB is a fully managed, serverless NoSQL key-value/document store with single-digit-millisecond latency at any scale. ElastiCache (Redis/Memcached) is an in-memory cache that fronts a database to absorb hot reads and reduce latency.

A relational app experiences read-heavy reporting queries that slow down the primary. The exam asks how to scale reads without hurting writes.

The answer is read replicas — offload the reporting queries to replicas so the primary handles writes. If instead the requirement were "survive an AZ failure with automatic failover," the answer would be Multi-AZ, which does not help with read scaling.

Now a different need: a shopping-cart service requiring millisecond latency, massive scale, and a flexible schema. That points to DynamoDB, not RDS. And if repeated identical queries are hammering the database, put ElastiCache in front to serve them from memory.

Databases live inside your VPC and are protected by security groups — the app tier's SG is typically the DB SG's source. Encryption at rest (KMS) and in transit ties into the security domain.

Cost-wise, DynamoDB's on-demand vs provisioned capacity and RDS Reserved Instances are common optimization levers. And caching with ElastiCache is both a performance and a cost play, since it reduces expensive database load.