DVA-C02 Development with AWS Services Practice Question
A developer is building a mobile backend using Amazon API Gateway and AWS Lambda. The API has a single endpoint that accepts POST requests with a JSON payload and stores the data in an Amazon DynamoDB table. The developer wants to implement caching to reduce latency and costs. The data is user-specific and should not be shared between users. The developer configures API Gateway caching with a TTL of 300 seconds. After testing, the developer notices that users are seeing other users' data. What should the developer do to fix this issue?
⚠ Common exam trap
DVA-C02 often tests the misconception that enabling API Gateway caching automatically isolates data per user, when in fact the default cache key only includes the method and path, leading to cross-user data leakage unless cache key parameters are explicitly configured.
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 cache key parameters in API Gateway, such as the Authorization header.
API Gateway caching by default uses only the request path and method as the cache key, so all POST requests to the same endpoint share a single cache entry. Since the data is user-specific, the cache must include a unique user identifier in the cache key. Enabling cache key parameters (e.g., the Authorization header or a custom user ID header) ensures that each user's request generates a distinct cache key, preventing cross-user data leakage. This is the correct and minimal fix because it directly addresses the root cause—the cache key not being user-specific—while retaining the performance benefits of API Gateway caching.
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 cache key parameters in API Gateway, such as the Authorization header.
Why this is correct
API Gateway's caching mechanism allows developers to specify request parameters, such as headers, query strings, or path parameters, to be included in the cache key. By enabling the Authorization header as a cache key parameter, API Gateway generates a unique cache entry for each distinct Authorization token presented by a user. This ensures that responses are cached on a per-user basis, preventing data leakage between users while still providing the performance benefits of caching for repeated requests from the same authenticated user.
- ✗
Store cached responses in DynamoDB and retrieve them based on user ID.
Why it's wrong here
Storing cached API responses in DynamoDB would introduce significant architectural complexity and increased latency compared to API Gateway's integrated caching. Each cache lookup would require an additional network call to DynamoDB, negating much of the performance benefit of caching. Furthermore, managing cache invalidation, expiration policies, and data consistency within a custom DynamoDB-based caching solution would add substantial operational overhead that API Gateway's managed caching handles natively.
- ✗
Use Lambda@Edge to cache responses at the CloudFront level.
Why it's wrong here
Lambda@Edge operates at the CloudFront content-delivery layer, which caches responses based on HTTP cache headers and request paths, not on per-user authentication context. In this scenario, the API Gateway endpoint receives user-specific data that must never be shared; Lambda@Edge cannot isolate cached responses by individual user identity because it lacks native awareness of the API Gateway authoriser or the DynamoDB partition key. This option is tempting because Lambda@Edge is a valid solution for caching static or region-agnostic content at the edge, such as personalised but non-secret assets like user avatars, where the cache key can include a user identifier in the URL or cookie.
- ✗
Disable API Gateway caching and use DynamoDB Accelerator (DAX) instead.
Why it's wrong here
DynamoDB Accelerator (DAX) is specifically designed to provide an in-memory cache for DynamoDB tables, accelerating read-heavy workloads by caching item data. It operates at the data layer, caching the results of DynamoDB API calls, not the full HTTP responses from an API Gateway endpoint. Therefore, DAX cannot directly cache API Gateway responses or address the requirement for user-specific caching at the API layer, as its purpose is to optimize DynamoDB interactions, not general API caching.
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
This DVA-C02 question is part of Courseiva's 1,135-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
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.