SOA-C02 Reliability and Business Continuity 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.

• ✗

  Enable automated backups with a retention period of 35 days.

  Why it's wrong here

  Automated backups in RDS for PostgreSQL provide point-in-time recovery (PITR) by continuously shipping transaction logs to S3, but they do not create a synchronous standby. If the primary DB instance fails, you must manually restore from the latest backup or use the AWS Console/API to initiate recovery, which typically takes tens of minutes to hours depending on database size. The 35-day retention period only extends the backup window; it has no effect on failover behavior or availability. Therefore, automated backups address durability and disaster recovery, not high availability or automatic failover.

• ✗

  Create a read replica in another Availability Zone.

  Why it's wrong here

  A read replica in another Availability Zone is an asynchronous copy of the source DB instance that is used to offload read traffic or support analytics. It is not a Multi-AZ standby, so AWS does not automatically promote it when the primary fails; you would need to perform a manual promotion, which converts the replica into a standalone instance and requires updating your application's connection string. During the promotion process, there is downtime and replication lag may result in data loss. Read replicas are designed for read scaling and cross-region disaster recovery, not for automated high availability.

• ✓

  Enable Multi-AZ deployment on the DB instance.

  Why this is correct

  Enabling Multi-AZ on an Amazon RDS for PostgreSQL DB instance provisions a synchronous standby replica in a different Availability Zone and automatically maintains a synchronous physical replication stream. In the event of an infrastructure failure, an availability zone outage, or a database patching event, Amazon RDS automatically performs a failover to the standby, typically completing within 60–120 seconds and preserving your data because all commits are synchronous. The DNS endpoint remains unchanged, so application connections are transparently redirected without manual intervention. This configuration meets the requirement for automatic failover and high availability.

• ✗

  Schedule manual snapshots to be taken every hour and restore from the latest snapshot when needed.

  Why it's wrong here

  Manual snapshots are full backups stored in S3, but taking them hourly does not create a standby or provide automatic failover. Restoring from a snapshot involves creating a brand-new DB instance from the stored data, which is time-consuming and may take hours for large databases, and any transactions committed after the last snapshot are lost. The restore operation is a manual, deliberate step that requires you to detect the failure, initiate the restore, and update connection endpoints. This approach is suitable for disaster recovery with a low recovery point objective, but it explicitly does not provide the automatic, low-downtime failover that Multi-AZ offers.

Go deeper

Related to this question