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 metric filter on the log group and then create a CloudWatch alarm on the resulting metric

  Why this is correct

  A metric filter applied to a CloudWatch Logs log group continuously scans incoming log events for a specified pattern (e.g., a literal string or a JSON field value) and converts matching events into a CloudWatch custom metric. Once the metric is published, you can configure a CloudWatch alarm on that metric with thresholds, evaluation periods, and actions such as sending to an SNS topic. This built-in pattern-matching capability runs entirely within the CloudWatch service, with no additional compute or custom code, and is the standard design for alerting on log content.

• ✗

  Create a CloudWatch alarm directly on the log group

  Why it's wrong here

  CloudWatch alarms are designed to operate on numeric metrics—such as a custom metric emitted by a metric filter—not on raw log groups as a monitoring dimension. The “Alarms” console and API require you to specify a metric name, namespace, and statistic; a log group alone contains no comparable numeric data stream for a threshold to evaluate. Attempting to attach an alarm directly to a log group has no supported action in the CloudWatch service, so this option is technically invalid and would not produce any alert.

• ✗

  Create an AWS Lambda function to parse the logs and send a notification to Amazon SNS

  Why it's wrong here

  While an AWS Lambda function could be subscribed to a CloudWatch Logs log group to parse each log event and publish to an SNS topic, this approach introduces significant operational overhead: you must manage Lambda concurrency, retries, failure handling, IAM permissions, and memory/timeout settings, and you will incur invocation costs for every log event. CloudWatch Logs metric filters already perform pattern matching natively and push only aggregated, numeric values to CloudWatch, making the Lambda-based path unnecessarily complex, less reliable, and more expensive for a straightforward log-content alert.

• ✗

  Create an Amazon EventBridge rule to filter log events and send to SNS

  Why it's wrong here

  An Amazon EventBridge rule cannot directly “filter log events” from CloudWatch Logs because EventBridge operates on events emitted to the default or custom event buses, not on real-time log streams. While CloudWatch Logs can integrate with EventBridge for specific log-based triggers (e.g., actions like AWS API calls via CloudTrail), arbitrary log pattern matching is outside that integration model. The appropriate native mechanism is a CloudWatch Logs metric filter feeding a CloudWatch alarm, not an EventBridge rule, which would require an intermediary transport to make log data available as an event.

Go deeper

Related to this question