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.

• ✗

  Move the session storage to an instance store volume.

  Why it's wrong here

  Instance store volumes are physically attached to the host and provide only temporary, block-level storage. Data on an instance store is ephemeral: it is lost when the instance is stopped, terminated, or experiences a host failure, so it cannot reliably persist session state across Auto Scaling lifecycle events. Additionally, each EC2 instance has its own local instance store, meaning sessions would not be shared across the fleet, breaking the stateless design required for elastic scaling.

• ✗

  Enable sticky sessions on the Application Load Balancer.

  Why it's wrong here

  Enabling sticky sessions (also called session affinity) on an Application Load Balancer only causes the ALB to route requests from a given client to the same target instance for a configured duration. While this reduces session conflicts, it does not make the session durable: if that instance becomes unhealthy, is replaced during a scale-in event, or otherwise terminates, the session data stored in its local memory is permanently lost. Sticky sessions can also lead to uneven load distribution and are not a substitute for a centralized session store.

• ✗

  Increase the size of the Auto Scaling group to handle peak traffic.

  Why it's wrong here

  Increasing the size of the Auto Scaling group merely adds more EC2 instances to handle elevated traffic levels. This does nothing to address where session state is stored: each instance retains only its own local session data, so if a user's session is bound to a particular instance and that instance is scaled in or fails, the session is lost regardless of how many other healthy instances remain. The root problem is the lack of a shared, external session repository, not insufficient compute capacity.

• ✓

  Configure an ElastiCache Redis cluster to store session state externally.

  Why this is correct

  Configuring an ElastiCache Redis cluster to store session state externally solves the persistence problem by creating a centralized, in-memory data store that every EC2 instance can read from and write to. Because sessions live outside any single instance, any instance in the Auto Scaling group can service any request, making the application effectively stateless from the instance perspective. Redis offers sub-millisecond latency, supports replication and backup/restore for durability, and integrates cleanly with common session-management libraries, so instance terminations or scaling events no longer disrupt active user sessions.

Go deeper

Related to this question