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.

• ✓

  JWT authorizer configured for the OpenID Connect issuer

  Why this is correct

  A JWT authorizer is the correct choice because it natively validates RS256-signed OAuth2/OIDC tokens against the issuer's JSON Web Key Set (JWKS) without requiring custom Lambda code. For a financial reporting platform, it lets you use an existing enterprise identity provider (e.g., Auth0, Okta, Microsoft Entra ID) so users authenticate with standard SSO, and you can enforce per-user scopes and claims. API Gateway automatically checks token expiry, issuer, and audience, giving low operational overhead while keeping authentication separate from application logic.

• ✗

  IAM authorization for all internet users

  Why it's wrong here

  IAM authorization relies on AWS Signature Version 4 and requires callers to possess valid AWS credentials, which are intended for AWS principals such as IAM users, roles, or federated identities—not for arbitrary internet users of a public financial API. You would have to issue IAM credentials to every external customer, creating insecure credential distribution and making it impossible to leverage a customer-managed OIDC identity provider. While IAM is appropriate for service-to-service calls within AWS, it is not a viable authentication mechanism for an open public API consumed by non-AWS users.

• ✗

  API keys only

  Why it's wrong here

  API keys are designed for identifying consumers for usage plans, quotas, and throttling, but they do not authenticate a user's identity or verify any claims about the caller. An API key is essentially a shared secret that can be easily leaked, copied, or embedded in client code, so any attacker who obtains it gains full access to the financial reporting data. Moreover, API keys do not integrate with OIDC issuers to validate tokens, meaning they cannot support multi-tenant SSO or fine-grained per-user authorization, making them insufficient for secure financial APIs.

• ✗

  A VPC endpoint policy

  Why it's wrong here

  A VPC endpoint policy controls which principals and actions are allowed through a private VPC endpoint, such as a Gateway or Interface endpoint, and it applies only to traffic coming from within a VPC. A public API exposed over the internet is not accessed via a VPC endpoint, so the policy would have no effect on external API users. Even in a mixed architecture, endpoint policies govern network-level access for AWS resources and do not authenticate individual end users or validate OIDC identity tokens, so they cannot replace an API authorizer.

Go deeper

Related to this question