SOA-C02 Networking and Content Delivery 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 Amazon CloudFront with origin stickiness enabled.

  Why it's wrong here

  Amazon CloudFront is a content delivery network that caches content at edge locations, but it does not provide layer-7 session affinity or any native 'origin stickiness' feature to bind a user to a specific EC2 instance. While CloudFront can forward cookies to the origin for cache decisions, it does not guarantee that all requests from a client are routed to the same instance, so session state would be lost when requests hit different origins. Therefore this option does not satisfy the requirement of maintaining session continuity.

• ✗

  Use a Network Load Balancer (NLB) with target group stickiness.

  Why it's wrong here

  A Network Load Balancer operates at the transport layer (L4) and does not inspect HTTP cookies, so its target group 'stickiness' is implemented as source IP hash-based routing rather than application-layer session affinity. Because clients often traverse NAT gateways, proxies, or mobile networks, their source IP can change mid-session, causing the NLB to route requests to a different EC2 instance and drop the session. Additionally, an NLB cannot generate a load balancer cookie (like ALB's AWSALB) for cookie-based stickiness, making it unsuitable for this stateful web application scenario.

• ✓

  Enable sticky sessions on the Application Load Balancer using a load balancer-generated cookie.

  Why this is correct

  The Application Load Balancer supports sticky sessions by generating a durable cookie (AWSALB) that is stored in the client's browser and mapped to the specific EC2 instance that handled the initial request. On subsequent requests, the ALB reads this cookie and routes the client to the same instance for the duration of the cookie's lifetime or until the instance becomes unhealthy. This mechanism is purpose-built for session-stateful web applications, and it adds negligible overhead because the routing decision is made entirely on the ALB without requiring external database reads or application code changes.

• ✗

  Store session state in Amazon DynamoDB and have each instance read from DynamoDB.

  Why it's wrong here

  Storing session state in DynamoDB introduces network latency for every request as each instance performs a separate read operation against an external database, whereas the correct approach uses the ALB’s native cookie-based stickiness to route requests to the same instance without any external calls. This option is tempting because DynamoDB is a fully managed, highly available key-value store ideal for offloading session persistence in stateless architectures, and would be correct if the requirement were to decouple session data from compute for resilience across instance failures.

Go deeper

Related to this question