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.

• ✗

  Create a read replica in the same AWS Region.

  Why it's wrong here

  A read replica in the same AWS Region replicates data asynchronously and is designed primarily to offload read traffic from the primary instance, not to provide failover or disaster recovery. If the entire Region becomes unavailable, the replica in that same Region is also affected, leaving no cross-Region recovery capability. Moreover, it does not support automatic promotion to become a new primary, so it cannot meet a strict RPO requirement or survive a Regional outage.

• ✓

  Enable Multi-AZ deployment for the RDS instance.

  Why this is correct

  Enabling Multi-AZ deployment for the RDS instance creates a synchronous standby in a different Availability Zone, guaranteeing zero data loss (RPO=0) because transactions are committed on both the primary and standby before a write is acknowledged. Automatic failover is triggered by Amazon RDS within 60–120 seconds, providing high availability within a Region and protecting against AZ failures, database instance failures, and storage failures. This is the most appropriate choice when the specified RPO is below 5 seconds and the disaster recovery scope is limited to Availability Zone outages, as it eliminates asynchronous replication lag entirely.

• ✓

  Create a cross-Region read replica in another AWS Region.

  Why this is correct

  Creating a cross-Region read replica in another AWS Region uses asynchronous replication to maintain a warm standby copy of the database in a geographically separate location, with an RPO typically measured in seconds. The replica can be promoted to a standalone primary database during a Regional outage, making this a valid disaster recovery strategy that provides resilience beyond a single Region. While the asynchronous nature introduces a small replication lag—usually a few seconds—it still offers a very low RPO and can be acceptable if the application tolerates limited data loss in a disaster scenario.

• ✗

  Enable automated backups with a retention period of 35 days.

  Why it's wrong here

  Automated backups with a retention period of 35 days rely on transaction logs that are shipped approximately every 5 minutes, resulting in a maximum RPO of 5 minutes—far above the sub-5-second requirement in this scenario. Although backups enable point-in-time recovery, restoring requires creating a new DB instance from a backup snapshot, which introduces a significant RTO and does not provide automatic failover. Thus, automated backups are a complementary backup mechanism but cannot satisfy the low RPO needed for immediate failover.

• ✗

  Take manual snapshots every hour.

  Why it's wrong here

  Taking manual snapshots every hour captures the database state at an hourly interval, meaning the RPO is up to 60 minutes because all transactions after the last snapshot would be lost. The restore process from a manual snapshot is also time-consuming, often taking tens of minutes or more, resulting in a high RTO that is unsuitable for disaster recovery with a low RPO. This approach is operationally expensive and does not offer automatic failover, so it cannot meet the stringent recovery objectives required here.

Go deeper

Related to this question