DVA-C02 Security Practice Question
A developer is using Amazon API Gateway with a Lambda authorizer to secure a REST API. The developer wants to pass user context from the authorizer to the backend Lambda function. How should the developer accomplish this?
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
✓
Return a context object from the Lambda authorizer that maps to integration request parameters.
The Lambda authorizer can return a context object alongside the IAM policy. This context object can be mapped to integration request parameters (such as headers or path parameters) using API Gateway's mapping templates or passthrough behavior. The backend function then receives the user context via those parameters. Option D is correct because returning a context object from the authorizer and mapping it to integration request parameters is the standard method. Option A is incorrect because the principal identifier is a single field, not suitable for passing multiple context values. Option B is incorrect because the authorization token is the input to the authorizer, not the output. Option C is incorrect because custom headers are not automatically mapped to resource path parameters; such a mapping would not pass user context from the authorizer.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Include the user context in the principal identifier returned by the authorizer.
Why it's wrong here
The principal identifier is a mandatory string field in the Lambda authorizer's output, primarily used for caching the authorization policy and for logging purposes. It serves as a unique key to identify the authenticated user or scope, but it is not designed to carry complex, structured user context or multiple data points to the backend integration. Attempting to embed a JSON object or multiple values within this single string would be an anti-pattern and impractical for consumption by the backend.
- ✗
Encode the user context in the authorization token.
Why it's wrong here
The authorization token is an input provided by the client in the request header (e.g., Authorization: Bearer <token>) to API Gateway, which then passes it to the Lambda authorizer for validation. The authorizer's role is to process this token and return an authorization policy, along with any derived context. The original client-provided token is never directly forwarded to the backend integration, meaning any user context encoded within it would not reach the downstream service.
- ✗
Use a custom header that maps to a resource path parameter.
Why it's wrong here
Resource path parameters are integral components of the API's URL structure, used by API Gateway for routing requests to specific resources and actions within the API. While custom headers can indeed be mapped to various integration request parameters, mapping them specifically to a *resource path parameter* would incorrectly conflate data passing with API routing logic. The authorizer's derived context is meant for the backend business logic, not for defining the resource path itself.
- ✓
Return a context object from the Lambda authorizer that maps to integration request parameters.
Why this is correct
The Lambda authorizer's output includes an optional `context` object, which is a key-value map designed specifically for passing arbitrary, trusted information to the backend integration. API Gateway automatically makes the properties within this `context` object available for mapping to various integration request parameters, such as HTTP headers, query string parameters, or even parts of the request body. This mechanism ensures that validated user context, like user ID or roles, is securely and explicitly delivered to the downstream service.
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.