DOP-C02 Monitoring and Logging Practice Question
A company runs a microservices architecture on Amazon ECS with Fargate. The operations team wants to collect custom application metrics (e.g., request latency per service) and visualize them in CloudWatch dashboards. The team also needs to set CloudWatch alarms based on these metrics. Which solution requires the LEAST amount of code changes and operational overhead?
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
✓
Use the CloudWatch Embedded Metric Format to emit custom metrics as JSON log entries.
The CloudWatch Embedded Metric Format allows applications to emit metrics as structured JSON logs, which CloudWatch automatically extracts into metrics and logs. This requires minimal code changes (just log format). Option B is wrong because publishing to CloudWatch via PutMetricData requires the AWS SDK and more code changes. Option C is wrong because CloudWatch Agent on Fargate is not supported (requires EC2). Option D is wrong because using a sidecar container for StatsD adds complexity and overhead.
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 the CloudWatch Embedded Metric Format to emit custom metrics as JSON log entries.
Why this is correct
The CloudWatch Embedded Metric Format encodes custom metric values inside a structured JSON log event; when the Fargate task's awslogs driver sends that log to CloudWatch Logs, CloudWatch automatically extracts the declared metrics into the specified namespace for graphing and alarms. This requires no separate daemon, sidecar, or SDK call—developers only add a serialization layer to application logging, making it the minimal-code path you asked for.
- ✗
Deploy a StatsD daemon as a sidecar container and configure the application to send metrics to StatsD, then forward to CloudWatch.
Why it's wrong here
A StatsD sidecar would receive metrics over UDP, aggregate them, and then require a separate forwarder to publish them to CloudWatch—creating an extra operational layer that must be built, deployed, and monitored on every task. UDP packet loss means metrics can be silently dropped, and since the CloudWatch agent's StatsD plugin is not supported on Fargate, you'd have to write and maintain a custom StatsD-to-CloudWatch bridge; this adds overhead without providing a native advantage over EMF.
- ✗
Modify the application code to use the AWS SDK to call PutMetricData API directly.
Why it's wrong here
Calling PutMetricData from each microservice forces every deployment to include the AWS SDK, distribute IAM credentials, and implement batching and retry logic to stay within CloudWatch's PutMetricData API quotas (default 150 requests per second per region). This tightly couples business logic to AWS-specific monitoring APIs and increases code churn across services, which is far heavier than the single logging-based approach EMF provides.
- ✗
Install the CloudWatch Agent on each Fargate task as a sidecar container to collect custom metrics.
Why it's wrong here
The CloudWatch Agent is designed for EC2 and on-premises hosts, where it can read system-level metrics and needs a configuration file; Fargate does not give you host access or allow the privileged/root operations the agent expects. Running it as a sidecar is an unsupported, resource-heavy workaround that consumes memory/CPU per task and still cannot expose Fargate host metrics, making it a poor fit compared to EMF's native log/metrics integration.
Go deeper
Related to this question
About these practice questions
One of 1,298 original DOP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.