DOP-C02 Monitoring and Logging 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.

• ✓

  Create a CloudWatch alarm on the 'RunningTaskCount' metric.

  Why this is correct

  The RunningTaskCount metric is an ECS control-plane metric automatically emitted by AWS for each service and cluster, including services running on Fargate. An alarm on this metric can directly compare the current running task count against a threshold or the DesiredTaskCount, and notify via SNS when it falls below expected levels. This is the simplest, most direct way to detect service degradation without any additional agents or instrumentation.

• ✗

  Install the CloudWatch agent on the task containers.

  Why it's wrong here

  The CloudWatch agent is a software daemon intended for EC2 instances and on-premises servers to collect operating system-level metrics and custom logs. In the Fargate launch type, you do not have access to the underlying infrastructure, and AWS does not support installing the agent directly into task containers; doing so would require a custom sidecar and would not expose the ECS service-level RunningTaskCount metric. ECS automatically publishes task count metrics to CloudWatch, so the agent adds no value for this monitoring requirement.

• ✓

  Enable Container Insights for the ECS cluster.

  Why this is correct

  Container Insights for ECS is an AWS-integrated monitoring solution that automatically gathers telemetry from clusters, services, and tasks, including metrics such as RunningTaskCount, CPU, and memory. To activate it you only need to enable Container Insights on the cluster; it then uses the embedded CloudWatch agent and performance events to aggregate data into the ECS/ContainerInsights namespace. This provides a richer operational view and can also be the foundation for alarms through the service's built-in dashboards.

• ✗

  Configure a CloudWatch Logs subscription filter to count tasks.

  Why it's wrong here

  A CloudWatch Logs subscription filter is designed to stream matched log entries to a target like Lambda or OpenSearch for real-time processing, not to generate time-series metrics. To count tasks, you would need to ensure every task produces a recognizable log entry on startup, then build a separate consumer to count those events and publish a custom metric—an indirect, complex, and error-prone approximation. Moreover, log events are not emitted for tasks that fail before logging, so subscription filters cannot reliably reflect the actual RunningTaskCount metric.

• ✗

  Create a service auto scaling target for the ECS service.

  Why it's wrong here

  A service auto scaling target is an Application Auto Scaling configuration that defines the resource type and minimum/maximum capacity for a service; it simply declares that scaling is enabled. By itself, it does not monitor anything, emit metrics, or raise alarms—you would still need a scaling policy (e.g., target tracking on CPU or memory) to actually adjust capacity. Creating a scaling target never changes the CloudWatch metric availability; it is purely a mechanism for managing desired count, not for detecting or alerting on running task shortages.

Go deeper

Related to this question