A team needs the ability to restore a DynamoDB table to its exact state as of any specific second within roughly the last five weeks, in case a bug silently corrupts data and isn't noticed for several days. The feature must be turned on explicitly per table before it is needed. Which feature should they enable, and how does a restore work?
- DynamoDB Streams, which retains a rolling window of item-level changes that can be replayed in place to reconstruct the table's state as of any past second
- Point-in-time recovery (PITR), which continuously backs up the table for a fixed 35-day window and restores the chosen second's state into a new table, since restores can't be applied in place
- On-demand backups taken manually every hour, restored in place over the existing table to roll it back to the desired hour
- Global tables, since replica tables in other regions retain older versions of items that can be queried directly for any past point in time
Why B? And why not the others?
Correct answer: B. Point-in-time recovery (PITR), which continuously backs up the table for a fixed 35-day window and restores the chosen second's state into a new table, since restores can't be applied in place
Point-in-time recovery must be explicitly enabled per table, after which DynamoDB continuously backs up the table for a fixed 35-day retention window and lets the team choose any second within that window to restore, always creating a new table since PITR restores are never applied in place over the live table. The option describing DynamoDB Streams is wrong because Streams retains only a short rolling window of change records, on the order of 24 hours, intended for near-real-time processing such as triggering a Lambda function, not for reconstructing state weeks in the past. The option describing manual hourly on-demand backups is wrong because it would only allow restoring to the top of an hour rather than any specific second, and, like PITR, an on-demand backup restore also produces a new table rather than rolling back the existing one in place. The option describing global tables is wrong because replica tables in other regions hold the current, replicated state of items for availability and low-latency access, not a retained history of past item versions that can be queried for an arbitrary earlier point in time.
Source: AWS DynamoDB documentation: Point-in-time recovery (PITR) for DynamoDB