CloudWatch metrics, alarms and dashboards: SOA-C03 study notes and practice questions
What to know about CloudWatch metrics, alarms and dashboards for the SOA-C03 exam, from the Monitoring, Logging, Analysis, Remediation, and Performance Optimization domain (22% of the exam guide), then 3 free questions to test it. Part of the SOA-C03 study guide.
Alarm questions often start with an alarm that didn’t behave as expected. Knowing exactly how alarms evaluate is the key.
How an alarm evaluates
States: OK, ALARM, INSUFFICIENT_DATA.
Period, evaluation periods and datapoints to alarm: “3 out of 5” means the alarm fires when 3 of the last 5 periods breach. This avoids alarms on a single spike.
TreatMissingData decides what happens when data stops arriving: missing (the default; the alarm can go to INSUFFICIENT_DATA), notBreaching, breaching or ignore. For a metric that only reports when something happens (such as errors), notBreaching stops false INSUFFICIENT_DATA states; for a heartbeat that must keep arriving, breaching turns silence into an alarm.
Statistics: Average hides spikes; use Maximum or a percentile (p99) for latency.
Alarm features
Feature
Use
Composite alarm
Combine alarms with AND/OR/NOT to cut noise, such as “high errors AND high latency”
Metric math
Alarm on an expression, such as error rate = errors / requests
Anomaly detection
Alarm when a metric leaves its learned normal band, for seasonal patterns
Actions
Notify through SNS; EC2 actions (stop, terminate, reboot, recover); Auto Scaling actions; Systems Manager OpsItems or incidents
High-resolution metrics
Down to 1-second data and 10-second alarm periods for custom metrics
Metrics and dashboards
Basic monitoring sends EC2 metrics every 5 minutes; detailed monitoring every minute, at extra cost.
Custom metrics come from PutMetricData, the CloudWatch agent, or metric filters on log groups.
Dashboards can show metrics from other accounts and Regions with cross-account observability set up between a monitoring account and source accounts, without copying data.
Common traps
An alarm stuck in INSUFFICIENT_DATA for a sparse metric: change TreatMissingData, not the threshold.
Alarming on Average for latency. Spikes vanish; use p99 or Maximum.
Many single alarms paging people. Use a composite alarm for one meaningful signal.
A regional bank's online banking team has separate CloudWatch alarms on its Application Load Balancer for HTTP 5xx error count and for target response time. Each alarm notifies the on-call engineer through Amazon SNS.
Short spikes in one metric alone page the engineer several times a night, but every real outage so far has shown both metrics breaching together. The team wants one page only when both conditions are true at the same time.
What should a CloudOps engineer do?
Choose one answer.
AA. Raise the evaluation periods on both alarms to 10 so that brief spikes clear before either alarm reaches the ALARM state.
BB. Create a composite alarm that requires both alarms to be in ALARM at the same time, and send the SNS notification only from the composite alarm.
CC. Add an SNS subscription filter policy so that the engineer receives a message only when both alarms publish within the same minute.
DD. Replace both alarms with anomaly detection alarms so that the thresholds adapt to normal nightly traffic patterns automatically.
Show the answer and explanation
Answer: B
A. Wrong: More evaluation periods smooth out short spikes, but each alarm still pages on its own whenever it breaches. The engineer would also be paged later for real outages, which slows the response. Learn more: Alarm evaluation (opens in a new tab)
B. Right: Correct. A composite alarm evaluates the states of other alarms with AND, OR and NOT. With actions removed from the underlying alarms, only the composite alarm pages, and only when both conditions hold together. Learn more: Combining alarms (opens in a new tab)
D. Wrong: Anomaly detection builds a band of expected values for one metric. It can reduce false alarms on each metric, but the two alarms would still page separately rather than only when both breach. Learn more: Using CloudWatch anomaly detection (opens in a new tab)
Explanation
A composite alarm is the CloudWatch feature for alerting on a combination of conditions. Its rule expression, such as ALARM(errors) AND ALARM(latency), is evaluated against the states of the underlying alarms, and only the composite alarm needs actions. Tuning periods or thresholds on separate alarms reduces noise but never ties the two conditions together.
A ski resort runs a nightly lift-pass reconciliation job on Amazon EC2.
While it runs, the job publishes a custom CloudWatch metric, RecordsProcessed, every minute. If the job crashes, it stops publishing the metric completely. The operations team created an alarm on RecordsProcessed less than 1 for 5 consecutive periods, but when the job crashed last week the alarm stayed in INSUFFICIENT_DATA and nobody was notified.
Which change makes the alarm notify the team when the job stops publishing?
Choose one answer.
AA. Set the alarm's missing data treatment to notBreaching so that gaps in the metric are evaluated as normal data points.
BB. Set the alarm's missing data treatment to ignore so that the alarm keeps its last state until new data arrives.
CC. Set the alarm's missing data treatment to breaching so that every missing data point counts as below the threshold.
DD. Increase the alarm period from 1 minute to 1 hour so that at least one data point is always present in each period.
D. Wrong: A longer period does not create data when the job is not publishing. After a crash there are still no data points, so the alarm still lacks data to evaluate. Learn more: Alarm evaluation (opens in a new tab)
Explanation
When a metric disappears, the alarm's TreatMissingData setting decides what happens. The default, missing, leads to INSUFFICIENT_DATA when all points are absent. For a heartbeat-style metric where silence means failure, breaching is the right choice, because it turns the absence of data into an alarm.
An esports league runs its match services in six AWS accounts across two AWS Regions.
The operations lead wants one CloudWatch dashboard in a central monitoring account that shows metrics from all six accounts and both Regions side by side.
Security policy forbids long-term access keys, and the team does not want to copy metric data into a separate store.
Which TWO actions should a CloudOps engineer take? (Choose two.)
Choose two answers.
AA. In the monitoring account, turn on the cross-account cross-Region option in the CloudWatch settings so that dashboard widgets can select other accounts and Regions.
BB. Configure CloudWatch metric streams in every account and Region to deliver all metrics through Amazon Data Firehose into the monitoring account.
CC. Create an IAM user in each source account with read-only CloudWatch permissions and store its access keys in the monitoring account's dashboard settings.
DD. In each of the six source accounts, turn on sharing of CloudWatch data with the monitoring account, which creates a role that the monitoring account can assume.
EE. Use AWS Resource Access Manager to share the CloudWatch dashboards and metric namespaces of each source account with the monitoring account.
B. Wrong: Metric streams send metric data to a destination such as Firehose, which copies data into a separate store. That breaks the stated constraint and adds cost and setup in twelve places. Learn more: Use metric streams (opens in a new tab)
CloudWatch supports cross-account, cross-Region dashboards without moving data. The monitoring account turns on the cross-account cross-Region view, and each source account shares its CloudWatch data, which creates a role the monitoring account assumes. Access keys, metric streams and AWS RAM either break the constraints or do not apply.
Want more on CloudWatch metrics, alarms and dashboards? The 5 full-length practice sets have 12 more CloudWatch metrics, alarms and dashboards questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →