DOP-C02 Monitoring and Logging Practice Question
A company uses AWS Lambda functions to process incoming events. The DevOps team notices that some functions are timing out after 30 seconds, but the configured timeout is 1 minute. They want to capture the actual invocation duration for all invocations to analyze performance. What is the most efficient way to achieve this?
⚠ Common exam trap
Many exam-takers confuse CloudTrail's 'duration' field (which measures API call latency) with the actual function execution duration, leading them to incorrectly select option D.
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
✓
Enable detailed CloudWatch Logs for the Lambda functions and parse the 'REPORT' log entries to extract the 'Duration' value.
Lambda automatically writes a REPORT log entry to CloudWatch Logs at the end of each invocation, which includes the exact 'Duration' in milliseconds. Parsing these logs is the most efficient approach since it requires no code changes, no additional infrastructure, and leverages existing logging with no extra cost beyond standard CloudWatch Logs ingestion.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add custom metrics using the AWS SDK within the Lambda function code to record the duration.
Why it's wrong here
Adding custom metrics via the AWS SDK inside the function code is redundant because Lambda already publishes a Duration metric to CloudWatch, and more importantly it cannot be applied retroactively to existing invocations. The SDK call also introduces a performance hit and requires IAM permissions for PutMetricData, plus changes to the function's deployment pipeline. For inspecting historical execution data, the built-in REPORT lines in CloudWatch Logs are the authoritative source and require no code modifications.
- ✗
Configure Amazon Kinesis Data Streams to receive Lambda invocation records and compute duration using a consumer application.
Why it's wrong here
Streaming invocation records through Kinesis Data Streams would force you to modify each Lambda handler to emit records to a Kinesis producer, then build and operate a separate consumer application to parse those records and calculate duration. This architectural complexity introduces additional latency, higher cost, and duplicate logic since the exact duration is already available in the Lambda execution's REPORT log line. It is a disproportionate solution for what should be a simple log-based lookup.
- ✓
Enable detailed CloudWatch Logs for the Lambda functions and parse the 'REPORT' log entries to extract the 'Duration' value.
Why this is correct
Enabling CloudWatch Logs is the correct approach because every Lambda invocation automatically emits a REPORT log entry containing a Duration field, for example 123.45 ms, along with billed duration and memory usage. This is generated by the Lambda managed runtime, so there is no need to instrument the application code. You can use CloudWatch Logs Insights with a filter such as filter @type = 'REPORT' to query and parse these entries across all invocations, making it an efficient and fully managed solution for extracting execution duration.
- ✗
Use AWS CloudTrail to capture Lambda execution events and analyze the 'duration' field.
Why it's wrong here
AWS CloudTrail records management API activity such as InvokeFunction, GetFunction, and configuration changes, but it does not capture the internal execution duration of a Lambda function invocation. The event history shows that the function was invoked, the identity of the caller, and request parameters, but the function's actual compute time is not a field in CloudTrail events. CloudTrail is intended for audit and security investigation, not for performance monitoring, so it cannot satisfy the requirement to measure duration.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 1,298 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on DOP-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A DevOps engineer notices that a critical Lambda function occasionally times out. The engineer wants to monitor the function's duration and log the timeout errors for analysis. Which TWO steps should the engineer take to achieve this? (Select TWO.)
easy- ✓ A.Enable CloudWatch Logs for the Lambda function to capture logs.
- B.Store Lambda logs in an Amazon S3 bucket for analysis.
- C.Create a CloudWatch metric filter to monitor the Duration metric and set an alarm.
- ✓ D.Use AWS X-Ray to trace the function and view duration in the X-Ray console.
- E.Enable AWS CloudTrail to log all Lambda function invocations.
Why A: Option A is correct because Lambda automatically sends function logs (including timeout errors reported as "Task timed out after X seconds") to a CloudWatch Logs log group, so enabling/using CloudWatch Logs is the way to capture those timeout errors for analysis. Option D is correct because AWS X-Ray traces Lambda invocations end-to-end, recording subsegment timings and the function's duration so the engineer can pinpoint where the function spends time and why it occasionally exceeds its timeout. Option B is wrong because Lambda does not natively stream logs to S3; S3 storage would require an export or subscription pipeline and is not a monitoring step. Option C is wrong because the Duration metric is already emitted by Lambda to CloudWatch, so a metric filter is unnecessary (metric filters are for extracting values from log events), and an alarm alone does not log timeout errors. Option E is wrong because CloudTrail records control-plane API activity (e.g., UpdateFunctionConfiguration), not per-invocation execution details or timeout errors.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.