Why Does API Gateway Return 403 When Lambda Sends a User ID to a Cognito Authorizer?
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 Cognito authorizer for authentication. All the Lambda functions pass the user ID as part of the Authorization header to the API Gateway API. The API Gateway API returns a 403 status code for all GET requests. How should the developer resolve this issue?
Community Votes
100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The exam tests whether you know a Cognito authorizer requires a valid JWT in the Authorization header — sending a bare user ID fails token validation and produces a 403 response.
An Amazon API Gateway COGNITO_USER_POOLS authorizer validates a JWT (ID or access token) from Amazon Cognito in the Authorization header, not a plain user ID. The community unanimously (100% of votes) agrees that replacing the user ID with a valid Cognito token resolves the 403 errors.
Many candidates pick C (update the resource policy) because a 403 looks like an IAM permission denial, but the failure occurs at the Cognito authorizer stage because the Authorization header does not contain a valid token, so no policy change will help.
Community Discussion (4 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
A COGNITO_USER_POOLS authorizer in API Gateway expects a JWT — an ID token or access token issued by the Amazon Cognito user pool — in the Authorization header. The Lambda functions are passing only a user ID, which is not a signed token, so the authorizer cannot validate it and API Gateway rejects the request with a 403 status code. Modifying the client GET request to include a valid Cognito token (e.g.,Authorization: Bearer <idToken>) allows the authorizer to verify the signature, issuer, and expiration, and the request succeeds. Community comment [1] demonstrates exactly this fix with a fetch call sending Bearer ${idToken}, and comment [2] confirms that the client must provide a valid token for the Cognito authorizer to work.Why the Other Options Are Wrong
Option A confuses two mechanisms: API keys are used with usage plans and are sent in thex-api-key header, not the Authorization header, and they do not satisfy a Cognito authorizer. Option C addresses resource policies, which control who can invoke the API at the endpoint level (execute-api:Invoke); since the functions are already reaching the API and being rejected by the authorizer, the policy is not the problem. Option D refers to CORS preflight (OPTIONS) requests, which are browser-driven and irrelevant to server-side Lambda-to-API-Gateway calls. Only Option B fixes the actual root cause — an invalid Authorization header value.Community Comment Notes
All four comments agree on answer B, and the vote distribution shows 100% consensus, indicating high confidence in this question. Comment [1] is the most useful because it provides a concrete code snippet showing the GET request with aBearer JWT in the Authorization header. Comment [2] articulates the underlying reasoning: the Cognito authorizer requires a valid token, not a user ID. Comments [3] and [4] simply reinforce the consensus without adding new technical detail. Official Reference
- https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html
- https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html
- https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-id-token.html
Exam Strategy
When a question shows a 403 from API Gateway with a Cognito or Lambda authorizer, immediately inspect what the client places in the Authorization header — it must be a valid JWT, not a user ID, API key, or IAM signature. Map each distractor to its own mechanism: API keys go in x-api-key, CORS uses OPTIONS preflight, and resource policies only matter for endpoint-level invocation permissions. Matching the auth mechanism to the header content quickly eliminates the wrong options.
Related Analysis
Practice All DVA-C02 Questions
Access 100 questions with complete answers and detailed explanations.
View Full DVA-C02 Practice Test →
Bearer ${idToken}, // JWT token 'Content-Type': 'application/json' }; fetch(apiUrl, { method: 'GET', headers: headers }) .then(response => { if (!response.ok) { throw new Error('API request failed'); } return response.json(); }) .then(data => console.log(data)) .catch(error => console.log('Error:', error));