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.

• ✗

  Reboot the DB instance and rely on the corrupted data being overwritten by storage-level changes.

  Why it's wrong here

  Rebooting the DB instance merely restarts the database process and re-applies the redo log from the last checkpoint; it does not roll back committed transactions or undo logical corruption such as corrupted rows introduced by an application release. Storage-level changes are not made by a reboot, and any corrupted data remains physically present in the database files. To recover to a clean state, you must restore from a backup taken before the corruption occurred, not simply restart the instance.

• ✓

  Perform a point-in-time restore to a new DB instance using a timestamp before the corruption (for example, a time within 10:00–10:30 UTC).

  Why this is correct

  With automated backups enabled, RDS supports point-in-time recovery (PITR) within the retention window. Restoring to a timestamp before the corruption creates a consistent copy from that moment. The team can validate the restored DB and then cut over application traffic, reducing risk to the currently running workload.

• ✗

  Restore only the most recent automated backup snapshot, even if it is after the corruption timestamp.

  Why it's wrong here

  The most recent automated backup snapshot captures the database at exactly the time the snapshot was taken, which could be after the corruption was committed. If that snapshot contains the corrupted rows, restoring it will not satisfy the requirement to return to the 10:00–10:30 UTC state. Automated backups on RDS include transaction logs that enable point-in-time recovery to a specific timestamp, allowing you to reconstruct the database to a moment before the corruption, whereas a snapshot alone cannot provide that granularity.

• ✗

  Create a read replica of the current DB instance and overwrite the corrupted table using SELECT queries from the replica.

  Why it's wrong here

  A read replica continuously applies asynchronous replication changes from the source DB instance, so it will contain the same corrupted data that was committed after 10:30 UTC. Querying from a read replica to overwrite the corrupted table would simply copy the already-corrupted rows from the replica back into the primary, or at best fail to recover the original pre-corruption values. A read replica is not a backup artifact for point-in-time recovery; it cannot be used to roll back logical corruption that already propagated through replication.

Go deeper

Related to this question