Custom metrics, metric filters and alarms: DOP-C02 study notes and practice questions
What to know about Custom metrics, metric filters and alarms for the DOP-C02 exam, from the Monitoring and Logging domain (15% of the exam guide), then 3 free questions to test it. Part of the DOP-C02 study guide.
These questions ask how to measure something AWS doesn’t publish, or alarm without noise.
Getting metrics
Custom metrics with PutMetricData, or the embedded metric format (EMF): structured JSON logs that CloudWatch turns into metrics automatically, ideal for Lambda.
Metric filters turn matching log lines into metrics without changing the app.
High-resolution metrics (down to 1 second) for fast detection.
Dimensions split metrics (such as by service or customer tier).
Alarm design
Feature
Use
Metric math
Alarm on a calculation, such as error percentage = errors ÷ requests × 100
M out of N datapoints
Require several breaching periods so one bad minute doesn’t page
Anomaly detection
Alarm on a band learned from history, for metrics with daily patterns
Composite alarms
Combine alarms with AND, OR, NOT to cut noise, such as ALARM(latency) AND ALARM(errors); can suppress actions during maintenance
Metrics Insights queries
Alarm on a SQL query across many resources
Missing data
Treat missing data as missing, notBreaching, breaching or ignore. For a job that must report every day, breaching turns “nothing published” into an alarm.
Actions
SNS notifications, Auto Scaling policies, EC2 actions (stop, terminate, reboot, recover), Systems Manager OpsItems or incidents, and Lambda directly.
Alarm state changes are EventBridge events for richer automation.
Common traps
Changing log formats to get a metric. Use a metric filter.
Alarms on every single error, paging on noise.
Static thresholds on traffic with strong daily cycles.
Alarms that never fire for jobs that never ran, because missing data was left as missing.
A logistics company's delivery-tracking service writes one log line per failed delivery attempt to a CloudWatch Logs log group. Dispatchers need an alarm when failed attempts exceed 100 in any five-minute period.
The alarm must go to the on-call channel through SNS, and the service's log format should not change, because other teams read the same lines.
The team wants the alarm built with standard CloudWatch features and no custom monitoring code. The alarm should return to OK on its own once the failures drop.
Which approach meets these requirements?
Choose one answer.
AA. Create a metric filter on the log group that matches failed-attempt lines and publishes a count metric, then create an alarm with a five-minute period and a threshold of 100 that notifies SNS.
BB. Create a CloudWatch Logs Insights query that counts failed attempts and run it every five minutes with a scheduled task, and have the task send a message to SNS when the count is over 100.
CC. Create an alarm on the EC2 CPUUtilization metric for the instances that run the tracking service, because heavy failure rates usually raise CPU use.
DD. Change the service to emit a custom metric through the CloudWatch agent for each failed attempt, and alarm on that metric, while leaving the log group unchanged.
Show the answer and explanation
Answer: A
A. Right: Correct. A metric filter turns matching log lines into a CloudWatch metric without changing the log format, and the alarm evaluates the count over five minutes. The alarm action publishes to the SNS topic for the on-call channel. Learn more: Creating metrics from log events using filters (opens in a new tab)
A metric filter converts matching log lines into a CloudWatch metric, so the existing log format stays the same. An alarm on that metric with a five-minute period and a threshold of 100 can notify SNS directly. Scheduled Logs Insights queries, CPU alarms and changes to the service each add code or miss the failed-attempt count.
An online retailer runs its checkout API behind an Application Load Balancer. The team has a metric for successful checkout responses and a metric for failed responses, both published once per minute.
The on-call team wants a page when the checkout error rate exceeds 2 percent for five minutes, and a separate, quieter notification when latency is high but the error rate is normal. The page must not fire on a single bad minute, and the team does not want to maintain any Lambda functions for the alarms.
Which TWO actions meet these requirements? (Choose two.)
Choose two answers.
AA. Create one alarm on the p99 latency statistic of the load balancer's response time, and send it to the same paging topic as the error alarm so that each slow request pages on-call.
BB. Create one alarm for each target instance on its own failed-response count, and page on-call when any instance's alarm turns into ALARM state.
CC. Create an alarm that uses metric math to divide the failed-response count by the sum of both counts, times 100, and alarm when that expression stays above 2 for five consecutive one-minute periods.
DD. Create a Logs Insights query that computes the error rate every minute and a scheduled rule that starts an SNS notification whenever the query returns a result over 2 percent.
EE. Create a composite alarm with the rule ALARM(latency) AND NOT ALARM(error-rate), and route it to the quieter channel, while the error-rate alarm itself notifies the paging topic.
Show the answer and explanation
Answers: C, E
A. Wrong: A single slow request should not page on-call, and the latency alarm would page on every slow period. Sending it to the paging topic also removes the quieter notification the team asked for. Learn more: Using Amazon CloudWatch alarms (opens in a new tab)
C. Right: Correct. A metric math expression can compute the error percentage from the two metrics, and the datapoints-to-alarm setting requires five breaching minutes. The alarm therefore ignores a single bad minute. Learn more: Math expressions with metrics (opens in a new tab)
E. Right: Correct. The composite alarm goes into ALARM only when latency is high and the error-rate alarm is not firing, so it drives the quieter notification. The error-rate alarm pages on its own, so a real checkout failure always pages. Learn more: Composite alarms (opens in a new tab)
Explanation
A metric math alarm can compute the error percentage from the two metrics and require several consecutive breaching periods, so one bad minute does not page. A composite alarm with the rule ALARM(latency) AND NOT ALARM(error-rate) sends the quieter notification only when latency is the sole problem. Per-instance alarms, latency-only paging and scheduled Logs Insights queries each miss a requirement.
A regional bank runs a nightly reconciliation batch job on EC2. The job publishes a custom metric named ReconciledAccounts once when it completes, and the bank expects it to finish every night before 6 a.m.
If the job fails or never starts, the metric is not published at all. The operations team wants an alarm that goes to ALARM when no successful completion appears in a 24-hour period, and does not stay in an OK state simply because no data arrived.
The team wants to keep the alarm simple and avoid any extra monitoring code.
Which alarm configuration meets these requirements?
Choose one answer.
AA. Set the alarm's Treat missing data setting to ignore, with a 24-hour period and a threshold of zero, so that the alarm checks only the periods in which the job publishes.
BB. Replace the custom metric with a Logs Insights query that counts completion lines, and run that query from a scheduled rule every 24 hours to send an alert when the count is zero.
CC. Create an anomaly detection alarm on the ReconciledAccounts metric with a band of two standard deviations, and let the band learn the normal daily pattern.
DD. Use the SampleCount statistic over 24 hours with LessThanThreshold and a threshold of 1, and set Treat missing data to breaching.
D. Right: Correct. Treating missing data as breaching turns a period with no published completion into an ALARM state, which is the outcome the bank wants. A SampleCount below 1 over 24 hours also catches a period with no datapoints, whatever value the job reports. Learn more: Configuring how CloudWatch alarms treat missing data (opens in a new tab)
Explanation
Treating missing data as breaching turns a period without any published metric into an ALARM state, so an unfinished or never-started batch job is reported. A 24-hour SampleCount with a LessThanThreshold operator and a threshold of 1 fits a metric published once per night. Ignored missing data, scheduled queries and anomaly detection each miss the case where the metric is absent.
Want more on Custom metrics, metric filters and alarms? The 5 full-length practice sets have 14 more Custom metrics, metric filters and alarms questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →