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 a CloudWatch Events rule that matches CloudFormation 'CREATE_FAILED' stack events and targets an SNS topic.

  Why this is correct

  CloudFormation emits stack status change events to CloudWatch Events (Amazon EventBridge) whenever a stack transitions to a terminal state. A rule can filter for detail-type 'CloudFormation Stack Status Change' and the 'status-detail' of 'CREATE_FAILED', then route the event to an SNS topic. This is the native, event-driven mechanism for receiving notifications about stack creation failures, and it includes the stack name and status in the event payload.

• ✗

  Use AWS Config rules to detect failed stack creations.

  Why it's wrong here

  AWS Config is a service for assessing resource configuration compliance against rules, not for observing CloudFormation operation lifecycle. It can detect that a provisioned resource violates a rule, but it has no visibility into the outcome of a stack creation or the CREATE_FAILED status emitted by CloudFormation. Moreover, a failed stack may never produce all resources or may leave partial resources, so Config cannot reliably signal the failure event itself. For real-time notification of a stack failure, you need an event-driven integration.

• ✗

  Enable CloudTrail and create a metric filter for 'CreateStack' API calls.

  Why it's wrong here

  CloudTrail records the 'CreateStack' API call at the moment a user requests stack creation, which only indicates that the request was accepted, not whether the stack subsequently reached 'CREATE_COMPLETE' or 'CREATE_FAILED'. The failure status is an asynchronous stack event that occurs later, so a metric filter on the CreateStack API call would over-report creations and miss the actual failure signal. CloudTrail alone cannot be used to trigger on the final stack status; you need CloudWatch Events for the status change.

• ✗

  Stream CloudFormation logs to CloudWatch Logs and create a metric filter for 'CREATE_FAILED'.

  Why it's wrong here

  CloudFormation does not automatically stream its stack events or logs to CloudWatch Logs; stack events are published to CloudWatch Events/EventBridge, not to a log group. Without a log stream containing 'CREATE_FAILED' entries, a metric filter has nothing to match. While you could technically create a custom mechanism to forward CloudFormation events to logs, the native and simpler integration is an EventBridge rule targeting SNS. This option is incorrect because it relies on a non-existent default logging behavior.

Go deeper

Related to this question