A fitness startup builds mobile and web apps requiring email and social sign-in, MFA, and temporary access to S3 photos plus personalized API calls. Backend services run on EKS and need scoped AWS permissions without static keys. Which application authentication design meets these needs?
Select an answer to reveal the explanation.
Short Explanation
You're separating who users are from what they're allowed to touch. User pools handle login and MFA while identity pools vend short-lived creds. Hardcoded keys put your whole bucket at risk.
Full Explanation
The correct design works because user pools provide OAuth 2.0 sign-in for email and federated social identities with enforceable MFA and JWTs for personalized API authorization, while identity pools exchange valid tokens for short-lived scoped credentials for direct S3 access without static keys, leaving EKS backends to use workload identity for their own scoped permissions. The JWT-only user-pools design fails on credential vending, as tokens authenticate API calls well but cannot create SigV4 AWS credentials, so mobile clients gain no direct secure S3 access and must hairpin through proxies. The direct identity-pool federation design fails on managed authentication, as it can mint temporary S3 credentials with fine-grained roles yet offers no directory, email verification, hosted sign-up, or centralized MFA. The proxy-through-EKS design fails on workload versus user identity separation, as Pod Identity correctly scopes backend service permissions without keys but cannot represent external users, losing scalable direct access and per-user scoping. For exams, map MFA and social login to user pools, temporary S3 credentials to identity pools, and cluster service access to Pod Identity without conflating them. Practically, validate a test user with MFA, decode JWT claims, exchange the token for pool credentials, confirm S3 allows only the user prefix and denies after expiry, and audit for any embedded long-lived keys.