SAA-C03 Design Resilient Architectures 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 snapshot restore and attach the restored instance, then manually copy only the affected rows back into the current database.

  Why it's wrong here

  A snapshot restore captures the database state at the time the snapshot was taken, which could be significantly earlier than 10:00 UTC, causing more data loss than a targeted point-in-time recovery. After restoring the snapshot to a new or existing instance, you would need to manually identify and copy only the affected rows, a process that is error-prone, non-atomic, and risks introducing data inconsistencies or missing dependent records. This approach also requires application downtime or complex reconfiguration to attach the restored instance, making it slower and less reliable than PITR, which uses continuous transaction logs to restore to a precise second.

• ✓

  Use point-in-time recovery to restore the database to a timestamp just before 10:00 UTC, then swap application connectivity to the recovered instance.

  Why this is correct

  Point-in-time recovery (PITR) for Amazon RDS uses automated backups and transaction logs to restore the database to any second within the backup retention period, allowing you to target a timestamp just before 10:00 UTC when the corruption occurred. This minimizes data loss to only the changes made in the seconds immediately preceding the incident, far more precise than a full snapshot. After restoring to a new RDS instance, you swap the application connection string (or use Route 53/RDS Proxy) to point to the recovered instance, enabling a clean recovery with minimal disruption and no manual row copying.

• ✗

  Rely on automated backups to roll forward automatically until the data becomes correct.

  Why it's wrong here

  Automated backups in Amazon RDS operate as a background process that copies data and transaction logs for recovery purposes, but they do not roll the live database forward or apply changes to correct current data. The corrupted table remains corrupted because there is no automatic rollback or correction mechanism; backups only provide the source for a restore operation, which must be manually initiated. Relying on backups to self-heal the database misunderstands their role—they are a safety net for restoration, not a real-time data repair service, and the damage from the 10:00 UTC incident will persist indefinitely unless an explicit restore is performed.

• ✗

  Disable automated backups going forward to prevent future corruption, then reindex the corrupted table.

  Why it's wrong here

  Disabling automated backups does not undo the data corruption that occurred at 10:00 UTC; it only stops future recovery points from being created, actually worsening your ability to recover from this incident. Reindexing the corrupted table, while helpful for performance or index corruption, will not restore overwritten data values because the physical rows have already been changed and the original values are lost. This action also leaves the database live and exposed to further issues, and it removes the very mechanism needed to perform a point-in-time recovery, making it a harmful and ineffective response to the problem.

Go deeper

Related to this question