Add an aws:MultiFactorAuthPresent condition to the role's trust policy for MFA-gated assumption
Short answer
B Add an aws:MultiFactorAuthPresent condition to the role's trust policy so only MFA-authenticated principals can assume it.
Question
Key Takeaways
Role assumption is governed by the role's trust policy, so the MFA condition belongs there (B). A permissions policy (A) controls what the role can do after assumption, not who can assume it. A session policy (C) is passed at assumption time and further restricts, but the gate must be in the trust policy. An S3 bucket policy (D) controls bucket access, not role assumption. B is correct.
IAM users in Account B assume a role in Account A to upload documents, and the new rule requires MFA. The trust policy of the role controls who can assume it, so add an aws:MultiFactorAuthPresent condition (or aws:MultiFactorAuthAge) to that trust policy—then only principals authenticated with MFA can assume the role. This is the minimal-risk, minimal-effort change and sits at the correct policy layer.
Common mistake: Putting the condition in the role's permissions policy (A)—that restricts post-assumption actions, not the act of assuming, so MFA would not be enforced at assumption. Using a session policy (C)—it can further narrow permissions but the MFA gate must be in the trust policy that decides who may assume. An S3 bucket policy (D) governs bucket access, irrelevant to role assumption.
Expert Analysis
Why the Answer Is Correct
A role's trust policy determines which principals are permitted to assume it. Adding the aws:MultiFactorAuthPresent condition to that trust policy ensures only MFA-authenticated sessions can assume the role, enforcing the new requirement with minimal change and lowest risk. The condition is evaluated at assumption time, which is exactly the gate required.
Why the Other Options Are Wrong
A puts the condition in the permissions policy, which controls what the role can do after it is assumed, not whether MFA was used to assume it. C uses a session policy passed at assumption, which further restricts permissions but does not by itself enforce MFA at the trust boundary. D edits the S3 bucket policy, which governs bucket access, not role assumption. B is correct.
Community Comment Notes
Community voted B (100). Commenters framed the trust policy as the 'resource policy for the IAM role' and noted the MFA condition must be on it so only MFA-authenticated users can assume the role. B confirmed.
Official Reference
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html
This link opens the official vendor documentation in a new tab.
Community Votes
100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 3 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 3
-
mikelord 👍 3Option B is the correct answer because adding the aws:MultiFactorAuthPresent condition to the role's trust policy enforces MFA for role assumption, ensuring that only users who have authenticated with MFA can assume the role. This solution meets the requirement effectively and with minimal changes.
-
723993f 👍 1 Answered BI think about Trust policy as a "Resource Policy" for IAM role, just as a matter of understanding and remembering, not how AWS wants us to think about it so just like any other resource where we add a resource policy (if available) when you want to protect the resource, you do the same for iam role
-
TareDHakim 👍 1 Answered BChatGPT Explanation: The trust policy determines who can assume the IAM role. Adding an aws:MultiFactorAuthPresent condition to the trust policy ensures that only sessions authenticated with MFA can assume the role.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.