A media firm lets external editors upload 5-GB raw videos directly to S3 without AWS credentials, with uploads limited to one prefix, content-type, and 15 minutes. The app runs on EC2 and must avoid proxying bytes or sharing long-lived keys. Which temporary credential mechanism grants scoped direct upload access?

Correct approach works because S3 presigned POST returns a URL plus signed policy fields for a plain HTTPS form upload without any AWS secret on the client, and S3 itself enforces starts-with prefix, exact Content-Type, content-length range for 5-GB objects, 15-minute expiration, and required server-side encryption, so EC2 only signs policy and never sees bytes or shares long-lived keys. Scoped STS AssumeRole credentials with short expiry look similar but still distribute an access key, secret, and session token that the editor app must use for SigV4 signing, violating the credential-less browser requirement and adding key handling. Presigned PUT URLs also allow direct credential-less upload with expiry, but they authorize one exact key rather than a policy, so they cannot enforce flexible prefix, content-type, and encryption conditions across editor-chosen filenames. Proxying uploads through EC2 with the instance role centralizes validation without sharing keys yet violates the no-proxy constraint and forces large video streams through app bandwidth and timeouts, harming scale and cost. For exams, choose POST policy when multiple conditions must be enforced for anonymous browsers, PUT for a single known key, and STS when the caller can run an SDK. In practice, decode the policy, test rejection of wrong prefix, type, or expired request, and confirm S3 logs show direct client upload.