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.

• ✓

  Perform a point-in-time restore (PITR) to a timestamp just before 10:30 UTC and create a restored DB instance/cluster.

  Why this is correct

  PITR uses automated backups to restore the database to a specific point in time. Selecting a timestamp just before the corruption (for example, slightly before 10:30 UTC) restores the affected data state as it existed before the bad release.

• ✗

  Change the VPC route tables so the database restarts in a clean state.

  Why it's wrong here

  Changing VPC route tables alters the network path that traffic uses, but it has no effect on the database engine or the committed data stored in the RDS volume. A database restart, whether caused by network changes or manually, replays the redo log and performs crash recovery, but it does not roll back committed transactions or remove rows that were incorrectly updated at 10:30. This option would do nothing to restore the lost or corrupted data and could even cause availability issues by blackholing traffic to the database.

• ✗

  Relaunch the same DB instance in the same Availability Zone and rely on caching to revert the changes.

  Why it's wrong here

  Simply relaunching or rebooting the existing DB instance in the same Availability Zone does not revert any committed changes because all successful writes are already durable in the underlying storage system. The RDS page cache and buffer pools accelerate reads and writes but never replace the authoritative persisted version of a row; corrupted values that were committed at 10:30 remain on disk and are read back after any restart. This approach only recovers from transient engine failures, not from application-level logical corruption.

• ✗

  Enable a DLQ on the database to store invalid SQL statements until the system is fixed.

  Why it's wrong here

  Dead-letter queues are a messaging pattern used by asynchronous services such as SQS, where a consumer can set aside malformed events for later inspection; relational databases do not route SQL statements through a queuing layer that could hold 'bad' writes for later deletion. RDS executes and commits SQL statements transactionally, and once committed, they become part of the database log and data files. Enabling a DLQ would not allow you to 'undo' the 10:30 update; it would be a concept mismatch and provide no recovery mechanism in RDS.

Go deeper

Related to this question