A team wants to restore an RDS database to its exact state as of a specific timestamp 40 minutes ago, before a bad deployment script ran. The database has automated backups enabled with a 7-day retention period. What should they do?
- Restore the most recent daily snapshot and manually replay the last 40 minutes of transactions
- Reboot the DB instance with the "restore" option enabled
- Use the point-in-time recovery feature to restore to the desired timestamp, which creates a new DB instance
- Enable Multi-AZ and promote the standby, which reverts to the last snapshot
Why C? And why not the others?
Correct answer: C. Use the point-in-time recovery feature to restore to the desired timestamp, which creates a new DB instance
RDS automated backups combine daily snapshots with continuously archived transaction logs, and as long as a timestamp falls within the retention window, point-in-time recovery can replay those logs up to the exact second requested; the result is always delivered as a new DB instance, since RDS never overwrites an existing instance in place. The option describing manually replaying transactions after restoring a snapshot is wrong because that duplicates work RDS already automates through point-in-time recovery and risks human error in reconstructing the exact state. The option describing a reboot with a restore flag is wrong because rebooting an RDS instance only restarts the database engine process; there is no such restore option on a reboot action. The option describing promoting a Multi-AZ standby is wrong because the standby is a continuously synchronized live replica of the current primary, not a historical snapshot, so promoting it would preserve the bad deployment's changes rather than undo them.
Source: AWS RDS documentation: backing up and restoring an RDS DB instance (point-in-time recovery)