SAP-C02 Continuous Improvement for Existing Solutions Practice Question

A startup runs a stateless REST API on a fleet of Amazon EC2 instances in an Auto Scaling group. The API stores session tokens in a local in-memory cache on each instance. During a scaling event, users are randomly logged out because their session token is not present on the new instance that serves their request. The team wants sessions to survive instance replacement and scale-out without changing the API code significantly. Which change should the solutions architect recommend?

⚠ Common exam trap

The trap here is relying on load balancer stickiness to preserve sessions, when stickiness only pins a user to an instance and does not survive that instance being replaced.

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

✓

Move session state to an Amazon ElastiCache for Redis cluster and have the API read and write tokens there.

Session state stored in instance memory cannot survive scale-out or instance replacement. Moving tokens to ElastiCache for Redis gives all instances a shared, low-latency store, so any instance can validate a session. The API change is minimal because only the cache client is swapped, and the fleet becomes truly stateless.

Answer analysis

Option-by-option breakdown

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

✗
Increase the Auto Scaling group's minimum capacity so instances are not replaced during traffic spikes.
Why it's wrong here
Raising minimum capacity reduces the frequency of scale-out but does not prevent instance replacement during health checks, deployments, or AZ events. Sessions stored in local memory are still lost whenever an instance is terminated. This approach also increases cost without solving the underlying statefulness problem.
✓
Move session state to an Amazon ElastiCache for Redis cluster and have the API read and write tokens there.
Why this is correct
ElastiCache for Redis provides a shared, highly available session store that all instances can access, so sessions survive instance replacement and scale-out. The API change is limited to replacing the local cache client with a Redis client. This directly removes the dependency on instance-local memory and supports horizontal scaling.
✗
Store session tokens in an Amazon S3 bucket and have each instance read the token on every request.
Why it's wrong here
Amazon S3 is not designed for low-latency, high-frequency session reads and writes, and eventual consistency for overwrites can cause stale tokens. Each request would incur an S3 API call, increasing latency and cost. It also lacks atomic update semantics needed for session refresh, making it unsuitable for this use case.
✗
Enable sticky sessions on the Application Load Balancer target group so each user is always routed to the same instance.
Why it's wrong here
Sticky sessions keep a user on one instance, but when that instance is replaced during a scaling or health event the session is still lost. It also creates uneven load distribution and does not allow the fleet to scale down safely. The requirement that sessions survive instance replacement is not met by affinity alone.

Go deeper

SAP-C02 Continuous Improvement for Existing Solutions Practice Question

Why each option matters

Option-by-option breakdown

Related to this question