DOP-C02 Monitoring and Logging Practice Question
A company is running a production application on Amazon ECS with Fargate. The DevOps team needs to monitor the application's performance and set up alerts for high memory usage. Which THREE steps should the team take to achieve this?
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 custom CloudWatch metric and publish memory usage data from the application
Options B, C, and D are correct. To monitor memory usage in ECS Fargate, you must enable the ECS task metadata endpoint (option D), which allows the container to access task metadata and publish custom memory metrics to CloudWatch. Then create a custom CloudWatch metric (option B) and set up a CloudWatch alarm on that metric (option C). Option A is incorrect because CloudWatch does not automatically collect memory metrics from Fargate tasks; custom metrics are required. Option E is incorrect because CloudWatch Container Insights provides visibility into container-level metrics but does not collect memory metrics from Fargate tasks without additional configuration; custom metrics are still needed for memory monitoring.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Configure CloudWatch to automatically collect memory metrics from Fargate tasks
Why it's wrong here
CloudWatch's default ECS metrics do not include per-task memory utilization for Fargate because the underlying hosts are not exposed. Unlike the EC2 launch type, there is no host-level CloudWatch agent to gather cgroup statistics, and the service cannot automatically pull memory data from Fargate. You must either instrument the application or use a sidecar agent to publish this data yourself.
- ✓
Create a custom CloudWatch metric and publish memory usage data from the application
Why this is correct
The application itself can read its memory usage from the container's cgroup files (e.g., /sys/fs/cgroup/memory/memory.usage_in_bytes) or from runtime APIs, and then call CloudWatch PutMetricData to publish a custom metric. This gives you full control over the metric's namespace, dimensions (e.g., service, task ARN), and granularity. Unlike built-in or container-level metrics, custom metrics are the only way to capture memory from within the Fargate task process.
- ✓
Set up a CloudWatch alarm on the custom memory metric with appropriate threshold and actions
Why this is correct
An alarm on the custom metric provides the actionable layer: you define a threshold (e.g., 85% of memory.limit) and a number of evaluation periods, and CloudWatch triggers a state change to ALARM when sustained breach occurs. The alarm can then fan out to SNS topics, Lambda functions, or ECS Service Auto Scaling to enable scaling based on memory pressure. This step is essential because raw custom metrics do not by themselves notify anyone.
- ✓
Enable the ECS task metadata endpoint and configure the application to publish memory metrics to CloudWatch
Why this is correct
The ECS task metadata endpoint (available at http://169.254.170.2/v2/stats inside the task) returns JSON containing CPU and memory statistics, including memory.usage and memory.limit. An application or a small sidecar process can poll this endpoint and feed the numbers into CloudWatch as custom metrics. This is particularly useful for Fargate because it provides platform-level memory data without requiring host-level access.
- ✗
Enable Amazon CloudWatch Container Insights for the ECS cluster
Why it's wrong here
Container Insights for ECS does eventually surface memory metrics, but on Fargate it requires the CloudWatch agent to be added as a sidecar container to every task definition, along with the appropriate IAM permissions. The agent is responsible for collecting stats from the Docker/cgroup interface and emitting them as CloudWatch metrics, so simply enabling Container Insights for the cluster does not automatically collect memory metrics from running Fargate tasks. Adding the sidecar also increases task resource consumption and operational overhead, making this incorrect if the goal is automatic collection.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 251 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.