SOA-C02 Networking and Content Delivery Practice Question

A company has a web application behind an Application Load Balancer (ALB) with sticky sessions enabled. The ALB's target group contains EC2 instances in an Auto Scaling group. After a deployment, users report that they are being logged out frequently. What is the most likely cause?

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The ALB's stickiness cookie is not configured or is being overwritten.

Sticky sessions (session affinity) rely on a cookie generated by the ALB (AWSALB) to route subsequent requests from a user to the same target. If the cookie is not configured or is overwritten (e.g., by the application after deployment), the ALB treats each request as new and may route to different instances, causing the user to be logged out. Option A is incorrect because deregistration delay controls how long the ALB waits before deregistering an instance, which does not affect existing sessions unless instances are being removed. Option C is incorrect because while frequent health checks may cause instances to be marked unhealthy, this would result in connection errors or routing to other instances, but it does not explain logouts due to sticky session loss. Option D is incorrect because cross-zone load balancing distributes traffic across zones but does not affect session stickiness.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The deregistration delay is set too low.
Why it's wrong here
A low deregistration delay only shortens the connection-draining window for instances that are already being removed from the target group. It does not change the ALB's routing decision for a healthy, registered instance, nor does it interfere with the session cookie that provides stickiness. Even with a very short delay, users would still be sent to the same target on subsequent requests unless the target actually deregisters.
✓
The ALB's stickiness cookie is not configured or is being overwritten.
Why this is correct
Sticky sessions on an Application Load Balancer rely on the AWSALB cookie being issued and honored by the client. If the stickiness policy is not enabled on the target group, or the application overwrites or strips the Set-Cookie header, the ALB receives no cookie and treats each request as a new session, routing it to any available target. This directly causes the observed behavior of users losing their session.
✗
Health checks are too frequent and marking instances unhealthy.
Why it's wrong here
Health check frequency alone does not cause stickiness to fail; it determines how quickly the ALB removes an unhealthy target from rotation. If an instance passes a health check, even a very aggressive interval, the ALB will continue honoring the sticky cookie and send the session to that same instance. Session loss would only occur if the instance actually goes unhealthy and is deregistered, which is a separate condition from simply checking too often.
✗
Cross-zone load balancing is disabled.
Why it's wrong here
Disabling cross-zone load balancing changes how the ALB distributes traffic across availability zones, but it does not interact with the session cookie. Even when only local targets receive traffic, the ALB still honors the AWSALB cookie and directs a client to the same target instance until the cookie expires or the target becomes unhealthy. Thus, it cannot be the cause of users being randomly routed to different instances across requests.

Go deeper

SOA-C02 Networking and Content Delivery Practice Question

Why each option matters

Option-by-option breakdown

Related to this question