A clinic needs its patient-records database as it stood about 20 minutes ago. Automated backups are enabled, and the only hand-made copy is last night's manual snapshot. Which restore reaches that time?
Select an answer to reveal the explanation.
Short Explanation
Last night's photograph cannot show you the lobby as it looked 20 minutes ago. You use point-in-time restore, which automated backups make available, and you land on a new instance at that time. Failing over the standby or editing rows by hand does not rewind the database to that moment.
Full Explanation
Automated backups keep the transaction history RDS uses for point-in-time restore, so a new instance can be created as of a time inside that window, including about 20 minutes ago. A manual snapshot restores only the moment the snapshot was taken, which here is last night, not 20 minutes ago. Multi-AZ failover promotes a current standby. It does not rewind committed data to an earlier minute, because the standby has been applying the same writes. Exporting tables and editing rows is a manual data fix, not a database restore, and it cannot reliably rebuild every change from that time. A point-in-time restore also rebuilds the surrounding database, which hand edits to an export do not reconstruct, and it leaves the current clinic database untouched until you cut over. Caveat: the chosen time has to fall between the earliest and latest restorable times, and the restore creates a new instance rather than rolling the current one backward. Operational check: restore to a new identifier, compare a known row with production, and cut over only after that row matches the earlier time.