Skip to main content

AWS DVA-C02 Drill: CloudWatch Logs Filtering - Real-Time Error Notifications

Jeff Taakey
Author
Jeff Taakey
21+ Year Enterprise Architect | AWS SAA/SAP & Multi-Cloud Expert.

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.

The DevPro Network: Mission and Founder

A 21-Year Tech Leadership Journey

Jeff Taakey has driven complex systems for over two decades, serving in pivotal roles as an Architect, Technical Director, and startup Co-founder/CTO.

He holds both an MBA degree and a Computer Science Master's degree from an English-speaking university in Hong Kong. His expertise is further backed by multiple international certifications including TOGAF, PMP, ITIL, and AWS SAA.

His experience spans diverse sectors and includes leading large, multidisciplinary teams (up to 86 people). He has also served as a Development Team Lead while cooperating with global teams spanning North America, Europe, and Asia-Pacific. He has spearheaded the design of an industry cloud platform. This work was often conducted within global Fortune 500 environments like IBM, Citi and Panasonic.

Following a recent Master’s degree from an English-speaking university in Hong Kong, he launched this platform to share advanced, practical technical knowledge with the global developer community.


About This Site: AWS.CertDevPro.com


AWS.CertDevPro.com focuses exclusively on mastering the Amazon Web Services ecosystem. We transform raw practice questions into strategic Decision Matrices. Led by Jeff Taakey (MBA & 21-year veteran of IBM/Citi), we provide the exclusive SAA and SAP Master Packs designed to move your cloud expertise from certification-ready to project-ready.