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.

• ✗

  Use Amazon Simple Email Service (SES) to send emails on stack failure.

  Why it's wrong here

  Amazon Simple Email Service (SES) is a service for sending email, but CloudFormation does not support SES as a direct notification target. Stack event notifications are delivered to SNS topics that you specify, and those topics can have email subscribers. To use SES, you would need to build a separate Lambda function to fetch the event from SNS and send it via SES, which is additional complexity. This is not a native CloudFormation integration, so it is incorrect for responding to stack failures.

• ✓

  Specify an SNS topic ARN in the 'NotificationARNs' parameter of the stack.

  Why this is correct

  CloudFormation provides a native push-based notification mechanism through the 'NotificationARNs' property of a stack. When you create or update a stack, you can supply up to five Amazon SNS topic ARNs, and CloudFormation automatically publishes all stack events—including failure states like CREATE_FAILED—to those topics. Subscribers such as email, SMS, or Lambda receive the notification immediately without any custom code. This is the simplest and most reliable way to be alerted on stack failure.

• ✗

  Create a Lambda function that polls the CloudFormation API for stack status changes.

  Why it's wrong here

  Writing a Lambda function that periodically polls the CloudFormation API for status changes is an anti-pattern because it requires a separate scheduler (such as an Amazon CloudWatch Events rule) to invoke the function, adds latency between the failure event and the notification, and incurs additional API call costs as you poll repeatedly. CloudFormation already offers a push-based SNS notification mechanism that is immediate and serverless. A custom polling loop is inefficient, error-prone, and not the recommended AWS native approach.

• ✗

  Enable CloudTrail and create a metric filter for 'CreateStack' events.

  Why it's wrong here

  CloudTrail records the CreateStack API call itself, but that log entry is generated when the request is received, not when the stack reaches a final status like CREATE_FAILED or CREATE_COMPLETE. A metric filter applied to CreateStack events would trigger on every stack creation attempt, regardless of outcome, and would not provide information about the actual result. CloudFormation status changes are emitted as stack events and are not captured as separate CloudTrail events, so this method cannot be used to reliably detect stack creation failure.

Go deeper

Related to this question