DVA-C02 Troubleshooting and Optimization Practice Question
A company has a REST API deployed on Amazon API Gateway with a Lambda integration. The API is experiencing high latency. Which TWO actions would help diagnose the issue?
⚠ Common exam trap
Candidates often confuse performance optimization actions (like increasing Lambda memory or adding CloudFront) with diagnostic actions. The question specifically asks for actions to 'diagnose' the issue, not to resolve it.
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
✓
Use AWS X-Ray to trace requests.
Option A is correct because AWS X-Ray traces the full request path through API Gateway, the Lambda integration, and downstream calls, exposing where latency is introduced (e.g., Lambda cold starts, slow downstream calls) via trace segments and subsegments. Option B is correct because enabling detailed CloudWatch Logs (execution logging and access logging) for the API Gateway stage captures per-request latency metrics such as integrationLatency and responseLatency, helping pinpoint whether the delay is in API Gateway or the Lambda backend. Option C is not a diagnostic action; increasing Lambda memory changes CPU allocation and could improve performance but does not help identify the root cause of latency. Option D is not a diagnostic step and changing the integration type alters architecture rather than measuring where latency occurs. Option E is also a remediation/architecture change (caching and edge termination) rather than a way to diagnose the source of the high latency.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use AWS X-Ray to trace requests.
Why this is correct
AWS X-Ray is a distributed tracing service that provides an end-to-end view of requests as they flow through various services, including API Gateway and Lambda. It generates a service map and detailed trace data, showing the latency incurred at each hop. This allows developers to precisely identify which component – be it the API Gateway's processing, the Lambda function's execution, or a downstream dependency called by Lambda – is contributing most significantly to the overall API latency, making it an ideal diagnostic tool.
- ✓
Enable detailed CloudWatch Logs for the API Gateway stage.
Why this is correct
Enabling detailed CloudWatch Logs for an API Gateway stage provides granular request and response data, including execution latency, integration latency, and backend errors. By analyzing these logs, developers can examine specific requests, understand the duration of each processing step within API Gateway, and determine if the bottleneck lies within the API Gateway's internal processing or the time taken by the backend integration (e.g., Lambda function) to respond. This offers detailed event-level insights into API performance.
- ✗
Increase the Lambda function memory.
Why it's wrong here
While increasing Lambda function memory can sometimes improve performance by allocating more CPU and network bandwidth, it is a mitigation strategy, not a diagnostic one. Without first identifying that the Lambda function itself is the bottleneck due to resource constraints, increasing memory is a speculative change that doesn't help diagnose the root cause of the API's overall latency. The actual problem could be in API Gateway's configuration, network latency, or a downstream service called by Lambda, which memory adjustment wouldn't reveal.
- ✗
Change the API integration type from Lambda to HTTP.
Why it's wrong here
Changing the API integration type from Lambda to HTTP would fundamentally alter the backend architecture, replacing the current serverless function with an HTTP endpoint, potentially on an EC2 instance or another service. This action does not diagnose the existing latency issue; instead, it replaces the entire backend component, introducing a new system with its own potential performance characteristics. This makes it impossible to diagnose the original problem within the current Lambda-backed API Gateway setup.
- ✗
Add Amazon CloudFront in front of API Gateway.
Why it's wrong here
Amazon CloudFront is a Content Delivery Network (CDN) primarily used to cache content closer to users and reduce latency for static assets or API responses that can be cached. While it can improve perceived performance for geographically distributed users by reducing network round-trip times between the client and API Gateway, it does not provide any diagnostic capabilities for internal latency issues within API Gateway or its backend integrations. CloudFront only addresses network latency, not the processing time within the API itself.
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 DVA-C02 question from scratch — 1,135 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 →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DVA-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 DVA-C02 exam.