DOP-C02 Monitoring and Logging Practice Question
A company is running a critical application on Amazon ECS with Fargate. The application generates custom metrics that are published to CloudWatch using the PutMetricData API. Recently, the metrics have been delayed by up to 5 minutes. The DevOps team needs to reduce the latency. What should the team do?
⚠ Common exam trap
Watch out — candidates often think increasing API call frequency or using log-based metrics will reduce latency, but the actual cause is the default 60-second storage resolution, which delays metric availability regardless of how often data is sent.
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
✓
Set the StorageResolution parameter to 1 when calling PutMetricData.
Setting the StorageResolution parameter to 1 when calling PutMetricData enables high-resolution metrics with a 1-second granularity. This reduces the latency of metric ingestion and retrieval because CloudWatch processes high-resolution metrics more quickly than standard 60-second resolution metrics, addressing the 5-minute delay.
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 the Fargate tasks to collect metrics.
Why it's wrong here
Fargate does not support installing the CloudWatch agent directly because tasks run in isolated containers without access to a host-level operating system or EC2 instance state. The CloudWatch agent requires a persistent host environment (Amazon EC2 or on-premises) to configure, monitor, and send host-level metrics. On Fargate, you must instead instrument your application code to call the CloudWatch PutMetricData API directly, so this option cannot reduce custom metric latency.
- ✓
Set the StorageResolution parameter to 1 when calling PutMetricData.
Why this is correct
Calling PutMetricData with StorageResolution=1 creates a high-resolution custom metric with 1-second granularity, making the data available for CloudWatch alarms in as little as 10 seconds instead of the 60-second standard resolution. This lower storage resolution is the key to detecting critical issues faster because CloudWatch can evaluate alarms at a 10- or 30-second period. Without this parameter, your metrics default to 60-second resolution and alarm latency remains as high as a minute.
- ✗
Publish the metrics as structured logs to CloudWatch Logs and use metric filters.
Why it's wrong here
Metric filters in CloudWatch Logs continuously scan incoming log events and asynchronously emit extracted numeric values as metric data points, but this pipeline adds a significant delay before the metric is visible and actionable. The extraction process itself, along with the log ingestion and filtering overhead, can introduce minutes of lag and only supports standard-resolution metrics. Consequently, for low-latency alarming, direct PutMetricData calls are far more responsive than relying on embedded log-based metrics.
- ✗
Increase the frequency of PutMetricData calls to every 5 seconds.
Why it's wrong here
Simply calling PutMetricData more frequently, such as every 5 seconds, does not change the storage resolution of the metric; without StorageResolution=1, CloudWatch still aggregates and stores the data at 60-second granularity, so alarm evaluation is not sped up. Moreover, repeated API calls at that rate can consume your PutMetricData quota and risk ThrottlingException if the limit is exceeded, especially with multiple tasks publishing concurrently. The only way to reduce metric granularity is to set the StorageResolution parameter when you first publish the metric.
Go deeper
Related to this question
About these practice questions
This DOP-C02 question is part of Courseiva's 1,298-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.