Building APIs with API Gateway: DVA-C03 study notes and practice questions
What to know about Building APIs with API Gateway for the DVA-C03 exam, from the Development with AWS Services domain (30% of the exam guide), then 2 free questions to test it. Part of the DVA-C03 study guide.
API Gateway questions in Domain 1 cover the synchronous side of an application: how a client request reaches a backend, what gets checked on the way in and how the response is shaped on the way out.
Choosing the API type
REST API: the feature-rich type. It has request validation, mapping templates, caching, usage plans with API keys and resource policies.
HTTP API: a lower-cost type for simple proxies. It supports JWT authorizers and Lambda or HTTP integrations, but not request validation, caching or usage plans.
WebSocket API: a persistent connection where the backend can push messages to clients.
If the requirement lists validation, caching, API keys or usage plans, the answer is a REST API. If it asks for the cheapest option with JWT authentication only, the answer is an HTTP API.
Request validation
Validation needs two parts: a model, which holds a JSON Schema for the body, and a request validator attached to the method.
A request that fails validation gets a 400 response from API Gateway, and the backend is never invoked. This is the answer when the question asks to reject bad input before it reaches the function.
Validators can check the body, parameters or both.
Transformations
Mapping templates (Apache Velocity Template Language) change the request before it reaches the integration, or the response before it reaches the client.
An integration response mapping can change the status code the client sees, so the backend does not need to change.
Proxy integrations (Lambda proxy) pass the request through unchanged, so the function must return the status code, headers and body. API Gateway does not add CORS headers to proxy responses.
How to choose
Scenario wording
Answer
Reject malformed JSON before the function runs
Model plus request validator on a REST API
Change the status code or body shape without editing the backend
Integration response mapping template
Serve identical responses for repeated requests
Stage cache, with the varying header added as a cache key parameter
Give a partner its own rate and quota
Usage plan with API keys, and API Key Required on the method
Return a large file
Redirect to a presigned S3 URL, since synchronous Lambda responses are limited to 6 MB
Browser clients get “blocked by CORS”
Return the Access-Control-Allow-Origin header from the function behind a proxy integration
Common traps
Caching a response that varies by user without listing the user header as a cache key. One customer then sees another’s data.
Adding a usage plan to a method that does not require an API key. The plan’s limits are tied to keys, so they do not apply.
Expecting caching or resource policies to fix CORS. The browser enforces CORS on the response.
Choosing a WebSocket API for a request-response endpoint.
Using an edge-optimized endpoint when the clients and API share a Region. A Regional endpoint avoids the extra CloudFront hop.
A pricing REST API in Amazon API Gateway returns a different price to each customer, based on the X-Customer-Id request header that the backend function reads.
To cut latency and backend calls, the team turned on stage-level caching for the prod stage with the default time-to-live. Since then, some customers have received another customer's prices.
The API must stay a single API and a single stage, and caching must stay on.
What should the developer change?
Choose one answer.
AA. Set the stage cache time-to-live to 0 seconds so that responses are never cached.
BB. Add X-Customer-Id as a method request header, and mark it as a cache key parameter on the method.
CC. Create one API stage for each customer, each with its own cache, and route every customer to their own stage.
DD. Create an API key and usage plan for each customer, so that API Gateway keeps a separate cache for each API key.
Show the answer and explanation
Answer: B
A. Wrong: A time-to-live of 0 turns caching off. Customers would stop seeing each other's prices, but the team would lose the latency and cost savings it turned caching on for.
B. Right: Correct. Cache key parameters decide which requests share a cached response. Adding the header as a key makes API Gateway cache each customer's response separately, so caching stays on.
C. Wrong: Separate caches would stop the leak, but one stage per customer breaks the single-stage requirement and adds a lot of operational work as the customer list grows.
D. Wrong: Usage plans control throttling and quotas for each API key. They do not partition the response cache, so the cache would still return one customer's response to another.
Explanation
API Gateway caches responses under a key made from the method's cache key parameters, and the default time-to-live is 300 seconds. Because the customer header was not a cache key, one customer's cached price was returned to others. Declaring the header as a cache key parameter fixes this while keeping caching on; a time-to-live of 0 disables caching, and API keys and usage plans do not change cache keys.
A payments team exposes a POST /refunds method in an Amazon API Gateway REST API, which invokes a Lambda function.
Every refund must include an orderId string and an amount number in its JSON body. Partner systems often send requests without amount, and each one currently runs the function, which fails and is billed.
The team wants API Gateway to return a 400 error for these requests without invoking the function.
Which TWO actions should the developer take? (Choose two.)
Choose two answers.
AA. Create a model with a JSON schema that lists orderId and amount as required properties.
BB. Add a mapping template to the integration request that removes any field that is empty.
CC. Attach a request validator that checks the body, and set the model on the method request.
DD. Create a usage plan with API keys and require an API key on the POST method.
EE. Turn on detailed CloudWatch metrics for the stage so that the failed requests can be counted.
Show the answer and explanation
Answers: A, C
A. Right: Correct. A model holds the JSON schema that the request body must match. Body validation checks each request against the schema's required properties.
B. Wrong: Mapping templates reshape the payload sent to the backend. They run after the method has accepted the request, so they cannot return a 400 response.
D. Wrong: Usage plans control which clients may call the API and how often. They do not inspect the request body, so bad requests still reach the function.
E. Wrong: Metrics show how often the problem happens but do not stop the requests. The function would still be invoked for each bad request.
Explanation
Body validation in API Gateway needs two parts: a model, which holds the JSON schema, and a request validator assigned to the method. A request that fails validation receives a 400 response from API Gateway, so the backend function is never invoked.
Want more on Building APIs with API Gateway? The 5 full-length practice sets have 10 more Building APIs with API Gateway questions, 390 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →