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.

• ✓

  Create a CloudWatch Logs metric filter to count 'ERROR' entries, then create a CloudWatch alarm on that metric with a period of 5 minutes and a threshold of 10.

  Why this is correct

  A CloudWatch Logs metric filter continuously scans incoming log events for the pattern 'ERROR' and increments a custom metric (e.g., ErrorCount) in near real time. The CloudWatch alarm evaluates that metric over a 5-minute period and triggers when the count crosses 10, providing fully managed, code-free alerting that also makes the metric available for dashboards and scaling decisions.

• ✗

  Use CloudWatch Logs Insights to run a query every 5 minutes and send notifications via a scheduled AWS Lambda function.

  Why it's wrong here

  CloudWatch Logs Insights is an interactive query engine designed for ad-hoc analysis of historical log data, not for real-time alerting. Scheduling a query every 5 minutes via Lambda introduces cold-start latency, concurrency limits, and API quotas, and it still polls rather than reacts, so you risk missing spikes between runs and incur complexity far beyond a built-in metric filter.

• ✗

  Create an AWS Lambda function that processes log events in real-time and publishes to Amazon SNS when the error count exceeds 10 in 5 minutes.

  Why it's wrong here

  Although a Lambda subscription filter can inspect each log event as it arrives, counting events over a sliding 5-minute window requires external state management (e.g., DynamoDB or ElastiCache) and careful handling of duplicate or out-of-order log events. This custom implementation adds significant cost, operational overhead, and potential for miscalculation, whereas a metric filter automatically maintains the aggregated count and alarm thresholds natively.

• ✗

  Use Amazon EventBridge to match log events with the pattern 'ERROR' and send them to an SNS topic.

  Why it's wrong here

  Amazon EventBridge event patterns match on structured JSON fields from AWS service events; they cannot natively parse unstructured text patterns inside CloudWatch Logs messages. Even if logs were routed via a subscription filter, EventBridge would emit a rule for every individual 'ERROR' occurrence rather than evaluating whether more than 10 events occur in a 5-minute window, so it cannot implement the required threshold-based alert.

Go deeper

Related to this question