The goal is to identify performance bottlenecks across a Lambda function that calls a database (DocumentDB). The most operationally efficient way to pinpoint where time is being spent—without building custom logging/metrics pipelines—is to use distributed tracing . AWS X-Ray provides end-to-end request traces, timing breakdowns, and service maps that help identify whether latency is dominated by Lambda initialization, downstream calls, or database queries.

By enabling X-Ray tracing on the Lambda function, the developer can capture traces for report-generation requests and examine segments that show duration spent inside the function and in downstream dependencies. To specifically diagnose database time, the developer can add custom subsegments around DocumentDB operations (query execution, connection acquisition, cursor iteration). This produces precise timing data for each step, making it straightforward to identify slow queries, excessive connection setup time, or serialization overhead. Because X-Ray aggregates and visualizes traces, the developer can quickly compare “fast” and “slow” traces and isolate the bottleneck.

Option B focuses on errors and generic metrics dashboards; it’s useful for monitoring, but it won’t precisely attribute the extra 22+ seconds to a particular downstream call path. Option C proposes performance improvements (pooling/async), but the question asks to identify bottlenecks first, and it also requires code changes and validation without confirming the root cause. Option D requires adding detailed logging statements and then querying logs; this is more development effort and more ongoing log volume/cost than turning on X-Ray and using trace analysis, especially when the intent is bottleneck identification rather than permanent instrumentation.

Therefore, A is the best choice: enable AWS X-Ray for the Lambda function and trace DocumentDB interactions with custom subsegments to quickly and efficiently identify the specific source(s) of increased latency.