DVA-C02 Development with AWS Services Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  TOKEN authorizer with the token passed in the Authorization header.

  Why this is correct

  A TOKEN authorizer is specifically designed to receive a single authorization token, typically a JWT, from a designated header like `Authorization`. It passes this token directly to a Lambda function which then decodes and validates it, returning an IAM policy that grants or denies access to API resources. This streamlined approach is ideal for scenarios focused solely on token-based authentication, simplifying the Lambda's input processing by providing just the raw token string.

• ✗

  REQUEST authorizer with the token in a custom header.

  Why it's wrong here

  A REQUEST authorizer receives the entire request, including headers, query strings, and body, but it does not natively decode or validate a JWT token; the developer would have to write custom parsing logic for the token, whereas a TOKEN authorizer automatically extracts and decodes the JWT from the specified header. This option is tempting because a REQUEST authorizer can inspect custom headers, making it suitable for scenarios where access decisions depend on multiple request parameters (e.g., path, query string, or body) rather than solely on a token.

• ✗

  Use Amazon Cognito User Pools as the authorizer.

  Why it's wrong here

  Cognito User Pools can be used directly as an API Gateway authorizer without custom Lambda code if the token is issued by Cognito. However, the requirement specifies a Lambda authorizer that decodes the JWT, implying a custom authorizer is needed.

• ✗

  Use a resource policy to allow or deny access based on the JWT token.

  Why it's wrong here

  API Gateway resource policies operate at the service level, defining access rules based on network-level attributes such as source IP addresses, VPC endpoints, or AWS accounts. They are evaluated before any authorizer and cannot inspect the content of application-layer tokens like JWTs. Therefore, a resource policy cannot perform fine-grained authorization decisions based on claims embedded within a JWT, making it unsuitable for this purpose.