DOP-C02 Monitoring and Logging Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Monitor the 'InitDuration' metric in CloudWatch for the Lambda function.

  Why this is correct

  Monitoring the 'InitDuration' metric is the direct, built-in approach because CloudWatch automatically receives this metric for every Lambda invocation that experiences a cold start. This metric reports the time the runtime spends initializing the execution environment (downloading the code, starting the runtime, and running initialization code) before the handler is invoked. It requires no custom instrumentation or querying, making it the simplest and most authoritative source for cold start duration.

• ✗

  Use CloudWatch Logs Insights to query log groups for 'REPORT' lines and calculate duration.

  Why it's wrong here

  While CloudWatch Logs Insights can parse 'REPORT' log lines that contain an 'Init Duration' field during cold starts, this method is indirect and unnecessarily complex. You must first ensure your Lambda function has the appropriate log group and permissions, then write and run a query that regex-matches the correct field name while excluding warm invocations that lack this field. This approach adds a dependency on log retention and query quotas, whereas the same data is already surfaced natively as the InitDuration cloud watch metric with zero setup.

• ✗

  Publish a custom metric from the Lambda code that measures initialization time.

  Why it's wrong here

  Publishing a custom metric from within your Lambda code to measure initialization time is both redundant and technically awkward. The CloudWatch Lambda runtime automatically emits InitDuration, so a custom metric would duplicate existing data and incur extra cost for PutMetricData API calls. Moreover, by the time your handler code executes, initialization has already completed; you would need to place measurement code in a separate static initializer or context that captures time before handler entry, which is error-prone and does not capture the runtime's own bootstrapping phases.

• ✗

  Enable AWS X-Ray and trace the Lambda invocation to see cold start duration.

  Why it's wrong here

  Enabling AWS X-Ray can indeed show a cold start in a trace, but it is not the intended or simplest mechanism for measuring cold start duration. X-Ray usage is opt-in and subject to sampling, so not every invocation will produce a trace, which makes it unreliable for capturing all cold start events. Also, the trace's 'Init' segment gives approximate timing but is more about visibility into downstream segments, whereas the InitDuration metric is a precise, per-invocation CloudWatch measurement designed exactly for this purpose.

Go deeper

Related to this question