SOA-C02 Reliability and Business Continuity Practice Question

A company runs a web application on EC2 instances in an Auto Scaling group behind an Application Load Balancer. The application stores session data locally on each instance. During a traffic spike, the Auto Scaling group launches new instances, but users report that they are logged out and lose session data. Which solution addresses this issue without modifying the application?

⚠ Common exam trap

A common mix-up: candidates assume that scaling out (adding more instances) or scaling up (using larger instances) will solve session persistence issues, but they overlook that the real problem is the lack of a shared session store or a mechanism to pin users to the same instance, which sticky sessions directly address without code changes.

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

✓

Enable sticky sessions (session affinity) on the Application Load Balancer.

The application stores session data locally on each EC2 instance, so when new instances are launched during a traffic spike, the load balancer may route a user's subsequent request to a different instance that does not have their session data, causing them to be logged out. Enabling sticky sessions (session affinity) on the Application Load Balancer ensures that all requests from a user during a session are sent to the same instance, preserving the locally stored session data without requiring any application modifications.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Modify the application to use ElastiCache for session storage.
Why it's wrong here
Using ElastiCache for session storage would centralize session state across all instances, making it robust to instance failures and scaling events. However, this requires modifying the application to integrate with ElastiCache, which the question explicitly seeks to avoid. Since the requirement is to address the issue without code changes, this option is incorrect.
✓
Enable sticky sessions (session affinity) on the Application Load Balancer.
Why this is correct
Enabling sticky sessions (session affinity) on the Application Load Balancer routes requests from a particular client to the same EC2 instance for the duration of the session. This preserves the session data as long as that instance remains healthy and within the Auto Scaling group, even while the group scales out. It is a configuration-only change to the load balancer, requiring no application code modifications, making it the correct solution.
✗
Increase the cooldown period for the Auto Scaling group.
Why it's wrong here
Increasing the cooldown period for the Auto Scaling group only delays the time before scaling activities can start after a previous scaling action. It does not affect how existing sessions are handled, nor does it prevent instances from being terminated when the group scales in or due to health checks. A cooldown period cannot keep a client pinned to the same instance, so it fails to preserve session state.
✗
Use larger EC2 instance types to handle the traffic spike.
Why it's wrong here
Switching to larger EC2 instance types may reduce the frequency of scaling events by increasing the capacity of each instance, but it does not address the root cause of session loss. When an instance is still terminated—for example, during a scale-in or due to a failed health check—any sessions on that instance are lost regardless of instance size. This is a costly change that does not provide session affinity and therefore does not solve the problem.

Go deeper

SOA-C02 Reliability and Business Continuity Practice Question

Why each option matters

Option-by-option breakdown

Related to this question