SAA-C03 Design Resilient Architectures Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Aurora Global Database

  Why this is correct

  Aurora Global Database is the correct choice because it uses storage-based replication to synchronize data across multiple AWS Regions with a typical latency of under one second. It supports up to five secondary Regions, and when a regional failure occurs, you can promote a secondary Region to primary in about a minute, giving you a very low RPO and RTO for fast disaster recovery. This managed feature also enables low-latency global reads and automatic failover, making it vastly superior to any snapshot-based approach.

• ✗

  A single-AZ Aurora cluster

  Why it's wrong here

  A single-AZ Aurora cluster operates entirely within one Availability Zone in a single Region, so it cannot protect against a Regional disaster. While Aurora's storage engine inherently replicates data six ways across three AZs for high availability within a Region, this does nothing to provide cross-Region failover or recovery. If the entire Region becomes unavailable, the cluster is unreachable and you would have to restore from backups, leading to a high RTO and no true DR capability.

• ✗

  An ElastiCache Redis replica

  Why it's wrong here

  An ElastiCache Redis replica is an in-memory key/value cache, not a durable relational database and not an Aurora DR mechanism. It does not natively integrate with Aurora's replication or failover, and any data written into the cache would be lost on restart, making it unsuitable as a recovery point. Using it to serve reads would require application-level cache warm-up and synchronization, and it cannot be promoted to become the source of truth for the Aurora database.

• ✗

  Manual snapshots copied monthly

  Why it's wrong here

  Manually copying Aurora snapshots to another Region once a month introduces a maximum RPO of 30 days, because any transactions committed after the snapshot are lost. Restoring a snapshot into a new Aurora cluster can also take tens of minutes or longer, resulting in a high RTO. This approach also requires operational effort to trigger and track copies, and it does not provide any automated failover or continuous replication, so it fails to meet the requirement for fast disaster recovery.

Go deeper

Related to this question