DOP-C02 Monitoring and Logging 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.

• ✗

  Have the application call the CloudWatch PutMetricData API directly.

  Why it's wrong here

  Calling the CloudWatch PutMetricData API directly requires embedding the AWS SDK into the application and adding instrumentation code at every metric emission point. This couples business logic to AWS-specific API calls, forces you to manage credentials, batching, and retries, and is exactly the code change the requirement rules out. It also prevents using a standard agent-based collection layer, making the solution brittle and hard to migrate.

• ✓

  Run the CloudWatch agent as a sidecar container in the ECS task definition, configured to collect StatsD metrics from the application container.

  Why this is correct

  The CloudWatch agent can run as a sidecar container in the same ECS task, and with the default awsvpc network mode all containers share a localhost network namespace. Configure the agent with a StatsD stanza so it listens on port 8125, and the application simply sends UDP messages in the StatsD format—no SDK, no logging changes, and no application code modifications. The agent buffers, batches, and forwards these metric points to CloudWatch as a single API consumer, preserving the existing application behavior.

• ✗

  Use the ECS agent's built-in metric collection feature.

  Why it's wrong here

  The ECS agent (or in Fargate, the underlying managed infrastructure) only exposes container-level telemetry such as CPU utilization, memory usage, and network I/O from Docker runtime stats. It has no mechanism to parse StatsD, StatsD-like UDP payloads, or any application-defined counters and gauges. Custom application metrics, especially those based on application logic or dimensions, are simply outside the scope of what the ECS agent collects, so relying on it leaves the needed metrics unavailable.

• ✗

  Modify the application to send logs using the embedded metric format.

  Why it's wrong here

  The embedded metric format (EMF) is a powerful pattern that turns structured logs into CloudWatch metrics, but it requires the application to rewrite its logging calls to emit JSON documents with a specific _aws section containing the metric definitions. This is a code change to the application's logging layer and a change to operational behavior, which the requirement explicitly prohibits. Additionally, when running on Fargate you typically need the CloudWatch agent or a separate EMF exporter to decode the logs, so it is not simpler than the sidecar approach.

Go deeper

Related to this question