SOA-C02 Reliability and Business Continuity Practice Question
A company runs a web application on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The application stores session state in memory on each instance. The SysOps administrator wants to make the application highly available across multiple Availability Zones without losing session data when instances are terminated or replaced. The solution must minimize application changes. Which approach should the administrator take?
⚠ Common exam trap
Test-takers frequently choose sticky sessions (Option A) because they seem to solve session affinity without code changes, but they fail to realize that sticky sessions do not persist session data across instance terminations, which is the core requirement for high availability without data loss.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Store session data in a shared Amazon ElastiCache cluster and modify the application to read/write session state to ElastiCache.
Storing session state in a shared Amazon ElastiCache cluster decouples session data from individual EC2 instances, allowing any instance in the Auto Scaling group to serve any user request without losing session data when instances are terminated or replaced. This approach requires minimal application changes (only modifying the session handler to point to ElastiCache) and supports high availability across multiple Availability Zones by using a replicated ElastiCache cluster (e.g., Redis with replication).
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use sticky sessions (session affinity) on the ALB and configure the Auto Scaling group with a larger min size.
Why it's wrong here
Sticky sessions (session affinity) route a given client to the same EC2 instance by cookie, but the session state is still stored in that instance's local memory. If the instance fails, is terminated by Auto Scaling, or scales in, the session data is lost regardless of the group's minimum size. Enlarging the min size only reduces the probability of such events; it does not provide the shared, durable session store needed for cross-AZ high availability.
- ✓
Store session data in a shared Amazon ElastiCache cluster and modify the application to read/write session state to ElastiCache.
Why this is correct
ElastiCache provides a centralized, in-memory data store (such as Redis) that can be shared by all EC2 instances in the Auto Scaling group. By moving session state to ElastiCache, the application becomes stateless at the instance level, so any instance can serve any user request without losing session data. ElastiCache supports replication and automatic failover, making session data highly available across Availability Zones. This directly satisfies the HA requirement and is the best practice for a decoupled web tier.
- ✗
Deploy the application in multiple AWS Regions and use Amazon Route 53 with latency-based routing.
Why it's wrong here
Deploying in multiple Regions with Route 53 latency-based routing is designed for disaster recovery and to route users to the lowest-latency Region, not for cross-AZ high availability within a single Region. It does not address the fundamental problem that session data is stored locally on each EC2 instance. Multi-Region adds significant cost and operational complexity, and latency-based routing could still send a user to an instance that does not have their session, unless you also implement session replication or a global session store, which is not described. The stated requirement is about surviving AZ failures, which is better solved with an ALB and Auto Scaling across AZs.
- ✗
Store session data in an Amazon RDS for MySQL database and configure the application to read/write session state to the database.
Why it's wrong here
While an RDS for MySQL database can persist session data, it is not optimized for the high-throughput, low-latency read/write pattern of web session management. Every session lookup involves a network round trip and SQL execution, which is significantly slower than an in-memory cache. Additionally, using a database for sessions introduces connection limits, increased load on the database, and requires more extensive application changes to implement session serialization and retrieval. ElastiCache is purpose-built for this use case because it provides microsecond latency and automatic failover, making it the better fit for decoupling session state from EC2 instances.
Go deeper
Related to this question
About these practice questions
This SOA-C02 question is part of Courseiva's 247-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
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.
Variation 1. A company runs a critical web application on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The application uses session stickiness (sticky sessions) to maintain user sessions. The SysOps administrator notices that when instances are replaced during a scale-in or failure event, users lose their session data. The administrator needs to preserve session data across instance failures without losing stickiness benefits. What should the administrator do?
medium- ✓ A.Disable sticky sessions on the ALB and configure the application to store session data in an external session store like Amazon ElastiCache for Redis.
- B.Increase the stickiness duration to a very high value so that sessions are not lost during brief interruptions.
- C.Change the Auto Scaling group to use a larger instance type to handle more sessions per instance, reducing the likelihood of session loss.
- D.Configure the Auto Scaling group to use a larger minimum size and a lower maximum, so instances are less likely to be terminated.
Why A: It eliminates the dependency on stickiness by storing session data externally in Amazon ElastiCache for Redis. This way, if an instance fails or is scaled in, any other instance can retrieve the session data from the shared cache, preserving the user session. Disabling sticky sessions is necessary because with external storage, stickiness is no longer needed and can cause uneven load distribution.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.