A travel startup builds a mobile app with social sign-in, needs JWTs for APIs plus temporary scoped credentials for direct S3 photo uploads, and runs order jobs on EKS needing AWS API access without stored keys. Which application authentication design using Cognito and Pod Identity meets these needs?
Select an answer to reveal the explanation.
Short Explanation
Different callers need different kinds of keys, and mixing them gets messy. Identity pools trade your login for short-lived AWS credentials cleanly. It's like swapping a concert ticket for a locker key.
Full Explanation
The correct solution separates concerns by using a Cognito user pool as the OIDC and OAuth 2.0 identity provider issuing JWTs for API authorization, a Cognito identity pool federated to that pool and social IdPs to vend scoped temporary AWS credentials for S3 uploads, and Amazon EKS Pod Identity to inject least-privilege IAM roles into Kubernetes service accounts for order jobs without static keys. A user pool alone issues ID and access tokens but cannot vend AWS SigV4 credentials for S3 nor Kubernetes workload identities, so it satisfies sign-in but misses direct resource access. An identity pool alone brokers AWS credentials but does not authenticate users or mint JWTs for APIs, requiring an external provider, so swapping roles violates the JWT requirement. EKS Pod Identity is scoped to pods in EKS clusters, associating IAM roles with Kubernetes service accounts through the Pod Identity Agent, and cannot authenticate mobile users or external OAuth flows, so extending it to phones misses the consumer auth fact. For the exam, remember user pool authenticates humans, identity pool authorizes AWS access, Pod Identity authorizes pods, and in practice verify token expiry, identity pool role mappings and Pod Identity agent configuration.