After Cognito login, the parks mobile app must upload photos to each citizen’s own S3 prefix using temporary AWS credentials. Which Cognito capability vends those credentials?
Select an answer to reveal the explanation.
Short Explanation
User pools prove who signed in; identity pools hand out short-lived AWS keys. After login, exchange the token with an identity pool so the phone can PutObject to that citizen’s prefix—not a permanent key baked into the app.
Full Explanation
After Cognito login, uploading photos to each citizen’s own S3 prefix requires temporary AWS credentials, not the user-pool ID/access token alone. A Cognito identity pool (federated identities) exchanges the authenticated user token for short-lived AWS credentials. IAM roles attached to that identity can be scoped so PutObject is allowed only under that citizen’s prefix, which is the supported mobile upload pattern for parks and inspection apps.
User pools alone authenticate users and issue JWTs for API access; those tokens are not permanent AWS access keys for SigV4 S3 calls. Compiling IAM user long-term access keys into the app after signup is insecure, unrotatable at scale, and often over-privileged. Amazon Macie classification jobs discover sensitive data in buckets; they do not vend PutObject credentials to mobile devices.
Exam caveat: map authenticated identities to IAM roles with conditions on cognito-identity.amazonaws.com:sub (or equivalent) so citizen A cannot write citizen B’s prefix. Operational check: obtain identity-pool credentials after login, PutObject under the caller’s prefix successfully, attempt PutObject to another citizen’s prefix, and confirm the second call is denied by the role policy while CloudTrail shows the temporary session—not a long-term IAM user key.