SOA-C02 Monitoring, Logging, and Remediation 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 AWS CloudTrail and create a metric filter for RunTask API calls.

  Why it's wrong here

  CloudTrail records control-plane API calls such as RunTask, but it does not emit the task state events that contain the stoppedReason of RESOURCE:MEMORY. A metric filter on CloudTrail logs would require creating a log group from CloudTrail, and the pattern would need to match RunTask API activity, which only indicates that the task was requested, not why it later stopped. Because the failure occurs asynchronously in the ECS service after the API call, CloudTrail provides no visibility into the task's lifecycle or its memory-related stop reason.

• ✓

  Configure the CloudWatch Events rule to send notifications to an SNS topic.

  Why this is correct

  An Amazon SNS topic is the target of the CloudWatch Events rule, allowing notifications to be delivered via email, SMS, HTTP endpoints, or Lambda. By configuring an SNS subscription and including the topic as the event rule's target, the operator ensures that whenever the matching ECS task state change occurs, alerts are sent immediately. This is the notification mechanism that makes the monitoring actionable, rather than just detecting the event in the AWS console.

• ✓

  Create a CloudWatch Events rule that matches ECS task state changes with a reason of 'RESOURCE:MEMORY'.

  Why this is correct

  ECS task state changes are published as events with a detail type of 'ECS Task State Change', and the event payload includes fields such as lastStatus and stoppedReason. For tasks terminated because the container instance lacked sufficient memory, the stoppedReason is set to RESOURCE:MEMORY. Creating a rule with an event pattern that matches detail.lastStatus as STOPPED and detail.stoppedReason as RESOURCE:MEMORY precisely captures the failed tasks that need to be investigated.

• ✗

  Create a CloudWatch alarm on the ECS cluster's CPUUtilization metric.

  Why it's wrong here

  The CPUUtilization metric on an ECS cluster aggregates CPU usage across the cluster's container instances, so it will not reflect a single task failing to start due to memory. A task can be stopped with RESOURCE:MEMORY while the cluster's CPU utilization is low, because memory is the constrained resource. Additionally, CloudWatch alarms on this metric measure overall resource saturation, not task lifecycle failures, making them unsuitable for alerting on specific task start failures.

• ✗

  Enable CloudWatch Logs for the ECS cluster and filter for error messages.

  Why it's wrong here

  CloudWatch Logs for ECS captures container stdout and stderr, which is application-level logging, not the orchestration service's task state events. The RESOURCE:MEMORY stop reason is an ECS service event, not something written to the container's logs; the container may have failed to start entirely, producing no output. Even with log collection enabled, you would lack the structured event data needed to detect the memory constraint, so this approach would not trigger the required notification.

Go deeper

Related to this question