DVA-C02 Troubleshooting and Optimization Practice Question

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 sticky sessions on the Application Load Balancer

  Why it's wrong here

  Using sticky sessions (session affinity) on an Application Load Balancer attempts to route a user's requests consistently to the same EC2 instance. While this can simplify local session management, it creates an anti-pattern for highly available and scalable architectures. Sticky sessions can lead to uneven load distribution across instances and, critically, if the 'sticky' instance fails or becomes unhealthy, the user's session is immediately lost, causing service disruption and requiring re-authentication, thus undermining fault tolerance.

• ✗

  Store session data in an S3 bucket

  Why it's wrong here

  Storing session data in an S3 bucket is fundamentally unsuitable for web application session management due to its high latency and object storage paradigm. S3 is optimized for durable, cost-effective storage of large, infrequently accessed objects, not for the rapid, low-latency key-value lookups and frequent updates required by interactive user sessions. Each session read or write would incur significant network overhead and processing time, leading to a sluggish user experience and poor application performance.

• ✓

  Use Amazon ElastiCache for Redis to store session state

  Why this is correct

  Amazon ElastiCache for Redis provides a highly performant, scalable, and fully managed in-memory data store perfectly suited for externalizing session state. Its extremely low-latency read and write capabilities ensure a responsive user experience, while its built-in replication and automatic failover mechanisms guarantee high availability and durability of session data. By storing sessions externally, any EC2 instance in an Auto Scaling group can access any user's session, enabling seamless horizontal scaling and robust fault tolerance without session loss.

• ✗

  Store session data in the instance's ephemeral storage

  Why it's wrong here

  Storing session data on an EC2 instance's ephemeral storage (instance store) is highly problematic because this data is non-durable and tied directly to the lifecycle of a single instance. If the instance stops, terminates, or fails, all session data is permanently lost, forcing users to re-authenticate. Furthermore, this approach prevents session sharing across multiple instances in an Auto Scaling group, making horizontal scaling impossible and severely compromising application high availability and fault tolerance.

Go deeper

Related to this question