DBS-C01 · Question #55
The Development team recently executed a database script containing several data definition language (DDL) and data manipulation language (DML) statements on an Amazon Aurora MySQL DB cluster. The…
The correct answer is B. Perform a point-in-time recovery (PITR) of the DB cluster to a time before the release and copy. Explanation Option B is correct because Point-in-Time Recovery (PITR) creates a new DB cluster restored to a pre-release state, allowing the specialist to extract and copy only the affected data back into the production cluster - minimizing downtime and data loss while keeping…
Question
The Development team recently executed a database script containing several data definition language (DDL) and data manipulation language (DML) statements on an Amazon Aurora MySQL DB cluster. The release accidentally deleted thousands of rows from an important table and broke some application functionality. This was discovered 4 hours after the release. Upon investigation, a Database Specialist tracked the issue to a DELETE command in the script with an incorrect WHERE clause filtering the wrong set of rows. The Aurora DB cluster has Backtrack enabled with an 8-hour backtrack window. The Database Administrator also took a manual snapshot of the DB cluster before the release started. The database needs to be returned to the correct state as quickly as possible to resume full application functionality. Data loss must be minimal. How can the Database Specialist accomplish this?
Options
- AQuickly rewind the DB cluster to a point in time before the release using Backtrack.
- BPerform a point-in-time recovery (PITR) of the DB cluster to a time before the release and copy
- CRestore the DB cluster using the manual backup snapshot created before the release and change
- DCreate a clone of the DB cluster with Backtrack enabled. Rewind the cloned cluster to a point in
How the community answered
(25 responses)- A12% (3)
- B68% (17)
- C4% (1)
- D16% (4)
Explanation
Explanation
Option B is correct because Point-in-Time Recovery (PITR) creates a new DB cluster restored to a pre-release state, allowing the specialist to extract and copy only the affected data back into the production cluster - minimizing downtime and data loss while keeping the current cluster running during the recovery process.
Why the distractors are wrong:
- Option A (Backtrack directly) is tempting since Backtrack is enabled, but rewinding the production cluster affects all users and causes application downtime during the rewind; it also affects the entire database, not just the deleted rows.
- Option C (Manual snapshot restore) would work but is slower than PITR, as restoring a full snapshot takes longer than a targeted point-in-time recovery, making it less ideal when speed is the priority.
- Option D (Clone + Backtrack) adds unnecessary complexity - cloning then rewinding is an extra step compared to simply using PITR to recover the specific data needed.
Memory Tip: Think "PITR = Precise and Non-Disruptive" - whenever you need to recover specific data without taking down production, PITR lets you spin up a parallel cluster and surgically copy back only what was lost, combining speed with minimal data loss.
Topics
Community Discussion
No community discussion yet for this question.