SAA-C03 Design Secure Architectures 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.

• ✗

  API keys only

  Why it's wrong here

  API keys are static, shared secrets that merely identify a client project for usage plans, throttling, and quota tracking; they do not prove the identity of an end user. Because the key is sent in the request header and can be replayed by anyone who obtains it, it is not a secure authentication factor for a public B2B file exchange. API Gateway does not validate any OIDC token claims when using API keys, so they cannot enforce per-user authorization. Therefore, API keys alone are fundamentally inadequate for authenticating internet users.

• ✗

  IAM authorization for all internet users

  Why it's wrong here

  IAM authorization is designed for AWS principals—IAM users, roles, or federated identities—that must sign requests with AWS Signature Version 4 using long-term or temporary AWS credentials. General internet users of a public API do not possess IAM credentials, and distributing static AWS keys to external clients would create a severe security risk. Moreover, SigV4 signing is impractical for typical browser-based or third-party OIDC-authenticated clients. Thus, IAM authorization cannot authenticate individual users whose identities come from an external OpenID Connect provider.

• ✓

  JWT authorizer configured for the OpenID Connect issuer

  Why this is correct

  A JWT authorizer in API Gateway validates the RS256 signature, issuer, and audience of a JSON Web Token issued by a trusted OpenID Connect provider, such as Auth0, Okta, or Amazon Cognito User Pools. This authorizer leverages the provider's JWKS endpoint to verify tokens without requiring a custom Lambda authorizer or backend authentication logic, significantly reducing operational overhead. Additionally, it can map claims from the token into the request context, enabling fine-grained routing or scope-based restrictions. This directly meets the need to authenticate public API users who already hold OIDC-issued access tokens.

• ✗

  A VPC endpoint policy

  Why it's wrong here

  A VPC endpoint policy controls which AWS principals and actions are permitted to use a particular VPC endpoint when accessing a service from inside a VPC—it is an IAM-based resource policy for private network connections. It does not validate user identities, tokens, or OIDC claims, and it applies only to traffic routed through the endpoint, not to the public internet path. Since the B2B API is explicitly public, internet requests will never traverse the VPC endpoint, so the policy would have no effect on them. Therefore, a VPC endpoint policy cannot authenticate or authorize external end users.

Go deeper

Related to this question