SOA-C03 CloudWatch alarms: the missing-data setting that decides whether you get paged

Youss El — Wed, 04 Nov 2026 07:53:14 +0000

"An alarm on a metric that only reports data when something goes wrong never leaves the INSUFFICIENT_DATA state. How do you fix it?"

Monitoring is a core part of the AWS Certified CloudOps Engineer – Associate exam (SOA-C03, the renamed SysOps Administrator Associate). It's 65 questions in 130 minutes, according to the official exam page, and CloudWatch alarm behavior is the kind of detail operations questions are built around. Here's the part that trips people up most: what an alarm does when data is missing.

The three states

A metric alarm is always in one of these states (alarm evaluation docs):

OK: the metric is within the threshold.
ALARM: the metric is outside the threshold.
INSUFFICIENT_DATA: the alarm has just started, the metric isn't available, or there isn't enough data to decide.

An alarm only invokes its actions when it changes state (the exception is Auto Scaling actions, which repeat once per minute while the alarm stays in the new state).

Three settings that control evaluation

Period: how long each data point covers.
Evaluation Periods (N): how many of the most recent data points are looked at.
Datapoints to Alarm (M): how many of those must be breaching. They don't have to be consecutive.

If M and N differ, you have an "M out of N" alarm. For example, 4 out of 5 with a 1-minute period has an evaluation interval of 5 minutes.

Treat missing data: four options

Not every data point always arrives: a connection drops, a server goes down, or a metric reports only when something happens. For each alarm you choose how to treat those gaps (missing data docs):

Option	Missing data points are treated as...
`notBreaching`	Good, within the threshold
`breaching`	Bad, violating the threshold
`ignore`	Nothing: the current alarm state is kept
`missing`	Missing: if all data points in the range are missing, the alarm goes to `INSUFFICIENT_DATA`

The default is missing.

When does each make sense? AWS gives two examples:

A rollback alarm on a metric that continually reports data: missing data probably means something is wrong, so use breaching.
A metric that only produces data when an error occurs, such as ThrottledRequests in DynamoDB: no data means no errors, so use notBreaching.

Two more details worth knowing: alarms on AWS/DynamoDB metrics default to ignore, and for EC2 alarms that stop, terminate, reboot or recover an instance, AWS recommends treating missing data as missing and triggering the action only from the ALARM state, because EC2 metrics can briefly go missing even for a healthy instance.

What the alarm does with all-missing data

Say Datapoints to Alarm and Evaluation Periods are both 3, and the five most recent data points are all missing. The result depends only on the setting:

Setting	Resulting state
`missing`	`INSUFFICIENT_DATA`
`ignore`	Keeps the current state
`breaching`	`ALARM`
`notBreaching`	`OK`

If at least as many real data points exist as Evaluation Periods, CloudWatch just evaluates those real points and the missing-data setting isn't used at all.

Trap: alarm noise and composite alarms

Too many alarms paging you for the same incident? A composite alarm combines the states of other alarms with a rule expression, so you can alert only on the composite. Composite alarms can send SNS notifications and create investigations, Systems Manager OpsItems or incidents, but they can't perform EC2 or Auto Scaling actions.

Trap: the alarm that never fires fast enough

The evaluation window is Period × Evaluation Periods. For periods of one minute or longer, the alarm is evaluated every minute. An alarm with a very long evaluation window reacts slowly: if the window exceeds one day, it's only evaluated once per hour. If a question asks why a daily-job alarm took an hour to react, that's the reason.

A sample question

An application publishes a custom metric FailedPayments only when a payment fails. A CloudWatch alarm on it stays in INSUFFICIENT_DATA for days, and the on-call team can't tell whether things are healthy. What should the CloudOps engineer do?

A. Increase the alarm period to 24 hours.
B. Set the alarm to treat missing data as notBreaching.
C. Set the alarm to treat missing data as breaching.
D. Replace the alarm with a composite alarm.

Answer: B. The metric only exists when failures happen, so a gap means "no failures". notBreaching keeps the alarm in OK during those gaps. breaching would page the team whenever payments are healthy. A longer period doesn't change how gaps are treated, and a composite alarm just combines other alarms.

Checklist before exam day

Three states: OK, ALARM, INSUFFICIENT_DATA.
Know Period, Evaluation Periods and Datapoints to Alarm, and what "M out of N" means.
Four missing-data options, and the default is missing.
Metric only reports on errors → notBreaching. Metric should always report → breaching.
Actions fire on state changes, not on every evaluation.
Composite alarms reduce noise but can't run EC2 or Auto Scaling actions.

Good luck with SOA-C03.

Disclosure: I wrote 2 SOA-C03 practice exams (130 scenario questions with an explanation for every option). $34.99 until Dec 4: https://www.udemy.com/course/aws-cloudops-engineer-associate-soa-c03-2-practice-exams/?couponCode=SOAC03LAUNCH. Not affiliated with or endorsed by AWS.

DEV Community: Youss El