SAP-C02 Continuous Improvement for Existing Solutions Practice Question

A company runs a web application on Amazon EC2 instances behind an Application Load Balancer (ALB). The application stores session data locally on the EC2 instances. The company wants to make the application stateless to improve availability and scalability. Which solution should the solutions architect recommend?

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

✓

Use Amazon ElastiCache for Redis to store session data externally.

Amazon ElastiCache for Redis provides a fast, in-memory, highly available session store that decouples session state from EC2 instances, making the application stateless. This improves availability and scalability. Option B is incorrect because session stickiness (sticky sessions) on the ALB ties a user to a specific instance, preventing true statelessness and can cause uneven load distribution. Option C is incorrect because mounting Amazon EFS to store session files still relies on a filesystem, which is slower than in-memory storage and does not eliminate statefulness. Option D is incorrect because Amazon S3 is not designed for high-frequency read/write operations like session management; it introduces high latency and is less efficient than ElastiCache.

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 Amazon ElastiCache for Redis to store session data externally.
Why this is correct
ElastiCache for Redis is a fast, in-memory store ideal for session management, making the application stateless.
✗
Configure session stickiness on the ALB to route requests from the same user to the same EC2 instance.
Why it's wrong here
Sticky sessions prevent statelessness and can cause uneven load distribution.
✗
Mount an Amazon EFS file system on the EC2 instances and store session files there.
Why it's wrong here
Mounting Amazon EFS for session files fails to make the application stateless. The application would still depend on persistent storage for session state, just on a shared network file system rather than local disk, which doesn't remove the state dependency from the application logic. EFS is appropriate for shared file system requirements, such as content repositories or common configuration files across multiple instances, where the application is designed to manage state via files.
✗
Store session data in Amazon S3 and update the application to read and write sessions to S3.
Why it's wrong here
S3 is not designed for low-latency, high-frequency session storage; it would introduce significant latency.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

SAP-C02 Continuous Improvement for Existing Solutions Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question