SOA-C02 Monitoring, Logging, and Remediation Practice Question

A SysOps administrator needs to monitor application logs in Amazon CloudWatch Logs for the occurrence of the string 'ERROR'. The administrator wants to create a custom metric that counts the number of 'ERROR' occurrences per 5-minute window and trigger an Amazon CloudWatch alarm when the count exceeds 10. Which action should the administrator take to create the custom metric?

⚠ Common exam trap

It's easy for candidates to confuse CloudWatch Logs metric filters with CloudWatch Events or CloudTrail, thinking those services can parse log content, when in fact only metric filters can extract and count patterns from log data.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Create a metric filter on the CloudWatch Logs log group that matches the term 'ERROR'.

Metric filters in CloudWatch Logs allow you to define a pattern (e.g., 'ERROR') that is evaluated against incoming log events. The filter counts occurrences and publishes a custom metric to CloudWatch, which can then be used to set an alarm with a period of 5 minutes and a threshold of 10.

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 Events rule that triggers on 'ERROR' and publishes a metric.
Why it's wrong here
Amazon CloudWatch Events (now EventBridge) only matches event patterns from AWS services, such as EC2 instance state changes, AWS API calls via CloudTrail, or scheduled events. It has no access to the text content of application log streams, so it cannot trigger on the literal string 'ERROR' inside a log event. Even if you attempt to use an EventBridge rule with a log-driven target, you'd need a separate subscription filter to forward log events to a Lambda function before any custom metric could be published.
✓
Create a metric filter on the CloudWatch Logs log group that matches the term 'ERROR'.
Why this is correct
A metric filter is the correct way to define a pattern to look for in log events. CloudWatch Logs uses the filter to publish a numeric metric to CloudWatch, which can then be used for alarms.
✗
Create a CloudWatch dashboard that displays the log group and set an alarm on the dashboard.
Why it's wrong here
A CloudWatch dashboard is solely a visualization layer that renders existing CloudWatch metrics or CloudWatch Logs Insights query results. It does not have the ability to generate new metrics from raw log data, and alarms are always bound to a named CloudWatch metric, not to a dashboard widget or a log group query. To alarm on 'ERROR' occurrences, you must first create a metric filter on the log group to emit a numeric metric, then set an alarm on that metric and optionally display it on a dashboard.
✗
Enable AWS CloudTrail on the log group and select the 'ERROR' pattern.
Why it's wrong here
AWS CloudTrail is an auditing service that records API activity within your AWS account; it does not ingest or monitor application log files written to CloudWatch Logs. You cannot 'enable CloudTrail on a log group' — CloudTrail events may be delivered to a CloudWatch Logs log group, but that log group contains CloudTrail's own JSON records, not your application's stdout or log file content. Furthermore, CloudTrail provides no pattern-based metric extraction mechanism, so it cannot select 'ERROR' or publish any metric based on log entry strings.

Go deeper

SOA-C02 Monitoring, Logging, and Remediation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question