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.

• ✓

  Enable automated backups with a retention period that covers the recovery window.

  Why this is correct

  AWS RDS automated backups are foundational for Point-in-Time Recovery (PITR), capturing daily snapshots and continuously archiving transaction logs. A sufficient retention period is crucial, as it dictates how far back in time a database can be restored. If the corruption occurred outside the defined retention window, the specific recovery point before the incident would be unavailable, rendering PITR ineffective for that event.

• ✓

  Perform a point-in-time restore to a new database instance.

  Why this is correct

  Performing a Point-in-Time Restore (PITR) to a new Amazon RDS instance is the most reliable method to recover from data corruption. This process creates a new database instance reflecting the state of the original database at a precise timestamp before the corruption occurred. Restoring to a new instance is a critical best practice, as it preserves the corrupted production database for forensic analysis while allowing the restored, validated data to be promoted to production.

• ✗

  Convert the database to a single-AZ deployment for faster restores.

  Why it's wrong here

  Converting an RDS instance to a single-AZ deployment offers no benefit for recovering from data corruption and actively reduces database availability. While it might slightly reduce operational costs, it eliminates the high availability and automatic failover capabilities provided by Multi-AZ deployments. This change does not alter the underlying mechanism of Point-in-Time Recovery, which relies on automated backups and transaction logs, making it irrelevant for data integrity restoration.

• ✗

  Delete the corrupted rows manually and continue without restoring.

  Why it's wrong here

  Manually deleting corrupted rows is an extremely risky and unreliable approach for recovering from data corruption in a production environment. This method is highly prone to human error, potentially missing related data, orphaned records, or application-level inconsistencies that a full restore would resolve. A manual cleanup fails to guarantee a return to a known-good state, which is the primary objective when recovering from data integrity issues.

• ✗

  Use a read replica as the only recovery source for all deletions.

  Why it's wrong here

  An Amazon RDS read replica is primarily designed for read scaling and offloading read traffic from the primary database, not for point-in-time data recovery from corruption. While a read replica maintains a copy of the data, it replicates changes from the primary instance, including corruption, making it an unsuitable source for restoring to a clean state. It cannot provide the granular, precise timestamp recovery capabilities that automated backups and Point-in-Time Restore offer for data integrity issues.

Go deeper

Related to this question