Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, the confusion often lies in how to correctly trigger alerts from CloudWatch Logs based on text patterns in streaming logs. In production, this is about knowing exactly which AWS features to combine—metric filters versus Logs Insights queries—to generate meaningful real-time alarms that tie into SNS notifications. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
BrightApps Inc., a software startup, has just launched a new distributed web application on AWS. Application logs are continuously being sent to Amazon CloudWatch Logs. The development team wants to receive immediate email notifications if any log entries contain the word “ERROR” — to rapidly respond to issues in production. A developer has already created an Amazon SNS topic and subscribed the team’s email addresses to it.
The Requirement #
What is the next best step the developer should take to detect when “ERROR” appears in the logs and notify the team through the SNS topic?
The Options #
- A) Select the application log group. Create a CloudWatch metric filter with “ERROR” as the filter pattern. Then create a CloudWatch alarm on this metric, configured to notify the SNS topic when the metric is 1 or higher.
- B) In CloudWatch Logs Insights, select the log group. Create a metric query that searches for the term “ERROR” in the logs. Then create an alarm on this query to notify the SNS topic when it returns a result of 1 or more.
- C) Select the log group. Create an SNS subscription filter with “ERROR” as the pattern and set the SNS topic as the destination.
- D) Create a CloudWatch alarm that uses “ERROR” as a filter pattern, specify the log group as a dimension, and configure the alarm to notify the SNS topic.
Google adsense #
leave a comment:
Correct Answer #
A
Quick Insight: The Developer Imperative #
Relying on CloudWatch metric filters to convert log events into numerical metrics that a CloudWatch alarm can monitor is the standard and most effective approach. Logs Insights queries (Option B) can’t directly trigger alarms, and SNS subscription filters do not exist on CloudWatch Logs (Option C is invalid). Setting alarm filter patterns requires metric filters first — they are the core building block.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option A
The Winning Logic #
- CloudWatch Logs metric filters are how you transform text log entries into numeric CloudWatch metrics. Here, the filter pattern “ERROR” will increment the metric for each matching log line.
- The CloudWatch alarm then monitors this custom metric and triggers if the count of matching entries is 1 or greater, sending notifications via the SNS topic subscribed by the dev team.
- This end-to-end flow — Log Group → Metric Filter → Metric → Alarm → SNS Notification — is the best practice for real-time log-based alerting.
- The AWS SDKs and CLI reflect this flow with specific commands to create metric filters (
put-metric-filter) and alarms (put-metric-alarm).
The Trap (Distractor Analysis): #
- Why not B? CloudWatch Logs Insights queries are powerful for ad hoc log analysis, but you cannot create alarms directly from Logs Insights queries. You’d need a metric filter to generate an alarm metric first.
- Why not C? There is no such feature as an SNS subscription filter on CloudWatch Logs. SNS subscriptions cannot directly filter or read logs; SNS is just a notification delivery mechanism.
- Why not D? A CloudWatch alarm itself cannot directly include a “filter pattern” or log group dimension for log events without an underlying metric filter. Metric filters must be created before alarms watch the metrics.
The Technical Blueprint #
# Example AWS CLI commands to implement the correct solution:
# Create a metric filter on the log group "app-log-group" to track "ERROR" occurrences
aws logs put-metric-filter \
--log-group-name "app-log-group" \
--filter-name "ErrorCountFilter" \
--filter-pattern "ERROR" \
--metric-transformations metricName=ErrorCount,metricNamespace=MyAppMetrics,metricValue=1
# Create a CloudWatch alarm that monitors the metric from the filter created
aws cloudwatch put-metric-alarm \
--alarm-name "ErrorCountAlarm" \
--metric-name "ErrorCount" \
--namespace "MyAppMetrics" \
--statistic Sum \
--period 60 \
--threshold 1 \
--comparison-operator GreaterThanOrEqualToThreshold \
--evaluation-periods 1 \
--alarm-actions arn:aws:sns:region:account-id:dev-team-sns-topic
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Medium - Requires put-metric-filter and put-metric-alarm |
Near real-time with CloudWatch alarm evaluation | Best for automated email alerts on specific log patterns |
| B | High - Requires Logs Insights query setup and a metric extraction workaround | No built-in alarm support; requires custom solutions | Ad hoc queries, not real-time alerts |
| C | Invalid - No SNS subscription for Logs | N/A | Conceptually incorrect |
| D | Invalid - Alarm cannot directly filter logs | N/A | Misunderstands metric filter role |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always select CloudWatch metric filter + alarm when asked to trigger notifications on specific text patterns in logs.
Real World #
In some setups, you might supplement alerts with Lambda functions triggered by CloudWatch Logs subscriptions for complex processing. But for straightforward “ERROR” alerts, metric filters with alarms are the simplest and most reliable.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the DVA-C02 exam.