How to configure a built-in JWT authorizer on an Amazon API Gateway HTTP API?

A developer is working on a new authorization mechanism for an application. The developer must create an Amazon API Gateway API and must test JSON Web Token (JWT) authorization on the API. The developer must use the built-in authorizer and must avoid managing the code with custom logic. The developer needs to define an API route that is available at /auth to test the authorizer configuration. Which solution will meet these requirements?

  1. Create a WebSocket API and the /auth route. Configure and attach the JWT authorizer to the API. Deploy the API.
  2. Create a WebSocket API and the /auth route. Create and configure an AWS Lambda authorizer. Attach the Lambda authorizer to the API. Deploy the API.
  3. Create an HTTP API and the /auth route. Create and configure an AWS Lambda authorizer. Attach the Lambda authorizer to the /auth route. Deploy the API.
  4. Create an HTTP API and the /auth route. Configure the JWT authorizer. Attach the JWT authorizer to the /auth route. Deploy the API. Source Reference Answer

Community Votes

D
100%

100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

This question tests the distinction between HTTP APIs and WebSocket APIs regarding native JWT authorizer support, and between built-in JWT authorizers and custom Lambda authorizers.

Amazon API Gateway HTTP APIs support a built-in JWT authorizer that validates tokens issued by an OIDC or OAuth 2.0 provider without requiring custom code. WebSocket APIs do not support the native JWT authorizer, and Lambda authorizers require managing custom logic.

Candidates often choose option C (HTTP API with Lambda authorizer) because Lambda authorizers are widely used, but the requirement explicitly says to avoid managing custom code, which eliminates Lambda authorizers.

Community Discussion (4 comments)

e886835 👍 1 Selected: D
To test JWT authorization using the built-in capabilities of Amazon API Gateway, you should create an HTTP API, configure the JWT authorizer, and attach it to the /auth route.
xdeveloper 👍 1 Selected: D
WebSocket APIs in API Gateway do not support the built-in JWT authorizer. This option is invalid. Lambda authorizers require custom code, which contradicts the requirement to avoid managing custom logic.
ShakthiGCP 👍 1 Selected: D
It narrow downs to C and D . But for C , we need to create a Lambda function , whereas for D - JWT authorizer, it uses the token.
Dahlia9524 👍 3 Selected: D
not needs interactive chat like communication to verify the token. So no web-socket?

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

The correct answer is D. The scenario has three key constraints: (1) test JWT authorization, (2) use the built-in authorizer, and (3) avoid managing custom logic. Amazon API Gateway HTTP APIs natively support a JWT authorizer that validates tokens issued by any OIDC- or OAuth 2.0-compliant identity provider. You simply configure the authorizer with the issuer URL and audience, then attach it to a route such as /auth. No code, no Lambda, no deployment of custom logic is required.

Why the other options are wrong:

  • Option A uses a WebSocket API. WebSocket APIs in API Gateway do not support the built-in JWT authorizer; they only support Lambda authorizers for custom authentication. Therefore this option cannot meet the "built-in authorizer" requirement.
  • Option B also uses a WebSocket API and a Lambda authorizer. This violates both constraints: WebSocket APIs lack native JWT support, and a Lambda authorizer requires you to write and manage custom code.
  • Option C uses an HTTP API (correct API type) but attaches a Lambda authorizer. While functional, a Lambda authorizer requires you to author, deploy, and maintain a Lambda function that parses and validates the token — directly contradicting the requirement to avoid managing custom logic.
Community commenters consistently highlighted that the phrase "avoid managing the code with custom logic" is the decisive clue that eliminates every Lambda-authorizer option, and that WebSocket APIs simply do not offer a native JWT authorizer, narrowing the choice to D.

Official Reference

Exam Strategy

When a question says "built-in" and "no custom logic," immediately eliminate every option that mentions a Lambda authorizer. Then check whether the chosen API type (HTTP vs. WebSocket vs. REST) actually supports the native feature in question.

Related Analysis

A company maintains a REST service using Amazon API Gateway

A-Grade

A company has implemented a pipeline in AWS CodePipeline. Th

A-Grade

A developer is building an application that will use an Amaz

A-Grade

Practice All DVA-C02 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DVA-C02 Practice Test →

← Back to DVA-C02 Study Guide