These questions are independently created for study purposes. They are not official AWS exam questions, actual exam questions, leaked questions, or exam dumps.
SAA-040
In a web application running on EC2 Auto Scaling, some users are logged out every time a scale-in or an instance failure occurs. Session information is stored on the local disk of each instance. Which improvement is the most appropriate?
Choices
Explanation and answer
Read the explanation and correct answer (spoiler — try answering first)
Correct answer: C. Move session information to an external data store such as Amazon ElastiCache or Amazon DynamoDB and make the application tier stateless
Explanation
The root cause is holding state on instances, which are short-lived resources. If you externalize session information to a shared data store such as ElastiCache or DynamoDB and make the application tier stateless, sessions are not lost no matter which instance terminates.
Per-choice explanations
A. Enable sticky sessions on the Application Load Balancer so that the same user is always forwarded to the same instance
Incorrect. Sticky sessions only keep forwarding to the same instance, and the session is lost when that instance terminates. It does not eliminate logouts during failures and creates a separate problem of uneven load.
B. Attach a dedicated EBS volume to each instance and store session files there
Incorrect. An EBS volume is attached to a single instance and is pinned to a single Availability Zone. Once the instance terminates, other instances cannot read that session.
C. Move session information to an external data store such as Amazon ElastiCache or Amazon DynamoDB and make the application tier stateless
Correct. Externalizing state lets you treat instances as disposable resources that can be thrown away at any time.
D. Raise the minimum capacity of the Auto Scaling group so that scale-in does not occur
Incorrect. Even with a higher minimum capacity, instances are still replaced due to failures or failed health checks. It only increases cost without solving the root cause.
Practical Use
In an architecture built on Auto Scaling, instances must be designed as things that may terminate at any time. Being selected for scale-in, being replaced after a failed health check, and disappearing in an AZ failure are all part of normal operation, and a design where each of these affects users does not meet the prerequisites of horizontal scaling. The basic design principle is to avoid holding state that exists only on that instance, such as session information or temporary files being uploaded; in other words, to make the application tier stateless. Common destinations for externalized sessions are Amazon ElastiCache (Redis / Valkey / Memcached) and Amazon DynamoDB. ElastiCache is in-memory with fast responses, and session expiry management with TTL is natural to write. The Redis family supports replication and automatic failover (Multi-AZ), so the cache tier itself can be made highly available. DynamoDB is serverless with no capacity management, supports automatic deletion via a TTL attribute, and with global tables can even share sessions across Regions. On the other hand, ALB sticky sessions (session affinity) can serve as a stopgap for existing applications, but understand that it does not solve session loss during instance failure and has the side effect of skewing load toward specific instances. Similarly, files that need to be shared should be placed on Amazon EFS or S3 rather than EBS. On SAA-C03, questions that present symptoms such as "users are logged out on every scale-in" or "cart contents disappear when an instance is replaced" and ask you to choose externalized state (ElastiCache / DynamoDB) are a staple. Distractors include enabling sticky sessions, raising the minimum capacity, and storing sessions on EBS. The property that EBS is tied to a single AZ and a single instance is the deciding factor in this judgment.