Enforce MFA on S3 CLI access with STS temporary credentials
A solutions architect must provide a secure way for a team of cloud engineers to use the AWS CLI to upload objects into an Amazon S3 bucket. Each cloud engineer has an IAM user, IAM access keys, and a virtual multi-factor authentication (MFA) device. The IAM users for the cloud engineers are in a group that is named S3-access. The cloud engineers must use MFA to perform any actions in Amazon S3. Which solution will meet these requirements?
Community Votes
100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
Long-lived access keys carry no proof of MFA at the time of the call, so the enforcement point has to be a credential issued by AWS STS in an AssumeRole call that presents the MFA code, which yields temporary credentials that the CLI profile then uses.
Cloud engineers must upload objects to an S3 bucket using the AWS CLI with their own IAM user access keys, and every S3 action must require MFA. Each engineer already has a virtual MFA device and belongs to the S3-access group.
Relying on an S3 bucket policy to prompt for MFA. A bucket policy is an authorization control evaluated on the request, and it cannot force the CLI to present an MFA code, so the engineers could still authenticate with plain access keys and never be challenged.
Community Discussion (6 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
A policy attached to the S3-access group denies all S3 actions unless MFA is present in the request context, and the context key it tests is only populated when the credentials were obtained through an AWS STS AssumeRole call that included an MFA code. So the engineer runs get-session-token or AssumeRole supplying the MFA code, receives temporary credentials, and configures those in a CLI profile. Every subsequent S3 call carries the resulting session, and because the session was issued with MFA present, the deny statement's condition is satisfied and the call is allowed. The temporary credentials also expire, which removes the standing long-lived key risk.Why the Other Options Are Wrong
A: An S3 bucket policy is attached to the bucket, not to users, and more importantly a bucket policy cannot prompt for or validate an MFA code, so nothing forces the MFA challenge. B: A trust policy belongs on a role, and a group is not a role that can be assumed, so there is no trust relationship to attach a condition to. C: The deny-unless-MFA policy is correct, but using IAM access keys with the CLI bypasses it, because access key authentication does not produce a session context containing MFA. Only temporary credentials from STS do.Community Comment Notes
The community voted 100 to 0 for D, and the reasoning was consistent: access keys used with the CLI simply skip the MFA requirement, so STS-issued temporary credentials are the only way to make the group policy's MFA condition effective. A commenter linked the AWS documentation on requiring MFA for API operations and another on securing access keys with MFA.Official Reference
Related Analysis
Practice All SAP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full SAP-C02 Practice Test →