How to Fix Forced Logouts Behind CloudFront and an ALB?

Answer Correct answer: B, D — Forward session cookies in the CloudFront cache behavior and enable stickiness on the ALB target groups so each stateful user stays bound to one EC2 instance.

Users are reporting consistent forced logouts from a stateful web application. The web application is hosted on Amazon EC2 instances that are in an Auto Scaling group. The instances run behind an Application Load Balancer (ALB) that has multiple target groups with one listener rule. The ALB is configured as the origin in an Amazon CloudFront distribution. Which combination of actions should a CloudOps engineer take to resolve the logout problem? (Choose two.)

  1. Change to the least outstanding requests algorithm on the ALB target group.
  2. Configure cookie forwarding in the CloudFront distribution's cache behavior settings. Correct Answer
  3. Configure header forwarding in the CloudFront distribution's cache behavior settings.
  4. Enable group-level stickiness on the ALB listener rule for the target groups. Correct Answer
  5. Configure weighted target groups on the ALB.

Community Insight

The exam tests session affinity at two independent layers—CloudFront must pass the session cookie and the ALB must pin the user to one target—so the trap is substituting header forwarding or a routing algorithm for cookie forwarding.

Stateful EC2 sessions behind CloudFront and an Application Load Balancer break when CloudFront does not forward cookies and the ALB does not keep each user on one target. The correct pair is B and D: forward cookies at the CloudFront cache behavior and enable stickiness on the ALB target groups.

A frequent wrong answer is C: forwarding headers does not forward cookies in CloudFront, so the application still loses the session; A and E are also tempting but only change how requests are distributed, not whether a user stays on the same instance.

Community Discussion (2 comments)

Bad_Mat 👍 2 Selected: BD
Correction The correct actions are B. Configure cookie forwarding in the CloudFront distribution's cache behavior settings and D. Enable group-level stickiness on the ALB listener rule for the target groups.
Bad_Mat 👍 1 Selected: BE
Application Load Balancer and Amazon CloudFront, a CloudOps engineer must choose options B and E (note: option E is implied/part of the standard pair, or if option E isn't listed with a missing/implied context, the correct standard combination is enabling sticky sessions on the ALB target group and configuring cookie forwarding in CloudFront). (Note: If evaluating the literal choices provided where E is missing from your specific prompt list, please see the breakdown below for the correct pair). Another old question

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

A stateful application stores session state on a specific EC2 instance, so every request in a user's session must reach that same instance. Option B makes CloudFront forward the application's session cookie, for example by forwarding all cookies or whitelisting the session cookie, so the cookie is not stripped or served from cache before the request reaches the ALB. Option D enables target-group stickiness, which uses the ALB-generated cookie to bind a client to one healthy target. With an Auto Scaling group, instances can be added or replaced, so stickiness plus cookie forwarding is the combination that preserves the existing session across the CloudFront-to-ALB path.

Why the Other Options Are Wrong

A, least outstanding requests, is a load-balancing algorithm that deliberately spreads new requests and does not preserve affinity. C, header forwarding, sounds close but CloudFront handles cookies as a separate cache-behavior setting; forwarding headers alone does not guarantee the session cookie reaches the origin. E, weighted target groups, is for splitting traffic between target groups by percentage—useful for blue/green or canary deployments, not for pinning a user's session to one backend.

Community Comment Notes

Bad_Mat's comment corrects the answer to B and D and explains the standard pair as cookie forwarding in CloudFront plus stickiness for the ALB target groups. Another comment raises B and E, but weighted target groups would still let requests move between targets and do not solve the forced-logout symptom. The useful consensus is to treat CloudFront cookie handling and ALB session affinity as two mandatory settings, not alternatives.

Official Reference

Exam Strategy

For a stateful app behind CloudFront and an ALB, first identify the two places where session identity can be lost: the CDN cache behavior and the load balancer's target affinity. Then eliminate options that only change load-balancing algorithms or weights, because those affect distribution rather than session persistence.

Frequently Asked Questions

Why is header forwarding (C) not enough to keep sessions alive?

CloudFront handles cookies as a separate cache-behavior setting; forwarding headers does not guarantee the application's session cookie reaches the ALB and backend instance.

Does least outstanding requests (A) preserve ALB session affinity?

No, it only changes how the ALB chooses a target for new requests; it does not pin a returning user to the same EC2 instance holding their session state.

More SOA-C03 FAQ →

Related Analysis

Practice All SOA-C03 Questions

Access 100 questions with complete answers and detailed explanations.

View Full SOA-C03 Practice Test →

← Back to SOA-C03 Study Guide