Question

Difficulty: MediumResolving IAM and Authorization Failures

A developer is troubleshooting an application where an Amazon API Gateway REST API is secured using a custom Lambda authorizer. The authorizer validates a JSON Web Token (JWT) in the request header and returns an IAM policy. The Lambda authorizer has caching enabled with a Time to Live (TTL) of 300300 seconds, using the client's `Authorization` header as the cache key.

A client application makes a request to `GET /orders/1` with a valid token and successfully retrieves the resource. Immediately afterward, the same client sends a request to `POST /orders` using the same token. The client receives a HTTP 403 Forbidden response with the message `{"message":"User is not authorized to access this resource"}`. The CloudWatch logs show that the Lambda authorizer was not invoked for the second request.

Which of the following actions should the developer take to resolve this authorization failure? (Select TWO.)

  1. Update the Lambda authorizer function to return an IAM policy that specifies a wildcard in the resource path (e.g., `arn:aws:execute-api:region:account:apiId/stage/*`) to cover all methods and resources the client is permitted to access.Answer
  2. Disable authorization caching by setting the TTL to 00 seconds in the API Gateway console for the Lambda authorizer.Answer
  3. C
    Replace the Lambda authorizer with an API Gateway Cognito User Pool authorizer and pass the same JWT token in the `Authorization` header.
  4. D
    Update the trust relationship of the Lambda function's execution role to allow the `apigateway.amazonaws.com` service principal to assume the role.
  5. E
    Configure the API Gateway API method authorization to require Cognito Identity Pool credentials, and update the client application to sign requests using AWS Signature Version 4.

Answer

Update the Lambda authorizer function to return an IAM policy with a wildcard in the resource path, and disable authorization caching by setting the TTL to 00 seconds in the API Gateway console.
The correct options are to update the Lambda authorizer function to use a wildcard in the resource path of the returned IAM policy, and to disable authorization caching by setting the TTL to 00 seconds. When caching is enabled, API Gateway caches the policy matching the cache key (the token). If the policy restricts access to the exact resource path of the first request (`GET /orders/1`), subsequent requests to other endpoints will fail with a 403 error because the cached policy does not authorize access to the new path. Using a wildcard in the resource path allows the cached policy to authorize other paths, while disabling caching altogether forces API Gateway to run the authorizer for every request.

Step-by-Step Solution

1
Analyze the HTTP 403 response and the CloudWatch logs.
The 403 Forbidden error indicates an authorization failure, and the logs show that the Lambda authorizer was not invoked for the second request, meaning API Gateway is using a cached policy from the first request.
Since the first request succeeded and caching is enabled with a TTL of 300300 seconds, API Gateway cached the policy generated for the `GET /orders/1` resource.
2
Identify why the cached policy blocks the second request.
The cached policy restricts access to the resource of the first request (`GET /orders/1`). When the client attempts to access `POST /orders`, API Gateway evaluates the cached policy and blocks the request because the resource does not match.
By default, API Gateway caches the entire policy for the configured TTL under the specified cache key (the `Authorization` header).
3
Select the correct remediation strategies.
Updating the authorizer code to return a wildcard resource ARN (e.g., `arn:aws:execute-api:region:account:apiId/stage/*`) or disabling caching (setting TTL to 00) resolves the issue.
Wildcards allow the cached policy to apply to all resources in the stage, while disabling caching forces API Gateway to evaluate each request dynamically.

Key Concept

API Gateway Lambda Authorizer Caching Behavior
Estimated Time:2m 0s
Rate this question