DOP-C02 Resilient Cloud Solutions Practice Question
A company runs a high-traffic e-commerce application on EC2 instances in an Auto Scaling group behind an ALB. The application uses an in-memory cache on the EC2 instances. During a recent deployment, the Auto Scaling group terminated an instance that had active user sessions, causing users to lose their cart data and leading to a poor customer experience. The company wants to prevent this in future deployments. They need a solution that allows existing sessions to complete before instance termination, without manual intervention. Which solution should they use?
⚠ Common exam trap
DOP-C02 often tests the misconception that ALB connection draining alone handles graceful instance termination — candidates forget that connection draining only covers in-flight requests, not in-memory application state or session persistence.
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
✓
Implement an Auto Scaling lifecycle hook that puts the instance in a 'terminating:wait' state, and have a script on the instance that signals completion after draining sessions.
An Auto Scaling lifecycle hook puts the instance into a 'terminating:wait' state when the ASG decides to terminate it, pausing the termination process. A script on the instance can then drain active sessions (e.g., finish processing requests, flush cart data to a persistent store) and call CompleteLifecycleAction to signal completion, after which the ASG proceeds with termination. This is the only option that provides a programmable, instance-level mechanism to gracefully complete sessions before termination without manual intervention.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the Auto Scaling group's cooldown period and health check grace period.
Why it's wrong here
Cooldown periods suspend scaling activities for a specified time after a scaling action, and health check grace periods delay when an instance is considered unhealthy after launch. Neither mechanism influences the termination phase: they only affect when scaling or health checks occur, not how an instance is shut down. Because they never pause or script the termination process, in-flight sessions would still be abruptly cut off when the instance is terminated.
- ✗
Enable connection draining on the ALB target group and increase the deregistration delay.
Why it's wrong here
Connection draining, also called deregistration delay, instructs the load balancer to stop routing new requests to an instance and wait for existing TCP/HTTP connections to close before deregistering it. However, the ALB's deregistration process is independent of the EC2 instance's lifecycle: Auto Scaling can still terminate the underlying instance while the ALB waits, and the wait only covers open network connections, not application-level session state like shopping cart data or background jobs. Therefore, increasing this delay does not guarantee that application sessions finish gracefully.
- ✓
Implement an Auto Scaling lifecycle hook that puts the instance in a 'terminating:wait' state, and have a script on the instance that signals completion after draining sessions.
Why this is correct
A lifecycle hook pauses the Auto Scaling termination process by moving the instance into the 'terminating:wait' state, giving you a configurable period to perform custom actions before the instance is finally terminated. An in-instance script or agent can monitor and gracefully drain active user sessions, commit any required state, and then call complete-lifecycle-action with the appropriate lifecycle hook token to signal that termination may proceed. This is the only option that actually holds the termination process itself and coordinates with application-level work rather than merely affecting network connections or scaling timers.
- ✗
Change the health check type to ELB and mark instances unhealthy before deployment.
Why it's wrong here
Switching the Auto Scaling group's health check type to ELB and manually marking instances as unhealthy during deployment causes Auto Scaling to immediately regard the instance as failed and replace it. This triggers the normal unhealthy-instance termination flow, which does not include a drain or grace period for active sessions. Additionally, marking instances unhealthy before they have received traffic could interfere with the deployment itself, as the instance might be terminated before it ever becomes ready, and no application-level session completion is honored. Thus, this approach makes graceful draining impossible.
Go deeper
Related to this question
About these practice questions
One of 1,298 original DOP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
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.