DVA-C02 Development with AWS Services Practice Question
A company is using Amazon API Gateway to expose a REST API. The API is integrated with an AWS Lambda function. The developer wants to implement caching to improve performance. Which THREE steps are necessary to enable caching for a specific stage? (Choose THREE.)
⚠ Common exam trap
A common mix-up: candidates think caching requires modifying the Lambda function (Option B) or adding IAM policies (Option A), when in fact API Gateway's stage-level caching is a simple toggle with configurable cluster size and TTL, and no backend changes are needed.
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 API caching in the stage settings.
API Gateway provides built-in caching at the stage level, which can be enabled directly in the stage settings without modifying the Lambda function or adding external services. This caching reduces the number of calls made to the backend Lambda function by serving cached responses for identical requests, improving performance and reducing 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.
- ✗
Attach an IAM policy to the API Gateway role for cache access.
Why it's wrong here
API Gateway's built-in caching mechanism is fully managed by the service itself and does not require explicit IAM permissions for the API Gateway execution role to access the cache. The caching infrastructure operates internally to API Gateway, abstracting away the need for developers to configure or manage underlying resources like ElastiCache or associated IAM policies for cache operations. Therefore, attaching an IAM policy for cache access is an unnecessary and incorrect step for enabling this feature.
- ✗
Modify the Lambda function to store responses in ElastiCache.
Why it's wrong here
Modifying the backend Lambda function to directly store responses in ElastiCache would bypass API Gateway's native caching capabilities entirely. While a Lambda function could implement its own caching logic using ElastiCache, this approach would not leverage or enable the integrated API Gateway caching feature, which is designed to cache responses at the API Gateway layer before invoking backend integrations. This is an alternative caching strategy, not the method for enabling API Gateway's built-in caching.
- ✓
Enable API caching in the stage settings.
Why this is correct
Enabling API caching in the stage settings is the fundamental first step to activate API Gateway's managed caching feature for a specific deployment stage. This action provisions a dedicated cache cluster for that stage, allowing API Gateway to store and retrieve responses for subsequent identical requests without invoking the backend integration. Without explicitly enabling caching at the stage level, no other caching configurations will have any effect.
- ✓
Set a cache time-to-live (TTL) value.
Why this is correct
Setting a cache time-to-live (TTL) value is crucial for controlling the duration for which a cached response remains valid before it is considered stale and must be re-fetched from the backend. The TTL, specified in seconds, dictates the maximum age of a cached item, ensuring that clients receive reasonably fresh data while still benefiting from reduced backend load. A well-chosen TTL balances performance gains with data freshness requirements.
- ✓
Specify a cache cluster size (e.g., 0.5 GB).
Why this is correct
Specifying a cache cluster size, such as 0.5 GB or larger, is a mandatory configuration step when enabling API Gateway caching. This action allocates the necessary memory resources for the dedicated cache cluster that API Gateway provisions for your stage, directly impacting the number and size of responses that can be stored. Choosing an appropriate size ensures sufficient capacity for frequently accessed data, preventing cache evictions and maximizing cache hit rates.
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 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.