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.

• ✗

  A VPC endpoint policy

  Why it's wrong here

  A VPC endpoint policy governs access to the API through a private VPC endpoint, restricting which principals and actions are allowed, but it does not validate the identity of end users calling the public endpoint. Since the API is public, users bypass VPC endpoints entirely, so the policy cannot enforce authentication or verify OIDC tokens; it is purely a network-level access control, not an identity layer.

• ✗

  IAM authorization for all internet users

  Why it's wrong here

  IAM authorization is inappropriate for all internet users because IAM credentials are designed for AWS principals (IAM users, roles, or AWS services), not for arbitrary application users holding OIDC tokens from an external identity provider. To use IAM, each student or educator would need AWS credentials, and the client would have to sign every request with Signature Version 4—an impractical and insecure way to expose a public e-learning API. IAM also fails to integrate with the platform's existing identity provider, whereas a JWT authorizer natively trusts that provider.

• ✗

  API keys only

  Why it's wrong here

  API keys only identify the calling application or project for usage plans, quotas, and throttling; they do not authenticate an individual user's identity or verify any claims about who they are. An API key can be extracted from a client and reused by anyone, so it offers no assurance that the caller is a legitimate student or educator with valid OIDC credentials. For public APIs, API keys are insufficient for security and must be combined with an authentication mechanism such as a JWT authorizer.

• ✓

  JWT authorizer configured for the OpenID Connect issuer

  Why this is correct

  The JWT authorizer configured for the OpenID Connect issuer is the correct choice because it validates the JWT's signature, expiry, issuer, and audience against the OIDC provider's public keys (JWKS), requiring no custom Lambda or additional infrastructure. It integrates directly with any standards-compliant IdP—such as Auth0, Okta, or the platform's existing identity service—so users' existing login tokens are recognized. This approach authenticates every request with low latency and minimal operational overhead while supporting fine-grained scopes and claims for authorization.

Go deeper

Related to this question