IAM MFA BoolIfExists Condition: Password Change Failure Due to Missing Key
Exhibit
Refer to the exhibit.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123456789012:role/AdminRole"
},
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}Refer to the exhibit. This IAM policy is attached to a user. The user attempts to assume the AdminRole without using MFA. What is the result?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The user cannot assume the role because the Deny statement blocks all actions when MFA is not present
The Deny statement explicitly denies all actions when MFA is not present, overriding the Allow statement. Since the user is not using MFA, sts:AssumeRole is denied. Option A is incorrect because the Deny overrides the Allow. Option C is incorrect because the Deny applies to all actions, including sts:AssumeRole. Option D is incorrect because the Deny, not the Allow, imposes the MFA requirement.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The user can assume the role because the Allow statement grants it
Why it's wrong here
Although the policy contains an Allow statement that grants sts:AssumeRole, IAM authorization evaluates Deny statements before any Allow. An explicit Deny, even one with a condition, overrides every Allow that matches the same action. Because the Deny's condition (MFA not present) is satisfied for this user, the explicit deny supersedes the Allow, so the user cannot assume the role.
- ✓
The user cannot assume the role because the Deny statement blocks all actions when MFA is not present
Why this is correct
The Deny statement applies to all actions, including sts:AssumeRole, because its Action element is the wildcard '*'. Its condition, typically 'aws:MultiFactorAuthPresent' being false, is true for a user who has not authenticated with MFA, so the explicit deny is in effect. Under IAM's evaluation logic, an explicit deny always blocks the request, regardless of any other matching Allow statements, so the role assumption fails.
- ✗
The user can assume the role because the Deny statement does not apply to sts:AssumeRole
Why it's wrong here
It is incorrect to claim the Deny does not apply to sts:AssumeRole; the wildcard Action '*' matches every IAM action, including those in the STS service, so 'sts:AssumeRole' is captured. The Condition on the Deny only determines when the denial is active, not which actions it covers. Since the MFA condition is true (MFA absent), the Deny applies to the AssumeRole call and blocks it, overriding any Allow.
- ✗
The user cannot assume the role because the Allow statement requires MFA
Why it's wrong here
The Allow statement is not the reason the user cannot assume the role; it contains no MFA condition and would otherwise permit sts:AssumeRole. The blocking factor is the separate Deny statement, which applies the MFA condition to all actions. If the Deny were removed, the Allow alone would authorize the role assumption, demonstrating that the Allow is unnecessary to the denial.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SCS-C02 question from scratch — 1,205 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SCS-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SCS-C02 exam.