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 session storage to Amazon ElastiCache for Redis with replication.

  Why this is correct

  ElastiCache for Redis with replication provides a highly available, in-memory session store that is accessible from all EC2 instances. By using Multi-AZ replication, Redis automatically fails over to a replica if the primary node fails, so session data remains available. You can also enable append-only file persistence to guard against data loss, making it a robust and widely used pattern for storing session state in distributed applications.

• ✗

  Use EBS Multi-Attach to attach the volume to multiple instances.

  Why it's wrong here

  EBS Multi-Attach allows a single io1/io2 volume to be attached to multiple instances within the same Availability Zone, but it does not provide cooperative locking or distributed coordination for concurrent session data writes. Session data requires frequent read/write access from any instance, and Multi-Attach volumes are not suitable for read/write workloads without a clustered file system. Additionally, the volume is tied to one AZ, so it does not offer high availability across AZs or failure recovery if the volume becomes unavailable.

• ✗

  Take frequent EBS snapshots of the volume.

  Why it's wrong here

  EBS snapshots capture point-in-time states of the volume, so frequent snapshots can only give you last-known-good session data, not real-time data. If an instance fails, you would lose whatever session state was written after the most recent snapshot, and restoring requires creating a new volume and attaching it to an instance, causing downtime. Snapshots also store data in S3 and are not designed for frequent, in-memory session access; they serve as backups, not as a live, shared session store.

• ✗

  Use a larger EC2 instance type with more memory.

  Why it's wrong here

  Using a larger EC2 instance simply increases the available memory capacity on a single host, but the session data is still stored on the instance's local memory, which is ephemeral. If the instance crashes, is stopped, or is terminated, all session state is irrecoverably lost. This approach also does not enable sharing session data across multiple instances, so it fails to address the underlying scalability and availability requirements of a distributed application.

Go deeper

Related to this question