Connection Draining for Zero-Downtime Deployments
A company is running a stateful web application on EC2 instances behind an Application Load Balancer. During a deployment, users report session timeouts. What should the DevOps engineer implement to ensure zero-downtime deployments without losing in-flight sessions?
Quick Answer
The correct answer is to enable connection draining, also known as deregistration delay, on the ALB target group and pair it with Auto Scaling lifecycle hooks to wait for the draining period. This works because connection draining allows the load balancer to stop sending new requests to an instance being de-registered while still completing any in-flight sessions, preventing the abrupt termination that causes user timeouts. On the AWS Certified DevOps Engineer Professional DOP-C02 exam, this scenario tests your understanding of how to achieve zero-downtime deployments with stateful applications, often appearing as a trap where candidates confuse health check thresholds or launch template updates with session preservation. A common pitfall is assuming Auto Scaling alone handles graceful shutdowns, but it does not—lifecycle hooks are required to pause termination until the draining period expires. Memory tip: think “drain before you drain” — let the ALB drain connections before the instance drains from the ASG.
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
✓
Enable connection draining (deregistration delay) on the ALB target group and use lifecycle hooks to wait for the draining period.
Connection draining (deregistration delay) on the ALB target group allows in-flight requests to complete before instances are deregistered, and lifecycle hooks can be used to wait for the draining period before terminating instances, ensuring zero-downtime deployments without losing in-flight sessions. Option A is incorrect because updating the launch template and performing a rolling update does not inherently handle in-flight sessions; session stickiness would still cause timeouts if instances are terminated abruptly. Option B is incorrect because using a lifecycle hook that waits for instance termination without connection draining does not ensure that existing sessions are completed. Option D is incorrect because increasing health check intervals and unhealthy thresholds only delays the detection of unhealthy instances but does not prevent session loss during deployments.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Update the Auto Scaling group's launch template to use a new AMI and perform a rolling update.
Why it's wrong here
Rolling updates replace instances gradually but may still terminate instances with active sessions.
- ✗
Use an Auto Scaling group with a lifecycle hook that waits for instance termination.
Why it's wrong here
Lifecycle hooks can delay termination but do not guarantee session completion; ALB connection draining is needed.
- ✓
Enable connection draining (deregistration delay) on the ALB target group and use lifecycle hooks to wait for the draining period.
Why this is correct
Deregistration delay ensures in-flight requests complete; lifecycle hooks provide additional control over termination.
- ✗
Increase the health check interval and unhealthy threshold on the ALB target group.
Why it's wrong here
This delays removal of unhealthy instances but does not preserve sessions.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 251 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 stateless web application on AWS Lambda behind an Application Load Balancer (ALB). During a deployment, the team updates the Lambda function to a new version. Some users report seeing the old version of the application for several minutes after the deployment. What is the MOST likely cause?
hard- A.The Lambda function versions are not immutable, causing a gradual rollout.
- B.Lambda@Edge is overriding the function version at the edge locations.
- C.Amazon CloudFront is caching the old response and has not been invalidated.
- ✓ D.The ALB target group is still pointing to the old Lambda function version due to connection draining.
Why D: When an ALB is used with Lambda, the ALB invokes a specific Lambda function version or alias. If the deployment updates the Lambda function but the ALB target group alias is not updated atomically, or if connection draining keeps old connections active, some requests may still be routed to the old version. This can cause users to see the old application for several minutes. Option A is wrong because Lambda versions are immutable, so gradual rollout is not related. Option B is wrong because Lambda@Edge is not used in this setup (the application runs behind an ALB, not CloudFront). Option C is wrong because CloudFront is not mentioned in the architecture—the traffic goes directly from ALB to Lambda.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.