A developer wants a CloudWatch metric published straight from a Lambda function using the embedded metric format, so the function writes a single structured log line that CloudWatch parses into a metric. They must place the metric name, namespace, and dimension definitions in the log object so CloudWatch knows which property is a metric and how to dimension it. Which part of the embedded metric format log object carries that metadata?
- AA top-level Dimensions array placed beside the metric values, which CloudWatch reads directly to decide the namespace and which properties become metrics
- BA MetricName and Namespace pair set as CloudWatch Logs metric filter properties on the log group, which extract the value after the event is stored
- CA top-level _aws node containing a CloudWatchMetrics block that lists the namespace, the dimension sets, and the metric names and units to extract Correct
- DA StatisticValues object wrapping each metric, supplying the sample count and sum so CloudWatch can aggregate the values without a metadata directive
Why A is wrong: EMF does not read a bare top-level Dimensions array, the dimension sets live inside the structured _aws CloudWatchMetrics block, so this misnames the directive.
Why B is wrong: Metric filters are configured on the log group and are a separate mechanism, EMF embeds its directive in the log event itself rather than relying on a filter.
Why C is correct: The _aws metadata node with its CloudWatchMetrics array tells CloudWatch the namespace, dimensions, and metric definitions, which is exactly how EMF marks values as metrics.
Why D is wrong: StatisticValues belongs to the PutMetricData API for pre-aggregated statistics, it is not the EMF metadata directive that defines namespace and dimensions.