A media company lets external editors upload large videos directly to S3 and lets a partner analytics role read specific prefixes for two hours. Long-lived access keys were leaked last month. Which temporary credential mechanism should the engineer configure to enable secure time-bound uploads and cross-account reads?

The correct response pairs two temporary least-privilege mechanisms matching both access patterns: S3 presigned URLs let application logic delegate scoped time-limited PUTs so large videos go directly to S3 without distributing AWS keys to editors, while cross-account STS assumption lets the partner assume a constrained role for only specific prefixes with a session capped at two hours, eliminating dependence on leaked long-lived keys. Federation through AssumeRoleWithSAML with 12-hour sessions is a sound enterprise pattern but fails the explicit time bound, since extended duration prolongs exposure and violates the required two-hour analytics window. Cognito identity pools with replication to a partner bucket is common for external temporary credentials, yet it fails the in-place scoped read requirement because replication persistently copies objects rather than granting ephemeral prefix access, creating residual data, cost and governance drift. An EC2 proxy using an instance role for PUTs is a common ingestion pattern but fails delegation because an instance profile is bound to one account and cannot be assumed cross-account or by external editors, forcing proxied traffic with no temporary credentials issued. As an exam caveat, separate credential vending from cross-account delegation, remembering only STS AssumeRole grants cross-account access while presigned URLs, Cognito vending and instance roles remain same-account mechanisms. As a practical check, verify CloudTrail AssumeRole duration and prefix scope, test presigned URL expiry and PUT-only scope, and confirm no active user keys support these flows.