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.

• ✗

  Single-AZ DB deployment and rely on manual snapshot restore during failures.

  Why it's wrong here

  A Single-AZ deployment runs the primary database instance in only one Availability Zone, with no standby replica to take over if that AZ becomes unavailable. While automated snapshots are stored durably in S3, restoring them to a new instance requires manual action and typically takes tens of minutes or longer, meaning there is no automatic failover and recovery depends on operator intervention. This approach yields a high RTO and does not meet the requirement for automatic failover to a different AZ.

• ✓

  Multi-AZ deployment with an automatically managed standby in a different Availability Zone and automatic failover.

  Why this is correct

  In a Multi-AZ deployment, Amazon RDS or Aurora provisions a physically separate standby instance in a different Availability Zone and synchronously replicates data from the primary to that standby. When the primary fails or the AZ is degraded, RDS automatically initiates failover to the standby, which becomes the new primary; because the DNS endpoint remains unchanged, the application continues to work without manual intervention. This provides both the required cross-AZ redundancy and automatic failover, meeting the availability requirement directly.

• ✗

  Enable read replicas only, and promote a replica manually when the primary fails.

  Why it's wrong here

  Read replicas are designed to offload read traffic and use asynchronous replication, so they can lag the primary and may be missing recent transactions at failover time. To use one as a primary, an operator must manually stop replication and promote the replica, which is an explicit, time-consuming action that may also require updating application connection strings. Because the promotion is not automatic and data may be stale, this approach fails the automatic failover requirement and is not a substitute for Multi-AZ.

• ✗

  Enable point-in-time recovery (PITR) without configuring any Multi-AZ standby.

  Why it's wrong here

  Point-in-time recovery (PITR) enables restoring a database to any second within the backup retention period using automated backups and transaction logs, but the restore process creates a new DB instance and is always initiated manually by an administrator. PITR is designed to undo logical mistakes such as accidental deletes, not to maintain continuous availability; there is no standby instance in another AZ, and no automatic failover occurs when the primary fails. Therefore, PITR alone cannot satisfy the requirement.

Go deeper

Related to this question