DOP-C02 SNS Subscription Confirmation Practice Question
Network Topology
Refer to the exhibit. A DevOps engineer checks the CloudWatch alarm configuration and state. The alarm is in ALARM state for CPUUtilization averaging 90% over 5 minutes, but no notification was received. What is the most likely reason?
⚠ Common exam trap
DOP-C02 often tests the assumption that an alarm in ALARM state automatically sends notifications, ignoring that SNS subscriptions must be confirmed and that alarm actions can be disabled or misconfigured.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The SNS topic does not have any confirmed subscriptions.
A CloudWatch alarm in ALARM state triggers its configured actions, typically publishing to an SNS topic. If no notification is received, the most likely cause is that the SNS topic has no confirmed subscriptions—meaning no endpoint (email, SMS, Lambda, etc.) has completed the subscription confirmation handshake. Without a confirmed subscription, SNS accepts the publish but delivers to no one, so the alarm fires silently. This is a common operational oversight.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The SNS topic does not have any confirmed subscriptions.
Why this is correct
CloudWatch alarm actions publish notifications to the configured SNS topic, but the publish operation only succeeds if the topic has at least one active, confirmed subscriber endpoint, such as an email address that has clicked the confirmation link. When subscriptions are still in PendingConfirmation state or no subscription exists, the message is silently dropped while the alarm continues to show ALARM. Therefore, even though the alarm is firing correctly, no notification reaches the engineer because the delivery path lacks a confirmed subscriber. This is the root cause.
- ✗
The EC2 instance is stopped.
Why it's wrong here
If the instance were stopped, CloudWatch would stop receiving CPU utilization data for that instance, causing the alarm to transition to INSUFFICIENT_DATA rather than ALARM. Because the exhibit shows the alarm in ALARM state, the instance must be running and emitting CPU metrics that have breached the configured threshold. Hence, the stopped-instance hypothesis contradicts the observed alarm state and cannot explain the missing notification.
- ✗
The alarm period is set to 300 seconds, which is too long.
Why it's wrong here
The period of 300 seconds (5 minutes) is a standard and fully supported evaluation window for EC2 CPU alarms; it simply defines how often the alarm evaluates the metric aggregation. A longer period does not suppress notifications—CloudWatch sends an alarm action the moment the state transitions to ALARM regardless of the period. Notifications would still be emitted at the next evaluation after the threshold breach, so the period length is not responsible for the failure to receive an alert.
- ✗
The alarm has insufficient data to evaluate.
Why it's wrong here
An alarm with insufficient data points shows the state INSUFFICIENT_DATA, not ALARM; the exhibit explicitly indicates the alarm is in ALARM. That state means CloudWatch has collected enough data during the evaluation period to compare against the threshold and found the metric breaching it. Therefore, insufficient data is demonstrably false as an explanation for the missing notification.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 1,298 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.