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.

• ✗

  CPUUtilization metric with the Sum statistic, filtered by Auto Scaling group.

  Why it's wrong here

  Choosing the Sum statistic for CPUUtilization is misleading because it adds the CPU percentage values across every instance in the Auto Scaling group. For example, five instances at 70% CPU would produce a Sum of 350%, a figure that does not represent any real utilization level and scales artifactually with instance count. The Sum statistic is appropriate for counting events like status check failures or request counts, not for a rate-based metric expressed as a percentage, so it cannot accurately track fleet CPU pressure.

• ✓

  CPUUtilization metric with the Average statistic, filtered by Auto Scaling group.

  Why this is correct

  The Average statistic applied to CPUUtilization with the AutoScalingGroupName dimension gives the mean CPU percentage across all instances in the group, which is exactly what the dashboard needs to assess overall load. CloudWatch computes this by taking the CPUUtilization data points from each instance and calculating the arithmetic mean over the selected period. This is the standard and CloudFormation-idiomatic approach for monitoring an Auto Scaling group's aggregate CPU usage, and it directly answers the requirement without mixing units or extrapolating to a nonsensical total.

• ✗

  StatusCheckFailed metric with the Average statistic, filtered by Auto Scaling group.

  Why it's wrong here

  StatusCheckFailed is a metric that reports whether an EC2 instance's system or instance status checks are passing, returning a value of 0 (pass) or 1 (fail). Applying the Average statistic to it would yield the fraction of instances in the Auto Scaling group that are failing checks, which is a health indicator, not a measure of CPU utilization. Even though the dashboard could technically display it, the question specifically asks for a CPU utilization metric, so this metric is outside the scope no matter which statistic is chosen.

• ✗

  NetworkOut metric with the Average statistic, filtered by Auto Scaling group.

  Why it's wrong here

  NetworkOut measures the number of bytes an instance has sent out of all network interfaces, so its dimension is throughput rather than compute utilization. Averaging NetworkOut across the Auto Scaling group would show aggregate byte output per second, which is useful for diagnosing bandwidth saturation but says nothing about CPU load. Since the requirement is to monitor CPU utilization, choosing NetworkOut would leave the dashboard without any visibility into compute resource consumption, making it an incorrect selection regardless of the statistic.

Go deeper

Related to this question