DOP-C02 Monitoring and Logging Practice Question

Network Topology

Refer to the exhibit. A DevOps engineer runs the AWS CLI command to get the average TargetResponseTime for an ALB over a 1-hour period. The output shows only three datapoints. What is the most likely reason?

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

✓

The ALB did not receive any requests during most of the 5-minute periods.

The command uses a period of 300 seconds (5 minutes), so over a 1-hour period we expect 12 data points if the metric is consistently reported. However, TargetResponseTime is only emitted when the ALB receives at least one request in that interval. The output shows only three data points, indicating that for the majority of the 5-minute periods, the ALB received no requests, so no metric data was published. Option A correctly identifies this. Option B is incorrect because TargetResponseTime is a valid metric for Application Load Balancers. Option C is incorrect because the command appears to include the necessary parameters to retrieve the average. Option D is incorrect because a 300-second period is standard; using a smaller period would not produce more data points if there are no requests.

Answer analysis

Option-by-option breakdown

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

✓
The ALB did not receive any requests during most of the 5-minute periods.
Why this is correct
The ALB emits TargetResponseTime only when it actually processes requests. For any 5-minute interval in which no request was routed through the load balancer, CloudWatch receives no samples and therefore publishes no datapoint. The get-metric-statistics output contains a datapoint only for each period with at least one request, so periods with no traffic are simply missing from the result rather than appearing as zero. This exactly explains why fewer datapoints than expected are returned.
✗
The metric TargetResponseTime is not available for Application Load Balancers.
Why it's wrong here
TargetResponseTime is a standard CloudWatch metric in the AWS/ApplicationELB namespace; it measures the time from when the load balancer sends a request to a target until it receives the first response byte from that target. It is not to be confused with Classic Load Balancer's Latency metric, which uses a different metric name. If the metric were truly unavailable for ALBs, the CLI call would have returned a validation error, not a sparse set of datapoints. Hence, metric availability is not the reason.
✗
The command is missing the 'Statistics' parameter with 'Average'.
Why it's wrong here
The get-metric-statistics command already includes the --statistics parameter with a value of Average, so the request is valid in that regard. This parameter is required, but omitting it would cause an InvalidParameter error, not silently fewer datapoints. The presence of Average simply tells CloudWatch to return the arithmetic average of the samples in each 300-second period. Since the parameter is correctly supplied, the explanation for missing datapoints must lie elsewhere.
✗
The period of 300 seconds is too large; a smaller period should be used.
Why it's wrong here
A 300-second period is perfectly valid for ALB CloudWatch metrics and matches the default granularity of the GetMetricStatistics API for a 5-minute interval. The number of possible datapoints is determined by the (end time - start time)/period; a smaller period would create more potential buckets, but it would not create data for periods where no requests occurred. CloudWatch only emits samples for intervals with activity, so choosing a smaller period would still omit the same silent gaps. Thus, the period size is not the source of the issue.

Go deeper

DOP-C02 Monitoring and Logging Practice Question

Why each option matters

Option-by-option breakdown

Related to this question