SOA-C02 Monitoring, Logging, and Remediation Practice Question

A SysOps administrator is setting up monitoring for an application that runs on Amazon ECS with Fargate launch type. The application's performance degrades when memory utilization exceeds 80%. The administrator wants to receive a notification when memory usage approaches this threshold. What should the administrator do?

⚠ Common exam trap

A common mix-up: candidates assume they need to install an agent or use Container Insights to get memory metrics, but ECS Fargate automatically publishes `MemoryUtilization` and `CPUUtilization` metrics to CloudWatch without any extra setup.

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

✓

Create a CloudWatch alarm on the ECS service's MemoryUtilization metric

Amazon ECS services automatically publish a `MemoryUtilization` metric to CloudWatch for Fargate tasks. By creating a CloudWatch alarm on this metric with a threshold of 80%, the administrator can trigger an SNS notification when memory usage approaches the threshold, enabling proactive remediation before performance degrades.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Install the CloudWatch agent on each Fargate task
Why it's wrong here
Installing the CloudWatch agent on Fargate tasks is not possible because Fargate is a serverless compute engine that abstracts away the underlying host. You do not have access to the container runtime or host OS-level configuration, and tasks are immutable, so any agent installation would be lost on every task restart. Custom metrics can be published from application code using the CloudWatch API, but the agent itself cannot be installed inside Fargate tasks.
✗
Use Amazon CloudWatch Container Insights to view ReservedMemory metric
Why it's wrong here
CloudWatch Container Insights aggregates metrics such as CPU, memory, network, and disk from ECS clusters, but the metric name 'ReservedMemory' is not a standard CloudWatch metric exposed for ECS services. Container Insights does provide memory utilization at the cluster and service level, but viewing a metric in the console does not by itself send a notification; you would need to create an alarm on a valid metric. Therefore, this approach does not meet the need to be notified.
✗
Enable Service Auto Scaling with a target tracking policy based on MemoryUtilization
Why it's wrong here
Enabling Service Auto Scaling with a target tracking policy based on MemoryUtilization would automatically adjust the desired count of tasks to maintain a target average memory utilization. This action controls capacity, but it does not generate a notification to the SysOps administrator—it simply changes the running task count. To be notified you need a CloudWatch alarm that triggers an SNS topic, not a scaling policy.
✓
Create a CloudWatch alarm on the ECS service's MemoryUtilization metric
Why this is correct
The Amazon ECS service publishes the MemoryUtilization metric, which represents the average memory used by all tasks in the service relative to the memory reserved for each task. You can create a CloudWatch alarm on this metric with a threshold that, when breached, sends a message to an Amazon SNS topic subscribed to by the SysOps administrator. This alarm-plus-notification pattern directly addresses the requirement to be notified of memory issues.

Go deeper

SOA-C02 Monitoring, Logging, and Remediation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question