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.

• ✗

  Enable CloudTrail and create a metric filter for 'UpdateStack' events, then set an alarm.

  Why it's wrong here

  CloudTrail is an audit service that records API calls, but it does not provide real-time notifications about stack status. A metric filter for 'UpdateStack' events would merely indicate that an UpdateStack API call occurred, not whether that update failed or succeeded. Additionally, CloudTrail logs are delivered to S3 or CloudWatch Logs with latency, and alarms on these logs require creating a metric filter and a CloudWatch alarm, which is indirect and does not capture stack failure events specifically. This approach adds complexity and still relies on the API call rather than the actual stack lifecycle event that indicates failure.

• ✗

  Write a script that periodically checks the CloudFormation console for stack status and sends an email.

  Why it's wrong here

  This approach is manual and inefficient because the CloudFormation console is a graphical interface, and there is no built-in API to 'check the console' directly. A script would need to poll the DescribeStacks API repeatedly, which introduces latency, unnecessary API calls, and potential throttling risks. Moreover, this polling method can only capture the stack status at the moment of each check, so transient failures or specific lifecycle events could be missed between polls. It also requires you to implement scheduling, email delivery, and error handling yourself, making it far less reliable than using CloudFormation's native notification mechanism.

• ✗

  Create an Amazon EventBridge rule that matches CloudFormation events and triggers a Lambda function to send an SNS notification.

  Why it's wrong here

  An EventBridge rule can match CloudFormation API calls or lifecycle events and invoke a Lambda function to send SNS notifications, and this approach would technically work. However, it is overly complex compared to CloudFormation's built-in notification option, which directly sends stack events to an SNS topic with no intermediate components. To implement this, you must create an EventBridge rule with the correct event pattern, a Lambda function with execution role and error handling, and an SNS topic, while also managing potential duplicate notifications and invocation delays. Native stack notifications are simpler, more reliable, and specifically designed for this use case, making the EventBridge+Lambda setup unnecessary complexity for a basic failure alerting requirement.

• ✓

  Configure an SNS topic in the CloudFormation stack's notification options.

  Why this is correct

  CloudFormation natively supports sending stack lifecycle events (such as stack creation, update, and delete failures) directly to an Amazon SNS topic through the stack's notification options. When you create a stack, you can specify one or more SNS topic ARNs in the 'NotificationARNs' property, and CloudFormation publishes all stack events to those topics in real-time. For example, a 'CREATE_FAILED' or 'UPDATE_FAILED' event triggers a notification that is delivered to the SNS topic, and subscribers (such as email or Lambda) receive it immediately. This is the simplest, most direct, and most reliable way to get notified of stack failures, as it requires no additional services or custom scripting.

Go deeper

Related to this question