Exams / DVA-C02 / Custom metrics and alarms / Question 1
DVA-C02 practice question: Custom metrics and alarms (1 of 2)
Troubleshooting and Optimization A free question from our original DVA-C02 practice exam. Try it, then open the answer to see why each option is right or wrong.
A Lambda function processes orders and must publish a custom CloudWatch metric for each order's value, dimensioned by region. The developer wants to avoid adding a synchronous PutMetricData API call to every invocation and wants the detailed log events available for later queries. What should the developer do?
Choose one answer.
- AA. Call PutMetricData in a separate thread at the end of each invocation.
- BB. Create a metric filter that counts log lines containing the word order.
- CC. Write each order as a log event in CloudWatch embedded metric format.
- DD. Turn on Lambda Insights so the order value appears as a built-in metric.
Show the answer and explanation
Answer: C
- A. Wrong: This still makes an API call from every invocation and needs cloudwatch:PutMetricData. It may not finish before the invocation ends.
- B. Wrong: Counting matching lines gives the number of orders, not each order's value by region.
- C. Right: Correct. CloudWatch extracts the metrics from the structured log events asynchronously, and the logs stay queryable.
- D. Wrong: Lambda Insights adds system-level performance metrics. It does not know about business values such as order amounts.
Explanation
The CloudWatch embedded metric format (EMF) lets code emit metrics as structured JSON log events. CloudWatch Logs extracts the metrics automatically, so no PutMetricData call or permission is needed, and the detailed events can still be queried with Logs Insights. Avoid high-cardinality dimensions, because each unique combination creates a separate metric.
Study
Keep practising
Answer questions with a score at the end, or practise just this topic with the explanation after each one. No sign-up needed.