SOA-C02 Monitoring, Logging, and Remediation Practice Question

A company is running a critical application on Amazon EC2 instances. The application performance has degraded over the past week. The SysOps administrator suspects a memory leak. The administrator needs to collect detailed memory usage metrics every minute and store them for 30 days. Which solution is the MOST cost-effective and operationally efficient?

⚠ Common exam trap

Test-takers frequently confuse detailed EC2 monitoring (which only covers hypervisor-level metrics) with in-guest monitoring, assuming that enabling detailed monitoring will capture memory usage, but memory is a guest OS metric that requires the CloudWatch agent.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Install the CloudWatch agent on the EC2 instances to collect memory metrics and publish them to CloudWatch.

The CloudWatch agent is specifically designed to collect custom metrics like memory utilization from EC2 instances, which are not available through default or detailed EC2 monitoring. By installing the agent and configuring it to publish memory metrics to CloudWatch every minute, the administrator can meet the requirement for 1-minute granularity and 30-day retention cost-effectively, as CloudWatch retains metric data at 1-minute resolution for 15 days by default, but can be extended to 30 days via a custom metric retention setting.

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 AWS CloudTrail to log memory usage and store the logs in Amazon S3.
Why it's wrong here
AWS CloudTrail is an API auditing service that records management events, such as EC2 RunInstances or TerminateInstances calls, made by users, roles, or AWS services. It does not ingest operating system-level performance counters or guest OS metrics like memory utilization, because those values exist inside the instance rather than in the AWS control plane. Even if you enabled data events or delivered logs to Amazon S3, the logs would contain API call metadata, not sampled memory readings, so this approach cannot satisfy the monitoring requirement.
✗
Enable default EC2 monitoring to collect memory metrics every 5 minutes.
Why it's wrong here
Default EC2 monitoring publishes basic instance metrics—CPU utilization, network throughput, disk I/O, and status checks—to CloudWatch at a 5-minute frequency. Memory utilization is measured from inside the guest operating system, and AWS does not have visibility into that layer without an agent, so default metrics have no memory dimension at all. While the 5-minute interval is correct for basic metrics, it is irrelevant because the memory metric itself is missing entirely.
✗
Enable detailed monitoring on the EC2 instances to collect memory metrics every 1 minute.
Why it's wrong here
Enabling detailed monitoring on an EC2 instance changes the frequency of the existing hypervisor-visible metrics (CPU, network, disk) from 5 minutes to 1 minute, but it does not add memory metrics. Memory usage is not exposed by the Nitro or Xen hypervisor, so CloudWatch never receives it regardless of the monitoring interval. Detailed monitoring therefore only gives you finer-grained CPU, network, and disk I/O data, leaving the memory utilization gap unresolved.
✓
Install the CloudWatch agent on the EC2 instances to collect memory metrics and publish them to CloudWatch.
Why this is correct
The CloudWatch agent is a software component installed on the EC2 instance that reads memory usage from the operating system (/proc/meminfo on Linux or performance counters on Windows) and publishes those values to CloudWatch as custom metrics. Once configured, the agent can report memory utilization with a 1-minute resolution and even collect additional metrics like swap usage or disk space, all of which appear under the CWAgent namespace. Because the agent runs inside the instance, it can access OS-level data that hypervisor-based default and detailed monitoring cannot, making this the required solution.

Go deeper

SOA-C02 Monitoring, Logging, and Remediation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question