DOP-C02 Resilient Cloud Solutions 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.

• ✗

  Increase the instance memory to store more sessions

  Why it's wrong here

  Increasing instance memory only delays the inevitable: the session object still lives in the EC2 instance's local memory, so if that instance terminates, is patched, or is for autoscaling scaled in, all sessions cached on it are lost. It also makes the instances stickier in practice because large memory footprints make instance replacements more impactful, and it does nothing to let another instance serve a client whose session was created on a different instance.

• ✓

  Disable sticky sessions on the ALB

  Why this is correct

  Disabling sticky sessions on the ALB is a necessary precondition for a horizontally scalable, fault-tolerant design. With stickiness off, the ALB can route any request to any healthy target, so if an instance fails, the next request can be served by a different instance — assuming the session state is stored externally (for example, in ElastiCache or DynamoDB). This makes the application effectively stateless at the instance level, which also allows Auto Scaling to add or remove instances without worrying about breaking client sessions on a particular host.

• ✗

  Enable sticky sessions (session affinity) on the ALB

  Why it's wrong here

  Enabling sticky sessions (session affinity) is the opposite of what you want for a stateless architecture: it pins a client's requests to a single EC2 instance via a cookie, so that instance becomes the client's 'source of truth' for session data. If that instance goes down, the ALB cannot seamlessly shift that client to another instance because the new instance lacks the in-memory session context, resulting in dropped sessions and a poor user experience. Sticky sessions also interfere with uniform load distribution and complicate rolling deployments and instance replacement strategies.

• ✓

  Store session data in Amazon ElastiCache for Redis

  Why this is correct

  Storing session data in Amazon ElastiCache for Redis externalizes the session state, so each EC2 instance no longer holds any client-specific state. When a request arrives, any instance can read the session ID and pull the session data from Redis, making the web tier truly stateless and fault-tolerant. Because Redis offers sub-millisecond latency and supports data persistence, replication, and high availability, it is a common choice for session stores in AWS architectures, and it lets the ALB use plain round-robin or least-connections routing without sticky sessions.

• ✗

  Use an NLB instead of an ALB

  Why it's wrong here

  Swapping the ALB for an NLB does not solve the session state problem at all — an NLB operates at layer 4 and simply forwards TCP/UDP traffic to targets, without any concept of HTTP sessions, sticky sessions, or health checks at the application layer. You would still have the exact same issue: each instance keeps its own in-memory session data, and if a client is directed to an instance that lacks that session, the request fails. The NLB would also force you to implement session affinity manually (e.g., using source IP hashing) and would remove useful ALB features like path-based routing and HTTP header inspection.

Go deeper

Related to this question