DOP-C02 Incident and Event Response 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 to a time just before the deletion.

  Why this is correct

  Point-in-Time Restore is the fastest AWS-native recovery method because RDS never leaves you without a timeline: it automatically captures daily snapshots and continuously records MySQL binary logs, so you can pick a timestamp just before the offending DDL/DML statement. RDS then creates a new DB instance by restoring the last automated snapshot before that moment and replaying transaction logs up to the exact second you specify, avoiding any manual log analysis. The restored instance reflects the database before the change, making this both the quickest and most reliable choice.

• ✗

  Use the RDS console to undo the last transaction.

  Why it's wrong here

  The RDS console provides no operation to 'undo' a committed transaction; MySQL's transaction semantics only allow an explicit ROLLBACK inside the session before COMMIT, and once a DML/DDL statement commits, the change is permanent from the database engine's perspective. The console offers backup, restore, and monitoring features, but no built-in rollback or transaction-rewind button. Reversing a committed transaction would require a backup-and-recover workflow, such as Point-in-Time Restore, not a console click.

• ✗

  Use the binary log to replay transactions before the deletion.

  Why it's wrong here

  Manually replaying binary logs is a valid recovery technique only if you have already enabled binlog export to Amazon S3, which is not enabled by default, and you know the precise binlog filename and position or GTID of the statement you need to exclude. You would then run mysqlbinlog and apply the logs on a separate RDS instance, manually filtering out the deletion — a slow, error-prone process compared to RDS's native PITR. Because the question asks for the fastest AWS-native approach, diving into manual binlog replay is the wrong answer.

• ✗

  Create a manual snapshot of the current instance and restore it.

  Why it's wrong here

  A manual snapshot captures the current, post-deletion state of the instance; restoring it would simply recreate the missing data and give you no ability to rewind to a point before the deletion. Additionally, creating a manual snapshot takes time, restoring from it takes time, and the result is a copy of the present, not a historical point in time. Manual snapshots are designed for baselines and cloning, not for rolling back to a specific past moment, so this option is neither fast nor useful for this scenario.

Go deeper

Related to this question