SAA-C03 Design Secure Architectures Practice Question
A public API for a customer analytics portal is deployed on API Gateway. Clients must authenticate with standards-based tokens issued by an external OpenID Connect provider. Which authorization mechanism should be used? The design must avoid adding custom operational scripts.
⚠ Common exam trap
It's easy for candidates to confuse API keys (which are for rate limiting and usage plans, not authentication) with token-based authorization, or mistakenly think IAM authorization can be used for external users without AWS credentials.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
JWT authorizer configured for the OpenID Connect issuer
A JWT authorizer in API Gateway can validate tokens issued by an external OpenID Connect (OIDC) provider without requiring custom code. The JWT authorizer automatically verifies the token's signature, expiry, and issuer against the OIDC provider's JWKS endpoint, meeting the requirement for standards-based authentication and avoiding custom operational scripts.
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 not identity credentials—they are long-lived tokens tied to a usage plan and a client identifier. They only support throttling and quota tracking, not human authentication or user-level authorization. If a key is embedded in a browser or otherwise leaked, anyone can reuse it, so API keys provide no effective security for a public analytics portal. Thus, they don't meet the requirement to authenticate users.
- ✓
JWT authorizer configured for the OpenID Connect issuer
Why this is correct
This is correct because API Gateway's JWT authorizer validates the RS256 signature, issuer, audience, and expiry of a JWT issued by your customer's OpenID Connect (OIDC) provider. It automatically discovers the provider's JWKS keys through the OIDC discovery endpoint, so no custom Lambda code is required. The verified token claims are then passed to the integration via context, enabling clean, low-operational-overhead authentication for public API users. This directly matches the need to confirm the identity of each caller.
- ✗
IAM authorization for all internet users
Why it's wrong here
IAM authorization requires every request to be signed with AWS Signature V4 using AWS access keys, which are designed for IAM users, roles, or AWS services. Public internet users of a customer portal have OIDC identities, not AWS IAM credentials, so you would need to issue and manage AWS credentials for external users—a severe security risk and operational burden. Additionally, IAM authorizers do not understand third-party OIDC tokens or claims, so they cannot verify the identity of the portal's end users. Therefore, IAM authorization is not suited to this scenario.
- ✗
A VPC endpoint policy
Why it's wrong here
A VPC endpoint policy is evaluated only when traffic reaches the API through an interface VPC endpoint from within a VPC; it does not apply when callers hit the public API endpoint over the internet. This policy governs which AWS principals, actions, and resource ARNs can use that private endpoint, but it does not authenticate users or validate JWT tokens. Because the customer analytics portal is publicly exposed, an endpoint policy is irrelevant to internet-based requests and offers no user-level identity verification.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
One of 935 original SAA-C03 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.