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 VPC Flow Logs for the instance's subnet.

  Why it's wrong here

  VPC Flow Logs capture metadata about IP traffic flowing through the elastic network interfaces of your instance, including source/destination IPs, ports, protocol, and packet/byte counts. They are useful for security analysis and network troubleshooting, but they do not report guest-OS metrics such as memory utilization or disk space usage. Because flow logs operate at the network layer and never execute inside the instance, they cannot provide the memory utilization data the user is looking for.

• ✓

  Install and configure the CloudWatch Agent on the EC2 instances.

  Why this is correct

  The Amazon CloudWatch Agent is a software component installed inside the EC2 instance that collects operational metrics such as memory utilization, disk space and inode usage, and per-disk I/O statistics from the guest operating system. It can also collect custom application metrics and logs, and it sends them to CloudWatch via the PutMetricData API. This is the standard solution for monitoring metrics that are not exposed by the hypervisor, like memory usage, and it is the correct approach here.

• ✗

  Send the metrics to CloudWatch Logs and create a metric filter.

  Why it's wrong here

  Creating a metric filter requires you to first send log events to CloudWatch Logs, and then the filter parses those events to extract numeric values and emit them as CloudWatch metrics. However, this mechanism does not itself collect system performance data; it only transforms log output. To use it for memory monitoring, you would need a separate logging agent to emit memory readings, which is redundant and less reliable than using the CloudWatch Agent. The metric filter approach works exclusively with log data, not with system metrics directly.

• ✗

  Enable detailed monitoring on the EC2 instances.

  Why it's wrong here

  Enabling detailed monitoring on an EC2 instance changes the delivery frequency of the existing CloudWatch metrics from five minutes to one minute, such as CPU utilization, network throughput, and disk read/write bytes. These metrics are gathered by the hypervisor and do not include memory usage, because the hypervisor cannot see the guest OS's memory allocation. Detailed monitoring therefore only gives you more granular data for the metrics that already exist; it does not introduce new metrics like memory utilization.

Go deeper

Related to this question