DVA-C02 Troubleshooting and Optimization Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Enable detailed monitoring on the Auto Scaling group.

  Why it's wrong here

  Enabling detailed monitoring on the Auto Scaling group only changes the CloudWatch metric granularity from 5-minute to 1-minute intervals (e.g., for CPUUtilization). It does not generate termination events, send notifications, or invoke any code when an instance is about to be terminated. Detailed monitoring is entirely passive telemetry, so it cannot satisfy the requirement to know when instances are terminating.

• ✓

  Configure a CloudWatch Events rule to capture Auto Scaling termination events.

  Why this is correct

  A CloudWatch Events (now Amazon EventBridge) rule can match Auto Scaling lifecycle events such as EC2 Instance-terminate or EC2 Instance Launch. When a termination event occurs, the rule can trigger a Lambda function, SNS topic, or SQS queue to log, alert, or execute remediation. This directly captures termination signals and is the appropriate fully managed way to react to Auto Scaling terminations without modifying the group's behavior.

• ✗

  Install the CloudWatch Logs agent on the instances to capture application logs.

  Why it's wrong here

  The CloudWatch Logs agent sends application and OS logs to CloudWatch Logs for centralized viewing and alerting, but it does not listen for Auto Scaling lifecycle signals. Even if the instance logs a graceful shutdown message, that log is only written on the instance and may not be reliably flushed before termination. Logs can help post-incident forensics, but they do not provide a real-time, guaranteed termination notification from the Auto Scaling service itself.

• ✓

  Add a lifecycle hook to the Auto Scaling group to pause termination.

  Why this is correct

  A lifecycle hook pauses an instance during scale-in after the instance has been marked for termination but before it is actually terminated. The instance enters a 'terminating:wait' state, giving you time to run custom code (e.g., draining connections, uploading data) and then complete the hook with a CONTINUE or ABANDON result. This is the correct method when you need to perform cleanup on the instance itself before it is destroyed, and it can work alongside an EventBridge rule for notification.

• ✗

  Use an Elastic Load Balancer to replace instances automatically.

  Why it's wrong here

  An Elastic Load Balancer distributes traffic to healthy instances and can deregister instances that fail health checks, but it does not manage Auto Scaling termination behavior or notify you why an instance is being replaced. ELB health checks are for traffic routing, not for detecting Auto Scaling scale-in events (which may occur due to scaling policies, spot interruptions, or AZ rebalancing). It cannot provide a notification when Auto Scaling decides to terminate an instance.

Go deeper

Related to this question