Capture ECS task state-change events with EventBridge and investigate stopped tasks in CloudWatch Logs Insights

Answer Correct answer: A — capture ECS task state changes with EventBridge into CloudWatch Logs and investigate stopped tasks with Logs Insights.

A DevOps engineer manages a company's Amazon Elastic Container Service (Amazon ECS) cluster. The cluster runs on several Amazon EC2 instances that are in an Auto Scaling group. The DevOps engineer must implement a solution that logs and reviews all stopped tasks for errors. Which solution will meet these requirements?

  1. Create an Amazon EventBridge rule to capture task state changes. Send the event to Amazon CloudWatch Logs. Use CloudWatch Logs Insights to investigate stopped tasks. Correct Answer
  2. Configure tasks to write log data in the embedded metric format. Store the logs in Amazon CloudWatch Logs. Monitor the ContainerInstanceCount metric for changes.
  3. Configure the EC2 instances to store logs in Amazon CloudWatch Logs. Create a CloudWatch Contributor Insights rule that uses the EC2 instance log data. Use the Contributor Insights rule to investigate stopped tasks.
  4. Configure an EC2 Auto Scaling lifecycle hook for the EC2_INSTANCE_TERMINATING scale-in event. Write the SystemEventLog file to Amazon S3. Use Amazon Athena to query the log file for errors.

Community Votes

A
100%

100% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The subject of the requirement is ECS task state changes, so an EventBridge rule on ECS task state-change events is the correct source, feeding CloudWatch Logs where Logs Insights can query them (A). Option B logs container output in embedded metric format, which is application log data rather than task lifecycle events, and monitoring ContainerInstanceCount reflects capacity, not task failures. Option C is anchored to EC2 instance logs, which are the wrong layer since the cluster's tasks are what stop. Option D's Auto Scaling lifecycle hook fires on instance termination, not on individual task failures.

The requirement is to log and review all stopped ECS tasks for errors across an ECS cluster running on Auto Scaling group EC2 instances. An Amazon EventBridge rule matching ECS task state-change events captures each task transition, including STOPPED, and sends the events to CloudWatch Logs. Because the events carry the task definition, container and exit details, CloudWatch Logs Insights can then be used to query and investigate exactly which stopped tasks ended in errors.

Using an Auto Scaling lifecycle hook on EC2_INSTANCE_TERMINATING (D) — this triggers when an instance is terminated during scale-in, not when an individual ECS task stops, so it cannot report the set of stopped tasks. Configuring Contributor Insights over EC2 instance log data (C) — teo2157 noted the question concerns ECS tasks, not EC2 instances, so instance-level log analysis is the wrong layer. Writing container logs in embedded metric format and watching ContainerInstanceCount (B) captures application logs and cluster capacity rather than task state transitions.

Community Discussion (5 comments)

6ef9a08 👍 6 Selected: A
By using Amazon EventBridge to capture ECS task state changes and sending these events to CloudWatch Logs, combined with the analytical capabilities of CloudWatch Logs Insights, option A provides a comprehensive and straightforward solution for logging and investigating stopped tasks for errors.
teo2157 👍 1 Selected: A
Going for A as C is referring to configure the EC2 instances to store logs in Amazon CloudWatch Logs while the question is referring to ECS tasks
tgv 👍 1
---> A
trungtd 👍 2 Selected: A
Just A
KaranNishad 👍 1 Selected: C
CloudWatch Contributor Insights

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

The requirement is to record and review all stopped ECS tasks, and the authoritative signal for a task's lifecycle is the ECS task state-change event. An EventBridge rule matching those events and targeting CloudWatch Logs persists every transition, including STOPPED, together with the task definition family, container name, and exit code or reason, which is the information needed for root-cause analysis. CloudWatch Logs Insights then lets an operator query and aggregate those records to find which stopped tasks terminated with errors.

Why the Other Options Are Wrong

B configures tasks to emit logs in the embedded metric format and monitors the ContainerInstanceCount metric. Application log output and a cluster-capacity metric do not represent task state transitions, so stopped tasks and their error states are not captured. C configures the underlying EC2 instances to send logs to CloudWatch and builds a Contributor Insights rule over instance log data; as teo2157 pointed out, the requirement concerns ECS tasks, so instance-level log analysis is the wrong layer and will not enumerate stopped tasks. D creates an Auto Scaling lifecycle hook for the EC2_INSTANCE_TERMINATING scale-in event and queries the SystemEventLog with Athena; this fires on instance termination during scale-in, not on individual task failures, so it cannot report stopped tasks. A is correct.

Community Comment Notes

Community voted A (90). Commenters agreed that EventBridge capturing ECS task state changes into CloudWatch Logs, combined with Logs Insights analysis, is what identifies errors on stopped tasks, and teo2157 explicitly contrasted this with C's EC2-instance focus. One commenter mentioned Contributor Insights, but the consensus and the wording of the requirement point to task state changes.

Official Reference

Related Analysis

Practice All DOP-C02 Questions

Access 85 questions with complete answers and detailed explanations.

View Full DOP-C02 Practice Test →

← Back to DOP-C02 Study Guide