SOA-C02 Monitoring, Logging, and Remediation Practice Question

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 alarm's evaluation period is too short.

  Why it's wrong here

  The evaluation period determines how many consecutive data points must breach the threshold before the alarm transitions to ALARM. A shorter evaluation period could cause the alarm to trigger more quickly, but once triggered, the notification action is executed identically regardless of the period length. Delivery of the email depends entirely on the SNS subscription state, not on how the alarm's state changed. Therefore, an evaluation period that is too short would affect the timing of the alarm state, not the delivery path, so it does not explain missing emails.

• ✓

  The email subscription to the SNS topic has not been confirmed.

  Why this is correct

  For SNS email subscriptions, the subscriber must confirm the subscription by clicking the link in the initial confirmation message that Amazon SNS sends to the email address. Until that confirmation is completed, the subscription remains in the 'Pending Confirmation' state and Amazon SNS will not deliver messages published to the topic, even if the CloudWatch alarm successfully executes its action. This is a common and often overlooked cause of missing email notifications, and it directly explains the symptom described in the question.

• ✗

  The alarm's actions are not configured to send to the SNS topic.

  Why it's wrong here

  CloudWatch alarm actions are the configured notifications or automatic operations that run when the alarm changes state. If no action is attached or if the action points to a different SNS topic, the alarm would not publish at all, so no notification would be sent from that alarm. However, the question implies the alarm configuration is correct and the alarm is indeed entering ALARM; otherwise, the administrator would be troubleshooting why the alarm did not trigger. Since the alarm is likely publishing to the topic, the misconfiguration is not the root cause; the issue lies downstream in the SNS subscription itself.

• ✗

  The SNS topic is encrypted with a KMS key that the alarm does not have permissions to use.

  Why it's wrong here

  SNS topics can be encrypted with an AWS KMS customer-managed key, and the key policy must grant the SNS service permission to use that key for encryption and decryption. The CloudWatch alarm does not directly call KMS; it simply publishes to the SNS topic, and SNS performs the KMS operations using its own service-linked permissions. If the key policy were incorrect, SNS would reject the publish operation, and CloudWatch would record a failure in its action history—but this would affect all delivery protocols, not just email. Therefore, the alarm does not have separate KMS permissions to lack, and an encryption issue would not selectively block email messages.

Go deeper

Related to this question