Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, confusion often stems from mixing the API Gateway API types and authorizer types—especially JWT (built-in) vs Lambda (custom). In production, understanding that HTTP APIs natively support JWT authorizers, which minimize code management overhead, is essential to simplify secure API development. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
Acme Innovations is building a serverless application that requires a new, standards-based authorization mechanism with minimal custom code maintenance. The lead developer is tasked with creating a secure API endpoint to validate JSON Web Tokens (JWTs). The API should expose a route at /auth solely for testing the authorization configuration. The solution must employ the Amazon API Gateway native authorizer features without resorting to custom Lambda code.
The Requirement: #
Implement an Amazon API Gateway API with a testable /auth route that uses JWT authorization via built-in authorizer support, avoiding custom Lambda authorizers.
The Options #
- A) Create a WebSocket API with the
/authroute. Configure and attach the JWT authorizer to the API. Deploy the API. - B) Create a WebSocket API with the
/authroute. Create and configure a Lambda authorizer. Attach the Lambda authorizer to the API. Deploy the API. - C) Create an HTTP API with the
/authroute. Create and configure a Lambda authorizer. Attach the Lambda authorizer to the/authroute. Deploy the API. - D) Create an HTTP API with the
/authroute. Configure the JWT authorizer. Attach the JWT authorizer to the/authroute. Deploy the API.
Google adsense #
leave a comment:
Correct Answer #
D
Quick Insight: The Developer Imperative #
JWT authorizers are natively supported only on HTTP APIs, providing built-in integration without managing authorizer code yourself. WebSocket APIs do not support the JWT authorizer natively and require Lambda authorizers instead. Using an HTTP API with the JWT authorizer attached directly to your
/authroute enables the simplest and most maintainable approach aligned with exam best practices.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option D
The Winning Logic #
- Amazon API Gateway HTTP APIs support a built-in JWT authorizer that integrates directly with common identity providers (e.g., Cognito, Auth0) using OIDC or JWT tokens. You only need to configure the JWT issuer and audience.
- This approach avoids provisioning and maintaining any custom Lambda authorizer code, significantly reducing complexity and operational overhead.
- Attaching the JWT authorizer directly to the
/authroute ensures that this endpoint requires JWT validation, enabling an effective test of the authorization setup. - WebSocket APIs (Options A and B) do not currently support JWT authorizers natively and require Lambda authorizers. This contradicts the “avoid custom code” constraint.
- Using a Lambda authorizer (Options B and C) introduces custom logic management, which the requirement explicitly forbids.
The Trap (Distractor Analysis): #
- Why not A? WebSocket APIs do not support built-in JWT authorizers; JWT validation must be custom via Lambda authorizers.
- Why not B? Lambda authorizers mean custom code, violating “avoid managing custom logic.”
- Why not C? Same reasoning as B; Lambda authorizer requires custom logic. Moreover, HTTP APIs enable native JWT authorizers, making Lambda unnecessary and overcomplicated.
The Technical Blueprint #
Code Snippet: Attaching JWT Authorizer to HTTP API Route via AWS CLI #
# Create JWT authorizer for HTTP API
aws apigatewayv2 create-authorizer \
--api-id <your_api_id> \
--authorizer-type JWT \
--identity-source "$request.header.Authorization" \
--jwt-configuration issuer="https://example-issuer.com/",audience="myapp" \
--name MyJWTAuthorizer
# Create /auth route and attach JWT authorizer
aws apigatewayv2 create-route \
--api-id <your_api_id> \
--route-key GET /auth \
--authorizer-id <authorizer_id>
# Deploy the API
aws apigatewayv2 create-deployment --api-id <your_api_id> --stage-name prod
The Comparative Analysis #
| Option | API Type | Authorization Type | Custom Code Required | Resolution | Suitable? |
|---|---|---|---|---|---|
| A | WebSocket API | JWT Authorizer | No | Not Supported (JWT doesn’t work here) | No |
| B | WebSocket API | Lambda Authorizer | Yes | Custom code violates reqs | No |
| C | HTTP API | Lambda Authorizer | Yes | Works but adds custom logic | No |
| D | HTTP API | Built-in JWT Authorizer | No | Simplest, meets all reqs | Yes |
Real-World Application (Practitioner Insight) #
Exam Rule #
“For the exam, always pick HTTP APIs with JWT Authorizer when you see ’native JWT authorization’ without custom code.”
Real World #
“In actual projects, Lambda authorizers might be used to implement complex authorization logic not covered by the built-in JWT authorizer, but that adds operational overhead.”
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.