Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For AWS DVA-C02 candidates, the confusion often lies in understanding the distinction between metrics logging and event auditing services. In production, this is about knowing exactly which AWS service tracks real-time performance metrics versus which service logs API activity. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
BrightCart, an emerging online retail platform, is gearing up for a flash sale expected to spike application load drastically. The development team needs a reliable way to immediately alert them when the CPU usage on their EC2 fleet surges beyond a critical threshold during the event.
The Requirement: #
Implement a monitoring solution to notify the team when an EC2 instance’s CPU utilization exceeds 80% to promptly address potential performance bottlenecks.
The Options #
- A) Create a custom Amazon CloudWatch alarm that sends a notification to an Amazon SNS topic when the CPU utilization exceeds 80%.
- B) Create a custom AWS CloudTrail alarm that sends a notification to an Amazon SNS topic when the CPU utilization exceeds 80%.
- C) Create a cron job on the EC2 instance that invokes the
--describe-instance-informationcommand every 15 minutes and sends the results to an Amazon SNS topic. - D) Create an AWS Lambda function that queries the AWS CloudTrail logs for the CPUUtilization metric every 15 minutes and sends a notification to an Amazon SNS topic when the CPU utilization exceeds 80%.
Google adsense #
leave a comment:
Correct Answer #
A
Quick Insight: The Developer Imperative #
CloudWatch provides native, near real-time metrics monitoring for EC2 performance, making it the definitive source for CPU utilization alerts. CloudTrail, by contrast, logs API calls and user activity — it does not track metrics like CPU usage. Reliance on polling CloudTrail or custom scripts adds complexity and latency, which can delay critical alerts during spikes.
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 provides direct, continuous monitoring of EC2 metrics such as CPUUtilization. Setting a CloudWatch alarm with a threshold at 80% CPU allows automatic, near real-time triggers. These alarms can publish notifications directly to an SNS topic, enabling rapid team alerts via email or SMS. This design uses managed services optimized for monitoring without custom polling or complex parsing of logs.
- The
CPUUtilizationmetric is collected and updated every minute by CloudWatch. - CloudTrail logs API activity, not performance metrics, so it cannot trigger alerts on CPU usage.
- Running periodic cron jobs on the instance itself increases operational overhead and is vulnerable to instance failures.
- Using a Lambda to query CloudTrail log events for metrics is both ineffective (metrics aren’t in CloudTrail) and introduces delay and cost.
The Trap (Distractor Analysis) #
-
Why not B?
CloudTrail records API calls (who did what and when), but it does not collect or store performance metrics like CPU usage. Using CloudTrail to monitor CPU utilization is conceptually incorrect. -
Why not C?
Running a cron job inside the EC2 instance to poll instance info is inefficient, error-prone, and delivers delayed alerts, especially if the instance is unhealthy or non-responsive. -
Why not D?
Lambda querying CloudTrail logs every 15 minutes is indirect and ineffective; CloudTrail logs do not contain performance metrics, so this method cannot detect CPU spikes accurately or timely.
The Technical Blueprint #
# Example CLI to create a CloudWatch alarm that triggers SNS notification when CPU utilization > 80%
aws cloudwatch put-metric-alarm \
--alarm-name "HighCPUUtilization" \
--metric-name CPUUtilization \
--namespace AWS/EC2 \
--statistic Average \
--period 60 \
--threshold 80 \
--comparison-operator GreaterThanThreshold \
--dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
--evaluation-periods 1 \
--alarm-actions arn:aws:sns:us-east-1:123456789012:MySNSTopic \
--unit Percent
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Low: Native CloudWatch alarm setup | Near real-time alerting | Standard EC2 resource monitoring |
| B | Medium: Setup custom CloudTrail alarm | Poor: CloudTrail not metric-based | Incorrect for performance metrics |
| C | High: Custom cron job + SNS integration | Delayed; dependent on instance health | Fragile, not scalable |
| D | High: Lambda querying logs | Delayed; costly & indirect | Inefficient & inaccurate |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick CloudWatch alarms when you see metric-based threshold monitoring requirements, especially with EC2 performance metrics.
Real World #
In production, CloudWatch alarms integrated with SNS or AWS Chatbot enable near-real-time notifications and automated remediation workflows (via Lambda or Systems Manager), ensuring the team can react swiftly to resource stress during key events.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.