A media firm shares 50GB video previews with external partners for 48 hours without creating IAM users, while an EC2 app needs S3 access without static keys. Which temporary credential mechanisms should the architect configure for secure access?
Select an answer to reveal the explanation.
Short Explanation
You're handing out visitor badges that expire on their own. Presigned URLs plus roles give short-lived access without ever sharing master keys.
Full Explanation
The correct design pairs S3 presigned URLs with EC2 instance role because both provide temporary access without IAM users or static keys. A presigned URL embeds a SigV4 signature and an expiry of up to seven days, but it never outlives the credentials that signed it, so a URL signed with short-lived role credentials ends when that session does; the signer must therefore be a credential that lasts at least 48 hours (such as a dedicated signing identity), after which external GET of 50GB objects works for the full window, while instance profile delivers rotating STS credentials via metadata, letting app call S3 without stored secrets. The one-hour expiry variant fails on lifetime concept: mechanism is right but one hour breaks required 48-hour window and forces reissue. The EKS IRSA variant fails on principal concept: IRSA federates Kubernetes OIDC for pods, correct for EKS but provides nothing to EC2 host process requiring trust by ec2.amazonaws.com and instance profile. The cross-account AssumeRole variant fails on identity concept: it is best practice for multi-account access but requires partners to hold IAM principals to assume role, violating no-IAM-user constraint. For exams distinguish S3 presigned URLs for object access, CloudFront signed URLs for distribution, STS for API role assumption, and Cognito for app users. In practice verify by creating URL with 172800 second expiry and testing anonymous GET, plus checking EC2 metadata returns temporary keys and S3 calls succeed with least-privilege role.