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 another Availability Zone and promote it on failure.

  Why it's wrong here

  Creating a Read Replica in another AZ and promoting it on failure is not a valid high-availability strategy because read replicas use asynchronous replication, meaning they can lag behind the primary and miss recent transactions. Promotion is a manual process that requires you to detect the failure and issue the promote operation, which introduces operational delay and potential data loss if the replica is not fully caught up. Additionally, a promoted replica does not automatically become the new primary with the same endpoint; you must reconfigure applications to point to the new instance.

• ✓

  Enable Multi-AZ deployment on the DB instance.

  Why this is correct

  Enabling Multi-AZ deployment creates a synchronous standby replica in a different Availability Zone with automatic failover, ensuring that if the primary instance fails, Amazon RDS automatically switches to the standby with minimal downtime. The synchronous replication means the standby is always up to date with the primary, so there is no data loss. This configuration provides high availability with a single database endpoint, so applications can maintain connectivity during failover.

• ✗

  Take hourly snapshots and automate restoration in another AZ.

  Why it's wrong here

  Taking hourly snapshots and automating restoration in another AZ cannot provide the availability that Multi-AZ offers because snapshots are point-in-time backups taken at intervals, so you risk losing up to an hour of committed transactions. Restoring a snapshot from Amazon S3 involves creating a new DB instance and loading the data, which can take a significant amount of time and requires you to update the application connection string to the new endpoint. This approach is a disaster recovery mechanism with high RTO and RPO, not a real-time failover solution.

• ✗

  Use Amazon RDS Proxy to manage connection failover.

  Why it's wrong here

  Amazon RDS Proxy is a connection-pooling service that sits between your application and the database to improve connection efficiency and resilience; it does not replicate data or provide a standby database instance. While RDS Proxy can minimize connection disruption during a failover event, it does not handle the underlying database failover or high availability. The actual failover still relies on the DB instance's own configuration, such as Multi-AZ, so using RDS Proxy alone would leave the database vulnerable to an AZ outage.

Go deeper

Related to this question

Same concept, more angles

1 more way this is tested on SOA-C02

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.