Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Site Reliability Engineer.
For SOA-C02 candidates, the confusion often lies in understanding the difference between CloudWatch Alarms on metrics versus EventBridge events for Lambda errors. In production, this is about knowing exactly how to trigger immediate developer notifications with minimal latency and reliable filtering on errors. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
At Streamline CloudOps, the Site Reliability Engineering (SRE) team needs to implement an automated alerting system that instantly notifies the software development team whenever any AWS Lambda function experiences a failure. The notification mechanism must use AWS native services and provide scalable, real-time alerts without unnecessary delays or manual polling.
The Requirement: #
Create a robust, operationally sound solution to immediately inform developers upon Lambda function errors.
The Options #
-
A) Create an Amazon SNS topic with email subscriptions for each developer. Configure an Amazon CloudWatch alarm that monitors the Lambda error metric filtered by function name as a dimension. Set the alarm to notify the SNS topic when it enters an ALARM state.
-
B) Create an Amazon SNS topic with mobile push subscriptions for each developer. Set up an Amazon EventBridge rule using the
LambdaErrorevent pattern filtered by SNS topic name as the resource. Configure the rule to send notifications to the SNS topic when matched. -
C) Verify each developer’s email address in Amazon SES. Create a CloudWatch rule monitoring the
LambdaErrormetric with developer email addresses as dimensions. Configure the rule to send email notifications through SES when in ALARM state. -
D) Verify each developer’s phone number in Amazon SES. Create an EventBridge rule using an
Errorevent pattern filtered by Lambda function name as the resource. Configure the rule to send push notifications through SES when triggered.
Google adsense #
leave a comment:
Correct Answer #
A.
Quick Insight: The SysOps Engineer’s Imperative #
- Events such as Lambda errors trigger CloudWatch metrics; using CloudWatch Alarms with SNS email subscriptions is the most straightforward and proven approach for immediate, reliable notifications.
- EventBridge event patterns and SNS integrations are powerful but using LambdaError with SNS topic as a resource filter is not correct API usage here.
- SES is not designed for direct real-time alerts triggered by metrics or event rules and requires complex validation; it’s best suited for bulk, transactional email, not push notifications.
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 Lambda metrics such as
Errorsautomatically track failure counts per function, with function name exposed as a dimension. - You can create a CloudWatch alarm directly on the
Errorsmetric filtered by function name. - When the alarm state changes to ALARM (meaning error rate threshold breached), it can trigger an SNS topic.
- SNS can fan out notifications via email subscriptions to multiple developers, ensuring immediate, direct communication.
- This is the well-documented and supported approach for real-time operational alerts on Lambda failures.
The Trap (Distractor Analysis) #
-
Why not B?
EventBridge event pattern rules for Lambda function errors do not use SNS topic name as a resource filter; this is an invalid filter reference. Also, mobile push subscriptions add unnecessary complexity for simple error email alerts. -
Why not C?
CloudWatch rules do not support complex filtering by developer email as a dimension. SES is for sending validated bulk or transactional emails but is not automatically triggered by metric alarms directly. This adds complexity and latency. -
Why not D?
SES does not send push notifications. Phone number validation and push notification semantics are handled by SNS Mobile Push or other services, not SES. EventBridge error event filtering does not operate as described here for Lambda.
The Technical Blueprint #
SysOps CLI snippet: Creating CloudWatch Alarm with SNS notification #
aws cloudwatch put-metric-alarm \
--alarm-name "LambdaErrorAlarm" \
--metric-name Errors \
--namespace AWS/Lambda \
--statistic Sum \
--period 60 \
--threshold 1 \
--comparison-operator GreaterThanOrEqualToThreshold \
--dimensions Name=FunctionName,Value=MyLambdaFunction \
--evaluation-periods 1 \
--alarm-actions arn:aws:sns:us-east-1:123456789012:DevelopersSNS
The Comparative Analysis (SysOps Perspective) #
| Option | Operational Overhead | Automation Level | Impact |
|---|---|---|---|
| A | Low — leverages standard CloudWatch alarms and SNS | High — direct alarm notifications | Immediate developer email alerts |
| B | Medium — uses EventBridge rule but misconfigured resource filtering | Medium — depends on developer mobile subscriptions | Risky due to incorrect event filter usage |
| C | High — SES validation required for each email, metric filtering incorrect | Low — misuses CloudWatch rules for metric alarms | Complex, slower notifications |
| D | High — SES cannot send push notifications, phone number validation overhead | Low | Not feasible with SES push; improper event pattern usage |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick CloudWatch alarms + SNS email when you see Lambda errors requiring immediate developer notification.
Real World #
In production, you might add advanced routing via EventBridge for more complex workflows, or integrate SNS with chat tools like Slack or PagerDuty for enhanced incident response. Still, the backbone is CloudWatch metric alarms triggering SNS notifications.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the SOA-C02 exam.