SAA-C03 Design Resilient Architectures Practice Question
A team accidentally updates critical rows in an Amazon RDS for PostgreSQL database. Automated backups are enabled. They need to recover the data to the exact state as of 90 minutes ago.
They also cannot risk interrupting the current production database instance while investigators validate the restored data.
Which recovery strategy best meets these constraints?
⚠ Common exam trap
It's easy for candidates to confuse point-in-time recovery with snapshot restoration or assume that read replicas can be used for time-based rollbacks, but only PITR provides the exact time-targeted restore without affecting the production instance.
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 recovery (PITR) to restore to a new RDS DB instance as of 90 minutes ago, then validate and cut over after approval.
Point-in-time recovery (PITR) for Amazon RDS allows you to restore a DB instance to any second within the backup retention period, using automated backups and transaction logs. By restoring to a new RDS instance as of 90 minutes ago, you create an isolated copy for validation without affecting the production database. This meets both the recovery point objective (RPO) of 90 minutes and the constraint of no interruption to the current production instance.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use point-in-time recovery (PITR) to restore to a new RDS DB instance as of 90 minutes ago, then validate and cut over after approval.
Why this is correct
Amazon RDS point-in-time recovery (PITR) restores a new DB instance to any fraction of a second within the backup retention window by replaying transaction logs from the last automated snapshot. Launching a separate instance preserves the production database untouched, allowing you to validate the restored data at 90 minutes ago before promoting it and updating the application connection string. After approval, you can cut over by renaming the instances or changing the DNS endpoint, minimizing downtime and risk.
- ✗
Restore a manual snapshot and overwrite the existing production DB instance so the data matches exactly 90 minutes ago.
Why it's wrong here
Restoring a manual snapshot overwrites the entire database with the snapshot's capture time, which is only accurate to 90 minutes ago if a snapshot happened to be taken at that exact moment—something you cannot normally guarantee. Moreover, you cannot directly overwrite an existing RDS instance in place; you would have to restore to a new instance and then redirect traffic, and the restore process itself would interrupt production availability. Manual snapshots are periodic and do not provide the granular point-in-time precision needed to recover the precise state from 90 minutes ago.
When this WOULD be correct
If the requirement was to restore the entire production database to a specific past state with minimal downtime and no need for separate validation, and if overwriting the existing instance was acceptable, then restoring a manual snapshot would be appropriate.
- ✗
Wait for the next automated backup window and then restart the current DB instance to roll back changes automatically.
Why it's wrong here
Automated backup windows simply trigger snapshots and transaction log captures; they have no ability to roll back logical changes when the instance is restarted. A restart only reboots the DB engine, leaving committed UPDATE statements intact in the data files, so the erroneous rows would remain unchanged. Even after the next backup, restoring to that later backup would capture the corrupted state, not the pre-update state from 90 minutes ago. The only way to recover to the earlier timestamp is to use PITR to create a new instance from automated backups and logs.
When this WOULD be correct
If the question stated that the database needs to be restored to the state at the time of the last automated backup (e.g., 'recover to the most recent backup') and the team is willing to accept data loss from changes after that backup, then waiting for the next backup window and restarting could be a valid approach.
- ✗
Use cross-region read replicas to rewind changes and promote the replica to become the writer immediately.
Why it's wrong here
Read replicas replicate the current data stream; they do not provide a built-in mechanism to rewind to a historical point in time. Promoting a replica would not correct the data to the state from 90 minutes ago.
When this WOULD be correct
A company needs to minimize read latency for a global user base and wants to offload read traffic from the primary RDS instance. Cross-region read replicas can be promoted to become standalone databases for read-heavy workloads in different regions.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.
✓Use point-in-time recovery (PITR) to restore to a new RDS DB instance as of 90 minutes ago, then validate and cut over after approval.Correct answer▾
Why this is correct
Amazon RDS point-in-time recovery (PITR) restores a new DB instance to any fraction of a second within the backup retention window by replaying transaction logs from the last automated snapshot. Launching a separate instance preserves the production database untouched, allowing you to validate the restored data at 90 minutes ago before promoting it and updating the application connection string. After approval, you can cut over by renaming the instances or changing the DNS endpoint, minimizing downtime and risk.
✗Restore a manual snapshot and overwrite the existing production DB instance so the data matches exactly 90 minutes ago.Wrong answer — click to see why▾
Why this is wrong here
Restoring a manual snapshot and overwriting the production DB instance would cause downtime and data loss, as it replaces the current database entirely, violating the constraint of not interrupting production while validating.
★ When this WOULD be the correct answer
If the requirement was to restore the entire production database to a specific past state with minimal downtime and no need for separate validation, and if overwriting the existing instance was acceptable, then restoring a manual snapshot would be appropriate.
Why candidates choose this
Candidates may think manual snapshots are faster or more precise than PITR, or they overlook the need to avoid production interruption during validation.
✗Wait for the next automated backup window and then restart the current DB instance to roll back changes automatically.Wrong answer — click to see why▾
Why this is wrong here
Waiting for the next automated backup window does not allow recovery to a specific point 90 minutes ago; automated backups are typically taken once per day and do not support rollback to an arbitrary time.
★ When this WOULD be the correct answer
If the question stated that the database needs to be restored to the state at the time of the last automated backup (e.g., 'recover to the most recent backup') and the team is willing to accept data loss from changes after that backup, then waiting for the next backup window and restarting could be a valid approach.
Why candidates choose this
Candidates may mistakenly believe that automated backups enable point-in-time recovery without additional steps, or that restarting a DB instance automatically rolls back changes to a previous state.
✗Use cross-region read replicas to rewind changes and promote the replica to become the writer immediately.Wrong answer — click to see why▾
Why this is wrong here
Cross-region read replicas do not support rewinding changes; they replicate data asynchronously and cannot restore to a specific past point in time. Promoting a replica does not roll back the database to a previous state.
★ When this WOULD be the correct answer
A company needs to minimize read latency for a global user base and wants to offload read traffic from the primary RDS instance. Cross-region read replicas can be promoted to become standalone databases for read-heavy workloads in different regions.
Why candidates choose this
Candidates may confuse read replicas with point-in-time recovery capabilities, assuming replicas can be used to revert changes, or they overestimate the rollback functionality of replicas.
Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
About these practice questions
This SAA-C03 question is part of Courseiva's 935-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.