DVA-C02 Security 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.

• ✗

  Create a Lambda authorizer that checks the token against Cognito.

  Why it's wrong here

  A custom Lambda authorizer can be written to manually decode and validate a Cognito-issued JWT against the user pool's public signing keys, and this approach does work, but it requires the developer to implement token parsing, signature verification, and expiration checks by hand, duplicating logic that API Gateway's built-in Cognito authorizer already provides natively with far less code and maintenance.

• ✗

  Use an IAM authorizer with a policy that allows only Cognito roles.

  Why it's wrong here

  An IAM authorizer validates AWS Signature Version 4 signed requests using IAM credentials, roles, or Cognito identity pool temporary AWS credentials; it does not natively validate Cognito user pool ID or access tokens, so a request carrying a Cognito user pool JWT would be rejected because it isn't a SigV4-signed request at all.

• ✗

  Use a resource policy on API Gateway to restrict by source IP.

  Why it's wrong here

  A resource policy that restricts access by source IP address controls where requests can originate from at the network level, but it performs no validation of user identity or credentials whatsoever, so any client from an allowed IP range could call the API without ever proving they are an authenticated Cognito user.

• ✓

  Configure a Cognito Authorizer on the API Gateway method.

  Why this is correct

  Configuring a Cognito user pool authorizer directly on the API Gateway method tells API Gateway to automatically validate the Authorization header's JWT against the specified user pool's public keys and required scopes before invoking the Lambda backend, requiring zero custom authorization code and rejecting any request lacking a valid token issued by that pool.

Go deeper

Related to this question