SAA-C03 Practice Question 85: Aurora Backtrack Undo Mistake
AWS Certified Solutions Architect – Associate (SAA-C03) · Test 9 · question 5 of 10
An engineer runs a DELETE without a WHERE clause against an Aurora MySQL cluster and removes several million rows. The cluster was created with the Backtrack feature enabled and a 24-hour target backtrack window. The business wants the data back as fast as possible, and the application already connects through the cluster's writer endpoint, which must keep working afterwards without a configuration change.
What should the DBA do?
Show answer and explanation
Answer:
Backtracking rewinds an Aurora MySQL cluster to a time you specify without restoring from a backup, and AWS gives "a DELETE without a WHERE clause" as its example of the mistake it undoes. The advantage over restore is exactly what this question is optimising for: restoring to a point in time launches a new cluster from backup data and can take hours, whereas backtracking needs no new cluster and rewinds in minutes. Because the same cluster is rewound, the existing writer endpoint keeps working and no application change is needed. The one caveat, already satisfied here, is that Backtrack must have been enabled when the cluster was created.
Option B misunderstands Aurora's architecture. Replicas do not hold their own copy of the data (every instance in the cluster reads the same shared cluster volume), so the delete is already reflected on the replica and promoting it recovers nothing.
Option C is slow and changes the endpoint. Restoring a snapshot builds a whole new cluster, and the recovery point is whenever the snapshot was taken, so writes since then are lost as well.
Option D does recover the correct data and is the right answer for an Aurora PostgreSQL cluster or one without Backtrack enabled. Here it takes hours rather than minutes, produces a second cluster, and adds a dump-and-reload step, so it loses on every stated constraint.
Reference: Backtracking an Aurora DB cluster