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.

• ✗

  IAM authorizer

  Why it's wrong here

  An IAM authorizer validates requests using AWS Identity and Access Management (IAM) permissions, typically for users or roles within an AWS account or federated via AWS SSO. While powerful for AWS-native access control, it's less direct for authenticating external users with identity tokens from third-party providers. It requires clients to sign requests with AWS credentials, which isn't the standard approach for many public-facing APIs relying on OpenID Connect or OAuth 2.0.

• ✗

  API key authorizer

  Why it's wrong here

  API key authorizers are designed for client identification and usage plan enforcement, primarily for throttling and metering API access. They do not provide user authentication or authorization based on identity claims, as API keys are static credentials shared among clients. Therefore, they cannot verify a user's identity or grant access based on specific user attributes, failing to meet the requirement of allowing access only to specific authenticated entities.

• ✓

  JWT authorizer configured for the issuer and audience

  Why this is correct

  A JWT authorizer for an HTTP API validates JSON Web Tokens (JWTs) presented by clients, ensuring they are signed by a trusted issuer and intended for the specific API. By configuring the issuer (iss) and audience (aud) claims, the authorizer cryptographically verifies the token's authenticity and its intended recipient. This mechanism precisely controls access by allowing only requests with valid, unexpired tokens from a recognized identity provider, making it ideal for OAuth 2.0 and OpenID Connect flows.

• ✗

  S3 bucket policy

  Why it's wrong here

  An S3 bucket policy defines access permissions for objects stored within an Amazon S3 bucket, controlling who can perform actions like read or write on those objects. This type of policy is entirely unrelated to securing an API Gateway HTTP API endpoint. It cannot be used to authenticate or authorize requests made to an API Gateway, as its scope is limited strictly to S3 resources and not API invocation.