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.

• ✗

  Enable detailed monitoring on the EC2 instance to get 1-minute metrics.

  Why it's wrong here

  Enabling detailed monitoring on the EC2 instance changes the metric resolution from 5 minutes to 1 minute, but it does not create any alarm or notification mechanism. The existing requirement is to trigger an alert when CPU utilization exceeds 90% for 5 minutes, which can already be achieved with basic monitoring by setting an alarm with an appropriate period and evaluation periods. Thus, this step only incurs additional costs and provides no direct value toward the goal of notifying the team.

• ✓

  Configure an Amazon SNS topic and subscribe the team's email address to it, then set the alarm to send notifications to the SNS topic.

  Why this is correct

  An Amazon SNS topic acts as the delivery channel for CloudWatch alarm actions. By creating a topic, subscribing the team's email address, and confirming the subscription, the alarm can publish messages to that topic whenever it transitions to the ALARM state. This is the standard method to send email notifications and is a required component for the team to be alerted. Without this, the alarm would only change state and not proactively reach the team.

• ✓

  Create a CloudWatch alarm on the CPUUtilization metric with a threshold of 90% and an evaluation period of 5 consecutive minutes.

  Why this is correct

  A CloudWatch alarm on the CPUUtilization metric defines the monitoring condition itself. With a threshold of 90% and an evaluation period of 5 consecutive minutes, the alarm will transition to ALARM state when the metric exceeds 90% for that duration. This is the core detection mechanism that continuously evaluates EC2 CPU usage. However, the alarm only becomes useful when it is associated with an action, such as an SNS topic, to notify the team.

• ✗

  Create a CloudWatch Logs metric filter to count CPU utilization errors.

  Why it's wrong here

  CloudWatch Logs metric filters are designed to extract custom metrics from log data, such as counting specific patterns or error codes in application logs. CPU utilization is a standard EC2 metric that is published automatically to CloudWatch, not written into log files. Therefore, a log metric filter cannot count CPU utilization errors because there are no corresponding log events for this metric. This option incorrectly applies a log-processing feature to a system metric.

• ✗

  Create a CloudWatch dashboard to visualize CPU utilization.

  Why it's wrong here

  A CloudWatch dashboard provides a visual representation of metrics in graphs and widgets, but it is purely a visualization tool. It does not evaluate thresholds, maintain alarm states, or send notifications to any endpoint. While it can help the team monitor CPU utilization manually, it cannot trigger an alert when the utilization exceeds 90% for 5 minutes. Thus, it fails to meet the requirement of proactive notification.

Go deeper

Related to this question