A developer is troubleshooting an application. The application includes several AWS Lambda functions that invoke an Amazon API Gateway API. The API Gateway's method request is set up to use an Amazon

Question

Options

• AModify the client GET request to include a valid API key in the Authorization header.
• BModify the client GET request to include a valid token in the Authorization header.
• CUpdate the resource policy for the API Gateway API to allow the execute-api:Invoke action.
• DModify the client to send an OPTIONS preflight request before the GET request.

• A
  5% (2)
• B
  82% (32)
• C
  3% (1)
• D
  10% (4)

Explanation

When API Gateway uses a Cognito authorizer, it expects a valid JWT token (issued by Cognito) in the Authorization header - not a raw user ID. Passing just the user ID fails Cognito's token validation, causing the 403, so the fix is to pass the actual Cognito-issued token (B).

Why the distractors are wrong:

• A - API keys belong to Usage Plans, not Cognito authorizers; mixing these up is a classic trap.
• C - A resource policy controls which principals/IPs can reach the API at all; the request is already reaching the authorizer, so the 403 is an auth failure, not an access policy block.
• D - OPTIONS preflight is a CORS concept for browsers; Lambda-to-API Gateway calls don't require it, and it wouldn't fix an authorization failure anyway.

Memory tip: Think of the Authorization header like a bouncer's checklist - Cognito is the bouncer and only accepts a signed ticket (JWT token) from its own box office. Handing the bouncer your name (user ID) instead of the ticket gets you a 403 every time.

No community discussion yet for this question.