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 the CloudWatch alarms to publish to an SNS topic, and use SNS subscription filter policies to route only critical notifications.

  Why this is correct

  Publishing CloudWatch alarms to an SNS topic and applying subscription filter policies is a valid approach because SNS supports content-based filtering on message attributes. When an alarm transitions to ALARM state, it publishes a message with attributes like `state` and `severity`; each subscriber can define filter policies that match only their desired subset (e.g., `state = ALARM` with high severity). This effectively routes critical notifications to the right team while suppressing non-critical messages at the subscription level, without altering the alarm logic itself.

• ✗

  Use CloudWatch Evidently to run experiments and filter out false alarms.

  Why it's wrong here

  CloudWatch Evidently is an experimentation and feature-delivery service used for running A/B tests, launching feature flags, and rolling out new features safely. It has no capability to evaluate or filter CloudWatch alarm states, and it does not interact with alarm workflows or notification routing. Attempting to use it for false-alarm management is a category error; alert noise remediation belongs to alarm design (e.g., composite alarms), not experimentation tooling.

• ✓

  Use CloudWatch composite alarms to combine multiple alarms into a single alarm that triggers only when certain conditions are met.

  Why this is correct

  CloudWatch composite alarms combine multiple underlying alarms into a single alarm using Boolean expressions (AND, OR, NOT) across alarm states. For example, you can trigger a composite alarm only when both CPU utilization and error-rate alarms are in ALARM, which filters out single-metric spikes that do not represent a real outage. This reduces noise and notification fatigue by requiring a combination of conditions to fire, and it also simplifies operational responses by providing a single aggregated state.

• ✗

  Use CloudWatch Logs Insights to query logs and create alarms based on the query results.

  Why it's wrong here

  CloudWatch Logs Insights is a query engine for interactively searching and analyzing log data, usually for troubleshooting or ad-hoc investigations. While you can create metric filters from log patterns and then put alarms on those metrics, Logs Insights itself does not run continuously or provide any mechanism to suppress or filter existing alarm notifications. It helps you find the root cause after an alarm fires, but it does not address the problem of alert noise.

• ✗

  Use AWS Config rules to automatically suppress alarms that are not compliant.

  Why it's wrong here

  AWS Config rules continuously evaluate your AWS resource configurations against desired compliance policies, such as checking whether an S3 bucket has versioning enabled or an EC2 instance has the right security group. They have no knowledge of CloudWatch alarm states and cannot suppress, mute, or alter alarm actions in any way. Using AWS Config for alarm management would be a misuse of the service; compliance non-compliance is about configuration drift, not operational alerting.

Go deeper

Related to this question