SOA-C02 Monitoring, Logging, and Remediation 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.

• ✗

  Use the EC2 detailed monitoring feature to collect disk metrics.

  Why it's wrong here

  EC2 detailed monitoring enables 1-minute CloudWatch metrics at the hypervisor level, such as CPU utilization, network throughput, and EBS volume read/write behavior. However, these metrics do not expose guest-OS filesystem statistics like total disk space, free space, or usage percentage, because the hypervisor cannot see the operating system's filesystems. To access such in-guest data, you must install an agent inside the OS.

• ✓

  Install the Amazon CloudWatch Agent on the instances and configure it to collect disk metrics.

  Why this is correct

  The Amazon CloudWatch Agent runs inside the guest OS and gathers custom metrics from the operating system, including disk utilization metrics like disk_used_percent, disk_free, and inode usage. You define the metrics to collect in the agent configuration file, and the agent sends them to CloudWatch, where you can create alarms on thresholds. This is the standard method for monitoring filesystem space on EC2 instances.

• ✗

  Use AWS Systems Manager Patch Manager to check disk space.

  Why it's wrong here

  AWS Systems Manager Patch Manager automates the process of scanning EC2 instances for missing patches and installing them, but it is not a monitoring tool and does not emit periodic CloudWatch metrics for disk space. While you could run an SSM document such as AWS-RunShellScript to execute a df command on demand, that gives a one-time snapshot rather than continuous monitoring and alarming. Real-time or scheduled disk-usage monitoring requires a custom script or the CloudWatch agent, not Patch Manager.

• ✗

  Configure an Amazon CloudWatch metric filter on the system log.

  Why it's wrong here

  Amazon CloudWatch metric filters are designed to parse log event patterns and extract numeric values or counts from structured or unstructured log lines, but they only operate on data that is actually written to log streams. Standard system logs (like /var/log/messages or Windows Event Logs) do not contain periodic disk utilization figures at a useful granularity. Unless you explicitly configure your OS to log disk usage, a metric filter would have nothing to evaluate, making this an indirect and unreliable approach for monitoring filesystem capacity.

Go deeper

Related to this question