SOA-C02 Monitoring, Logging, and Remediation Practice Question

An application running on EC2 instances sends custom metrics to CloudWatch using the PutMetricData API. The SysOps admin notices that some metrics are missing from the CloudWatch console. What is the most likely cause?

⚠ Common exam trap

Watch out — candidates often assume missing metrics are due to timestamp or dimension issues, but the most common real-world cause is a namespace mismatch between the PutMetricData call and the console filter, which CloudWatch does not automatically reconcile.

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 namespace in the PutMetricData call does not match the namespace in the CloudWatch console

Custom metrics in CloudWatch are uniquely identified by the combination of namespace, metric name, and dimensions. If the namespace used in the PutMetricData API call does not match the namespace being viewed in the CloudWatch console, the metrics will not appear under that namespace. CloudWatch does not automatically merge or alias namespaces, so mismatched namespaces cause the data to be stored under a different namespace, making it invisible in the console view.

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 metric data does not include a unit
Why it's wrong here
Unit is also optional; CloudWatch accepts measurements without a unit and displays them as 'Count' or 'None' depending on context. The absence of a unit does not cause the metric to be hidden or omitted from the console; it simply lacks a defined scale (e.g., MB, seconds). Thus, omitting a unit would not explain why the user cannot see the custom metric.
✗
The metric data does not include a dimension
Why it's wrong here
Dimensions are optional in CloudWatch. A PutMetricData call without dimensions creates a metric with no dimensions, which is still valid and appears in the console under the metric's namespace and name. CloudWatch will display the metric; it just won't be filtered by any dimension. Therefore, missing dimensions alone do not prevent the custom metric from appearing in the CloudWatch console.
✗
The metric data is being sent with a timestamp older than 14 days
Why it's wrong here
CloudWatch does accept historical data points with timestamps up to two weeks in the past (the PutMetricData API allows timestamps up to 14 days old). Such data points are stored and shown in the console, but they appear at the older time, so they wouldn't be visible in a current view. Since the user is presumably looking at the current time range, the older data would not be missing—it would simply be backdated, so this is not the cause.
✓
The namespace in the PutMetricData call does not match the namespace in the CloudWatch console
Why this is correct
This is the correct answer. The namespace is a container for metrics; if the application sends custom metrics using a different namespace than the one being viewed in the CloudWatch console (e.g., 'Custom/App' vs 'AWS/EC2'), the metrics will be stored under the namespace specified in the PutMetricData call. The console only displays metrics from the selected namespace, so a mismatched namespace makes the metrics appear 'missing.' The fix is to use a consistent namespace across the publishing and viewing steps.

Go deeper

SOA-C02 Monitoring, Logging, and Remediation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question