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.

• ✓

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

  Why this is correct

  Configuring an SNS topic in the stack's notification options is the native CloudFormation mechanism for sending stack lifecycle events (e.g., CREATE_COMPLETE, UPDATE_FAILED, DELETE_IN_PROGRESS) to a pub/sub channel. You simply provide the topic ARN (up to five) when you create or update the stack, and CloudFormation publishes every stack event to it without requiring any Lambda code, custom resources, or additional infrastructure. This is the simplest and most direct way to get notified about stack changes.

• ✗

  Create a custom resource in the stack that publishes to Amazon SNS.

  Why it's wrong here

  Creating a custom resource that publishes to Amazon SNS is an unnecessarily complex workaround: it requires a Lambda-backed custom resource whose lifecycle occurs at a specific point during stack operations, and it only captures events at that single invariant rather than the full stream of stack-level events. Moreover, custom resources depend on Lambda function execution, IAM roles, and error handling, and they add cost and failure points. CloudFormation's built-in notification options already deliver SNS messages for all stack events, so a custom resource is redundant.

• ✗

  Create a CloudWatch alarm on the StackStatus metric.

  Why it's wrong here

  CloudWatch alarms watch numeric metrics (e.g., CPUUtilization, ErrorCount) emitted by services; CloudFormation does not emit a metric named StackStatus at all. Stack status is returned as a string field via the DescribeStacks API, not exposed as time-series data, so you cannot create an alarm on it. You could use a custom script or EventBridge rule to translate status changes, but a CloudWatch alarm on StackStatus is not a valid, supported configuration.

• ✗

  Use Amazon EventBridge to capture CloudFormation events and publish to SNS.

  Why it's wrong here

  While EventBridge can capture CloudFormation API events (e.g., via the AWS CloudFormation event source) and route them with a rule to an SNS target, this requires you to design an event pattern, configure a rule, and manage IAM permissions — and it typically captures resource-level CloudFormation events rather than the exact stack-level notification stream that native stack notifications provide. It's a viable automation path, but for the stated need (just get notified on stack events) it is more complex than simply specifying an SNS topic in the stack's notification options. The built-in integration is purpose-built, requires no rules, and is the most efficient choice.

Go deeper

Related to this question