DOP-C02 Incident and Event Response Practice Question
A company runs a stateful web application on EC2 instances behind an Application Load Balancer. The application uses sticky sessions (session affinity) based on cookies. During a deployment, the DevOps engineer notices that some users are being logged out and losing session data. The deployment uses a rolling update strategy. What is the MOST likely cause?
⚠ Common exam trap
The trap is blaming the deployment strategy or health checks when the real issue is architectural — local session storage is incompatible with elastic, stateless compute.
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 session data is stored locally on the EC2 instance, not in a shared external store.
Sticky sessions on the ALB bind a user to a specific EC2 instance via a cookie (AWSALB). If session data is stored locally on that instance, terminating the instance during a rolling update destroys the session data, logging the user out. The correct fix is to externalize session state to a shared store like ElastiCache, DynamoDB, or a database so any instance can serve any user.
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 Auto Scaling group is terminating instances before the new ones are fully ready.
Why it's wrong here
In an Auto Scaling rolling update, the old instance is terminated only after the new instance passes its health checks, so the termination itself is not premature. Even if termination timing were off, removing the EC2 instance would not log users out if their session data were persisted in an external store. The actual cause is that the session data lives on the instance's local filesystem or memory.
- ✗
The health check interval is too long, causing the ALB to route traffic to unhealthy instances.
Why it's wrong here
A long ALB health check interval may delay the removal of an unhealthy instance from the target group, but it does not affect the session data stored on that instance. Health checks only control traffic routing; they neither delete nor preserve sessions. The reported user logout is a result of the instance being terminated during the deployment, not of health check frequency.
- ✗
The ALB sticky session cookie is not being generated correctly.
Why it's wrong here
The ALB's sticky session cookie is generated by the load balancer itself and is independent of the deployment process, so it remains valid for the duration of the client's interaction. A correctly generated cookie still points to an instance that no longer exists after the rolling update, causing the session to be lost. Thus, cookie generation is not the root cause of the reported issue.
- ✓
The session data is stored locally on the EC2 instance, not in a shared external store.
Why this is correct
Because the web application stores its session state locally—either in memory (e.g., a servlet HttpSession) or on the instance's ephemeral disk—any instance replacement destroys active sessions. During a rolling update, the Auto Scaling group terminates old instances after launching new ones, forcing users who had sessions on those instances to be logged out. Moving session data to a shared external store such as ElastiCache for Redis, DynamoDB, or a central database makes sessions independent of instance lifecycle and prevents this behavior.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 1,298 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on DOP-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A company runs a stateful web application on EC2 instances behind an Application Load Balancer. The application uses sticky sessions (session affinity) based on cookies. During a deployment, the Auto Scaling group launches new instances, but users experience session loss. What is the most likely cause?
hard- A.The Auto Scaling group's lifecycle hooks are not configured.
- B.The stickiness duration is set too low.
- ✓ C.The target group's deregistration delay is too short.
- D.The target group's health check interval is too long.
Why C: The most likely cause of session loss during deployment is that the target group's deregistration delay is too short. When an instance is deregistered (e.g., during scaling in or deployment), the ALB stops routing new requests to it but allows existing connections to complete within the deregistration delay. If this delay is too short, in-flight requests may be terminated, causing session loss for users with sticky sessions. The other options do not directly cause session loss during instance replacement.
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.