Courseiva
Monitoring and Logging →mediumMultiple Choice

DOP-C02 Monitoring and Logging Practice Question

A DevOps engineer is troubleshooting a production AWS Lambda function that occasionally times out. The function has a timeout of 30 seconds and uses a synchronous invocation. The engineer wants to capture invocation logs to identify the cause. Which approach will provide the MOST detailed diagnostic information?

⚠ Common exam trap

It's easy for candidates to confuse CloudWatch Logs (which show custom log output) with X-Ray tracing (which provides automatic, detailed timing of every subcomponent), leading them to choose option C instead of the more diagnostic X-Ray approach.

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 AWS X-Ray tracing on the Lambda function.

AWS X-Ray provides end-to-end tracing for Lambda functions, capturing detailed timing information for each invocation, including subsegments for downstream calls, function initialization, and execution phases. This allows the engineer to pinpoint exactly where time is being spent, which is essential for diagnosing intermittent timeouts in synchronous invocations.

Answer analysis

Option-by-option breakdown

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

  • ✗

    Enable AWS CloudTrail data events for Lambda.

    Why it's wrong here

    AWS CloudTrail data events for Lambda record the invocation of the function as an API activity, such as Invoke calls or events from AWS services. While this can show that a Lambda was triggered and by whom, it does not include execution timing, subsegment durations, or any trace of the function's internal operations. CloudTrail is for auditing and governance, not performance troubleshooting, so it cannot help identify where time is being spent inside the invocation.

  • ✗

    Create a CloudWatch dashboard with function duration metrics.

    Why it's wrong here

    A CloudWatch dashboard with function duration metrics displays the average, minimum, maximum, or p99 duration across all invocations over a time window. This aggregated view is useful for spotting trends or anomalies, but it hides per-invocation variability and provides no breakdown of how the time is allocated—for example, how long is spent in initialization, external API calls, or database queries. Without a trace that correlates individual requests to their timing, you cannot pinpoint the specific bottleneck causing slow production lambdas.

  • ✗

    Add more logging statements to the function code and check CloudWatch Logs.

    Why it's wrong here

    Adding more logging statements to the function code and checking CloudWatch Logs can reveal where time is spent if you manually record timestamps before and after each external call. However, this approach requires modifying code, estimating granularity, and often lacks the context of the full distributed request across services like DynamoDB or API Gateway. CloudWatch Logs gives you raw output, not a structured trace, so correlating log entries across services and identifying a precise bottleneck becomes tedious and error-prone, especially in a production environment with high concurrency.

  • ✓

    Enable AWS X-Ray tracing on the Lambda function.

    Why this is correct

    AWS X-Ray tracing on the Lambda function provides an end-to-end view of the invocation, showing each subsegment's duration, including the time spent in external HTTP calls, AWS SDK operations, and service integrations. It automatically captures the trace for every invocation without requiring code changes (unless you need custom subsegments), and the trace timeline reveals exactly which downstream call or code block is consuming the most time. This makes X-Ray the correct tool to diagnose performance bottlenecks in a production Lambda, as it gives the per-invocation, subsegment-level detail that the other options lack.

Quick reference

Cloud Service Model Comparison

ModelYou ManageProvider ManagesExamples
IaaSOS, runtime, apps, dataHardware, hypervisor, networkingEC2, Azure VMs, GCP Compute Engine
PaaSApps and dataOS, runtime, middleware, hardwareElastic Beanstalk, Azure App Service
SaaSData and settings onlyEverything elseMicrosoft 365, Salesforce, Workday
FaaS / ServerlessFunction code onlyInfra, scaling, runtimeLambda, Azure Functions, Cloud Run
CaaSContainers and appsKubernetes, OS, hardwareEKS, AKS, GKE

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 →

How Courseiva writes practice questions · Editorial policy

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.