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 state locally on each instance. The company wants to improve the availability and scalability of the application by making the session state external and allowing any instance to handle any request. The solution must minimize latency for session access and require minimal changes to the application code. Which approach should a solutions architect recommend?
⚠ Common exam trap
The trap here is choosing sticky sessions as a quick fix, which does not externalize session state or improve availability.
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 state in an Amazon ElastiCache for Redis cluster and modify the application to use the ElastiCache endpoint for session storage.
Externalizing session state to ElastiCache for Redis provides low-latency, high-performance session storage that allows any EC2 instance to handle any request. This improves availability and scalability. Modifying the application to use Redis is a standard pattern and requires minimal code changes compared to other options. Sticky sessions do not solve the underlying issue, and RDS or S3 introduce higher latency.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store session state in an Amazon RDS for MySQL database and modify the application to use the database for session storage.
Why it's wrong here
RDS can store session state, but it introduces higher latency compared to an in-memory cache. For session data that is accessed on every request, a relational database may become a bottleneck and increase response times. While it externalizes sessions, it does not minimize latency as required. ElastiCache for Redis is specifically designed for low-latency access and is a better fit for this scenario.
- ✗
Enable sticky sessions (session affinity) on the ALB and keep session state local on each instance.
Why it's wrong here
Sticky sessions ensure that a user is routed to the same instance for the duration of a session, but they do not externalize session state. If an instance fails, the session is lost, and the user must re-authenticate or lose data. This approach does not improve availability or allow any instance to handle any request; it merely masks the problem. It also can lead to uneven load distribution.
- ✓
Store session state in an Amazon ElastiCache for Redis cluster and modify the application to use the ElastiCache endpoint for session storage.
Why this is correct
ElastiCache for Redis provides a low-latency, in-memory data store that is ideal for session state. By externalizing sessions to Redis, any instance can handle any request, improving availability and scalability. The application code needs to be modified to read and write sessions to Redis, but this is a common and minimal change. Redis also supports high availability with automatic failover when using a multi-AZ replication group.
- ✗
Use Amazon S3 to store session state and have the application read and write session data to S3 on each request.
Why it's wrong here
S3 is an object store with higher latency than in-memory caches. Using S3 for session state on every request would introduce significant latency and is not suitable for high-performance session management. S3 is eventually consistent for overwrite PUTs and does not provide the low-latency, atomic operations needed for session data. This approach would degrade application performance.
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
Related to this question
About these practice questions
One of 984 original SAP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
This SAP-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 SAP-C02 exam.