How to get email notifications when ERROR appears in CloudWatch Logs?

A company deploys a new application to AWS. The company is streaming application logs to Amazon CloudWatch Logs. The company's development team must receive notification by email when the word "ERROR" appears in any log lines. A developer sets up an Amazon Simple Notification Service (Amazon SNS) topic and subscribes the development team to the topic. What should the developer do next to meet the requirements?

  1. Select the appropriate log group. Create a CloudWatch metric filter with "ERROR" as the search term. Create an alarm on this metric that notifies the SNS topic when the metric is 1 or higher. Source Reference Answer
  2. In CloudWatch Logs Insights, select the appropriate log group. Create a metric query to search for the term "ERROR" in the logs. Create an alarm on this metric that notifies the SNS topic when the metric is 1 or higher.
  3. Select the appropriate log group. Create an SNS subscription filter with "ERROR" as the filter pattern. Select the SNS topic as the destination.
  4. Create a CloudWatch alarm that includes "ERROR" as a filter pattern, a log group dimension that defines the appropriate log group, and a destination that notifies the SNS topic.

Community Votes

A
100%

100% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The exam tests whether you know that alarms require a metric, so log patterns must first be converted into a CloudWatch metric via a metric filter; the common trap is choosing an SNS subscription filter that looks plausible but only works for SNS messages, not logs.

To receive SNS email notifications for log events containing 'ERROR', you must create a CloudWatch Logs metric filter, set up a CloudWatch alarm based on that metric, and configure the SNS topic as the alarm action. The community overwhelmingly supports Option A, noting that SNS subscription filters and Logs Insights cannot trigger alarms directly.

The most common wrong choice is C, which incorrectly assumes SNS subscription filters can be applied to CloudWatch Logs. In reality, SNS subscription filters filter messages already sent to SNS, not log events in CloudWatch, and CloudWatch Logs cannot directly use an SNS filter pattern.

Community Discussion (4 comments)

DeaconStJohn 👍 6 Selected: A
Just clicked through the console to achieve this. C. SNS subscription filtering is not supported on cloudwatch log groups. B. Log insights lets me jump into the logs and not create a metric that can be pushed to SNS. D. Cloudwatch alarm works off a predefined metric and not a pattern such as ERROR. We need to create the metric to create the alarm
albert_kuo 👍 1 Selected: A
aws logs put-metric-filter --log-group-name /aws/lambda/my-log-group \ --filter-name ErrorFilter --filter-pattern "ERROR" \ --metric-transformations metricName=ErrorCount,metricNamespace=MyAppNamespace,metricValue=1
65703c1 👍 1 Selected: A
A is the correct answer.
KarBiswa 👍 3 Selected: A
https://docs.aws.amazon.com/sns/latest/dg/sns-monitoring-using-cloudwatch.html

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

Option A is correct because it follows the standard CloudWatch monitoring path: a metric filter converts matching log events ('ERROR') into a numeric metric, then a CloudWatch alarm watches that metric and triggers the SNS topic when the value reaches 1 or more. Commenters note that clicking through the console confirms this workflow, and one provides the CLI command aws logs put-metric-filter with --filter-pattern "ERROR" and --metric-transformations metricValue=1. This creates the metric needed by the alarm.

Why the Other Options Are Wrong

Option B is wrong because CloudWatch Logs Insights is meant for interactive log querying, not for defining persistent metric filters that can drive alarms; although you can run queries, they do not automatically create the metric and alarm relationship described. Option C is wrong because SNS subscription filters only apply to messages published to SNS, not to CloudWatch log groups, so a log group cannot have an SNS subscription filter with a log pattern. Option D is wrong because CloudWatch alarms are built from existing metrics and cannot contain a log filter pattern directly; they require a separate metric filter to be created first.

Community Comment Notes

The top comment (6 upvotes) explains that SNS subscription filtering is not supported on CloudWatch log groups, Logs Insights does not create a metric that can push to SNS, and CloudWatch alarms work off predefined metrics rather than patterns. Another comment (3 upvotes) links to the AWS documentation on monitoring SNS with CloudWatch. A third comment shows a concrete CLI example for the metric filter, reinforcing that the metric must be created before the alarm.

Official Reference

Exam Strategy

Remember that CloudWatch Logs cannot directly trigger SNS from a phrase in a log line; you must create a metric filter to count occurrences and then attach an alarm to that metric. If you see an option mentioning an SNS subscription filter on a log group, eliminate it immediately—that's a common distractor.

Related Analysis

Practice All DVA-C02 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DVA-C02 Practice Test →

← Back to DVA-C02 Study Guide