DOP-C02 Monitoring and Logging 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.

• ✗

  Create an Amazon EventBridge rule that matches CloudFormation resource limit exceeded events and sends to SQS.

  Why it's wrong here

  EventBridge does not emit a distinct `resource limit exceeded` event from CloudFormation; it only publishes generic stack events such as `CREATE_FAILED` without a dedicated detail field for quota violations. The correct approach would instead monitor `CREATE_FAILED` events in EventBridge and then inspect the status reason to identify limit errors. This option is tempting because EventBridge can capture CloudFormation lifecycle events and SQS provides reliable decoupling, which would work if the specific event type existed—but it does not, so the rule never triggers for this failure mode.

• ✓

  Configure an SNS topic as a notification option in the CloudFormation stack, and subscribe an email endpoint.

  Why this is correct

  CloudFormation natively supports an SNS topic as a stack notification option: when you specify an SNS topic ARN in the stack's NotificationARNs property, CloudFormation publishes every stack event—such as CREATE_FAILED and ROLLBACK_COMPLETE—to that topic. Subscribing an email endpoint to the topic delivers these events in near real time, giving operations teams immediate insight into resource limit failures or any other stack error. This is the only answer that directly leverages CloudFormation's built-in notification channel without needing extra services to infer failure.

• ✗

  Use AWS Config to detect when a stack is in a failed state.

  Why it's wrong here

  AWS Config is a service for recording and evaluating the configuration of individual AWS resources against compliance rules, not for monitoring CloudFormation stack lifecycle states. While AWS Config can record an AWS::CloudFormation::Stack resource, it only captures the stack's current template and parameters, not transient operational statuses like CREATE_FAILED or the stack's failure reason. AWS Config does not emit stack failure events or alarms, so it cannot be used to detect a failed stack for notification purposes.

• ✗

  Enable CloudTrail and create a CloudWatch alarm on the CreateStack API call.

  Why it's wrong here

  CloudTrail logs API calls such as CreateStack, but that API call only represents the submission of the stack creation request—it does not indicate whether the stack subsequently succeeded or failed. A CloudWatch alarm on the CreateStack API call would fire for every stack launch, including fully successful ones, and would completely miss resource limit failures that occur asynchronously after the request. CloudTrail events do not contain the stack execution result; you would need to combine them with CloudWatch Logs metric filters and still lack the lifecycle failure information.

Go deeper

Related to this question