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.

• ✗

  Enable detailed monitoring on the Auto Scaling group.

  Why it's wrong here

  Detailed monitoring on an Auto Scaling group only increases the reporting frequency of existing EC2 metrics from five minutes to one minute. It does not add any new metric categories, because memory utilization is a guest-OS counter that the hypervisor cannot observe. Enabling it would provide faster polling of CPU or network metrics but would never expose memory usage, so the core monitoring gap remains unaddressed.

• ✓

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

  Why this is correct

  The CloudWatch agent is the recommended mechanism for publishing EC2 guest-level metrics such as memory utilization, swap usage, and disk space to CloudWatch. Running on each instance, it collects counters from the OS and sends them under the CWAgent namespace, making them available for CloudWatch alarms and dashboards. To use it, install the agent on every instance in the Auto Scaling group, typically via user data or a bootstrap script, so that newly launched instances also begin reporting memory metrics.

• ✗

  Use the default EC2 memory metric provided by CloudWatch.

  Why it's wrong here

  CloudWatch does not provide a default EC2 memory metric. The standard AWS/EC2 namespace only contains hypervisor-visible metrics like CPUUtilization, NetworkIn, DiskReadOps, and StatusCheckFailed; memory resides inside the guest OS and is invisible to Amazon's hypervisor. Therefore, there is no out-of-the-box memory metric to select in the CloudWatch console or API. Any memory utilization data must come from an agent that reads OS-level counters and publishes them as custom metrics.

• ✗

  Create a Lambda function to pull memory data from the EC2 instances.

  Why it's wrong here

  A Lambda function can retrieve memory metrics from EC2 instances only if a CloudWatch agent or custom script is already installed and publishing those metrics to CloudWatch, which the scenario does not specify. The question requires a solution that enables monitoring of memory usage, not merely pulls existing data. This option is tempting because Lambda is commonly used to process or aggregate CloudWatch metrics after they are collected, and in a scenario where memory data is already being published, a Lambda function could transform or alert on it.

Go deeper

Related to this question