SAA-C03 Design Resilient Architectures Practice Question
A developer accidentally deletes important rows in an RDS database. The mistake is discovered 45 minutes later. The database has automated backups enabled with a retention period of 7 days. What is the best way to restore the database to a point just before the deletion?
⚠ Common exam trap
It's easy for candidates to assume manual snapshots or read replicas can be used for granular point-in-time recovery, but only automated backups with transaction logs enable restoring to a specific second within the retention period.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use point-in-time restore (PITR) to restore the database to a specific timestamp before the deletion, based on automated backups.
Point-in-time restore (PITR) allows you to restore an RDS DB instance to any second within the automated backup retention period (here, 7 days). Since the deletion occurred 45 minutes ago, you can specify a timestamp just before the deletion, and RDS will replay the transaction logs to bring the database to that exact state. This is the most precise and efficient recovery method for accidental data modifications.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Restore the latest manual snapshot and then run SQL scripts to revert the deletion.
Why it's wrong here
Manual snapshots may not be close to the deletion time, which can lead to restoring data that is too far back. Reversion scripts are also error-prone and may be difficult to apply safely without additional data consistency checks.
- ✓
Use point-in-time restore (PITR) to restore the database to a specific timestamp before the deletion, based on automated backups.
Why this is correct
With automated backups enabled, RDS supports PITR within the retention window. PITR lets you restore to any second within that window, so you can select a timestamp just before the destructive deletion occurred. This avoids restoring a potentially stale snapshot and eliminates the need for risky manual compensating scripts.
- ✗
Promote an existing read replica to be the primary and then copy the missing rows from logs.
Why it's wrong here
If the replica is an active read replica, it generally replicates changes from the source, including the delete operation. Promoting the replica would typically preserve the deleted state, not recover the missing rows. Also, relying on “logs” is not a standard RDS row-level recovery mechanism.
- ✗
Recreate the instance using the most recent CloudWatch metric alarm snapshot of storage metrics.
Why it's wrong here
CloudWatch is a monitoring service, not a backup or storage service; it collects performance and operational metrics such as CPU utilization, free memory, and read/write IOPS, but it never captures row-level database content. Its alarms evaluate threshold breaches and can trigger actions like Auto Scaling or SNS notifications, but they do not take or store snapshots of any kind. Therefore, recreating an RDS instance from a 'CloudWatch metric alarm snapshot' is technically impossible because no database data is contained in those metrics, and this approach cannot recover the deleted rows.
Go deeper
Related to this question
About these practice questions
One of 935 original SAA-C03 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.