An operations team must alarm on the percentage of used memory and free disk space on a fleet of EC2 instances running a standard Amazon Linux AMI. They have not changed the default monitoring configuration. What is the most operationally efficient way to make these signals available as CloudWatch metrics?
- AInstall and configure the CloudWatch agent on the instances to collect memory and disk metrics and publish them to a custom namespace. Correct
- BEnable detailed monitoring on each EC2 instance so that memory and disk metrics are published at a one-minute frequency.
- CRead the existing MemoryUtilization and DiskSpaceUtilization metrics that EC2 publishes by default to the AWS/EC2 namespace.
- DCreate a CloudWatch metric filter over the instance system logs to extract memory and disk values into custom metrics.
Why A is correct: The CloudWatch agent reads in-guest counters such as mem_used_percent and disk_free, publishing them as custom metrics that alarms can then evaluate, which is exactly the supported pattern.
Why B is wrong: Detailed monitoring only raises the publishing frequency of the existing hypervisor metrics to one minute; it never adds in-guest memory or disk usage, so the required signals are still missing.
Why C is wrong: It sounds right because CPU is there by default, but EC2 publishes no memory or disk-space metric to AWS/EC2; those values live inside the guest and are never collected automatically.
Why D is wrong: Metric filters only run against log events already in CloudWatch Logs, and the default AMI does not log memory or disk usage, so there is nothing for the filter to match.