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 Multi-AZ RDS instance and attach it to the existing EC2 instance.

  Why it's wrong here

  A Multi-AZ RDS deployment creates a synchronously replicated standby in a different Availability Zone to protect the database layer, but it does nothing for the single EC2 instance running the web application. If that EC2 instance fails or its Availability Zone experiences an outage, the application becomes unavailable even though the database remains accessible. Furthermore, for a stateful application, any session state stored locally on the EC2 host is still lost, leaving users logged out and in-flight data unrecoverable.

• ✗

  Add a second EC2 instance in the same Availability Zone and use a Network Load Balancer.

  Why it's wrong here

  Placing both EC2 instances in the same Availability Zone fails to improve fault tolerance against an AZ-wide outage, which remains a single point of failure. For a stateful application, a Network Load Balancer distributing traffic without externalising session state would break user sessions upon instance failure, as the new instance lacks the required state. This option is tempting as it provides instance-level resilience and load distribution, making it suitable for stateless applications requiring high performance within a single Availability Zone.

• ✗

  Use an Auto Scaling group with a launch configuration that stores session data on instance store.

  Why it's wrong here

  An Auto Scaling group with a launch configuration that places session data on instance store does not provide durable or shared session state. Instance store volumes are ephemeral, physically attached to the host, and are wiped on instance stop or termination, so anytime the ASG replaces an unhealthy instance, all sessions on that instance are lost. Additionally, because instance store is not shared across instances, a load-balanced fleet would have no way to access a user's session if the request lands on a different instance, making this configuration unsuitable for any stateful workload.

• ✓

  Place instances in an Auto Scaling group across two Availability Zones, use an Application Load Balancer, and store session state in ElastiCache.

  Why this is correct

  Placing the application instances in an Auto Scaling group across two Availability Zones ensures that both an instance failure and a full AZ failure can be absorbed automatically, as the ASG launches a replacement instance in the remaining healthy AZ. An Application Load Balancer distributes traffic and performs health checks, routing requests only to healthy instances. Storing session state in ElastiCache (or a similar external store) decouples sessions from compute instances, so any instance can handle any request without losing user data; if an instance terminates, a new instance can access the same session state from ElastiCache. This combination provides both high availability and fault tolerance for a stateful web application.

Go deeper

Related to this question