A photo-sharing app lets authenticated users upload directly to S3 and lets support view private objects for 15 minutes without IAM credentials. The design must avoid long-lived keys and enforce least privilege per object. Which temporary credential mechanism meets both upload and support needs?

The correct design pairs federated write authorization with signature-based read delegation because Cognito identity pools exchange authenticated tokens for short-lived STS credentials scoped to user-specific prefixes for direct S3 PutObject, satisfying no long-lived keys and per-object least privilege, while S3 presigned URLs embed authentication and a fixed expiry such as 900 seconds so support can GET a private object with no IAM identity, matching the 15-minute requirement. The persistent bucket-wide IAM read approach for support fails temporal and object-level least privilege because it grants reusable identity-based access to all objects rather than a single expiring URL without credentials. The backend proxy with EC2 instance roles avoids static keys and centralizes checks yet violates the direct-to-S3 fact, increasing latency, cost and throughput limits. The STS AssumeRole issuance for support provides temporary credentials yet still distributes bearer IAM material requiring handling and broader scope, missing the credential-free delegation. On exams distinguish Cognito user pools for authentication from identity pools for STS authorization and distinguish role assumption from URL signing with attention to maximum durations. Practically verify prefix-scoped PutObject, generate a 900-second URL, confirm access succeeds then denies after expiry and signing-role revocation, and audit with CloudTrail.