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 develop

Question

Options

• ACreate a WebSocket API and the /auth route. Configure and attach the JWT authorizer to the
• BCreate a WebSocket API and the /auth route. Create and configure an AWS Lambda authorizer.
• CCreate an HTTP API and the /auth route. Create and configure an AWS Lambda authorizer.
• DCreate an HTTP API and the /auth route. Configure the JWT authorizer. Attach the JWT

• A
  9% (2)
• B
  18% (4)
• C
  5% (1)
• D
  68% (15)

Explanation

Option D is correct because Amazon API Gateway HTTP APIs have a native, built-in JWT authorizer that requires zero custom code - you simply configure the issuer and audience, attach it to a route, and it handles token validation automatically. This perfectly satisfies both the "built-in authorizer" and "no custom logic" requirements.

Why the distractors fail:

• A & B use a WebSocket API, which does not support JWT authorizers natively - WebSocket APIs are designed for persistent, two-way connections, not REST-style auth flows.
• B & C use a Lambda authorizer, which requires you to write and maintain custom authorization code - directly violating the "avoid managing code with custom logic" requirement.
• C has the right API type (HTTP) but the wrong authorizer type (Lambda), making it the most tempting wrong answer.

Memory tip: Think "HTTP API = JWT for free." The built-in JWT authorizer is an HTTP API-exclusive feature in API Gateway. If you see "built-in," "no custom code," and "JWT" together in a question, that combination points exclusively to an HTTP API with a native JWT authorizer - not REST APIs, not WebSocket APIs, and never Lambda authorizers.

No community discussion yet for this question.