DOP-C02 · Question #134
A company is testing a web application that runs on Amazon EC2 instances behind an Application Load Balancer. The instances run in an Auto Scaling group across multiple Availability Zones. The…
The correct answer is D. Modify the application to store user session information in an Amazon ElastiCache cluster. Explanation Storing user session information in Amazon ElastiCache (Redis or Memcached) is the correct solution because it provides a centralized, low-latency, in-memory session store that all EC2 instances can access simultaneously - meaning sessions persist regardless of…
Question
A company is testing a web application that runs on Amazon EC2 instances behind an Application Load Balancer. The instances run in an Auto Scaling group across multiple Availability Zones. The company uses a blue/green deployment process with immutable instances when deploying new software. During testing, users are being automatically logged out of the application at random times. Testers also report that, when a new version of the application is deployed, all users are logged out. The development team needs a solution to ensure users remain logged in across scaling events and application deployments. What is the MOST operationally efficient way to ensure users remain logged in?
Options
- AEnable smart sessions on the load balancer and modify the application to check for an existing
- BEnable session sharing on the load balancer and modify the application to read from the session store.
- CStore user session information in an Amazon S3 bucket and modify the application to read session
- DModify the application to store user session information in an Amazon ElastiCache cluster.
How the community answered
(28 responses)- A4% (1)
- B11% (3)
- C29% (8)
- D57% (16)
Explanation
Explanation
Storing user session information in Amazon ElastiCache (Redis or Memcached) is the correct solution because it provides a centralized, low-latency, in-memory session store that all EC2 instances can access simultaneously - meaning sessions persist regardless of which instance serves the request, whether scaling events add/remove instances, or whether a new application version is deployed on fresh (immutable) instances.
Why the distractors are wrong:
- Option A ("smart sessions") is not a real AWS feature on Application Load Balancers; sticky sessions exist, but they bind users to specific instances, which still causes logouts when those instances are terminated during scaling or blue/green deployments.
- Option B ("session sharing on the load balancer") is also fabricated terminology - ALBs do not have a native "session sharing" feature that reads from an external session store.
- Option C (Amazon S3) could technically store session data, but S3 is object storage designed for throughput, not low-latency key-value lookups; it would be slow, costly at scale, and operationally inefficient compared to ElastiCache.
Memory Tip: Think of ElastiCache as a shared whiteboard visible to every server - no matter which EC2 instance handles your request, it can always read your session from the same whiteboard, surviving any instance replacement.
Topics
Community Discussion
No community discussion yet for this question.