SAA-C03 Design Secure Architectures Practice Question
Account A hosts an IAM role that Account B developers must assume for a limited task. You want to require MFA for anyone assuming the role. Which trust policy condition most directly enforces that requirement for sts:AssumeRole?
⚠ Common exam trap
Watch out — candidates often confuse transport-layer security (HTTPS) with authentication-layer MFA, thinking that requiring encrypted communication also enforces multi-factor authentication, but `aws:SecureTransport` only ensures the channel is encrypted, not that the caller proved possession of a second factor.
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
✓
Add a statement condition requiring "Bool": {"aws:MultiFactorAuthPresent": "true"} in the role trust policy.
The `aws:MultiFactorAuthPresent` condition key in the role trust policy directly checks whether the caller authenticated with a valid MFA device before calling `sts:AssumeRole`. When set to "true" with a Bool condition, it enforces that the session must have been established after MFA verification, which is the most direct and standard way to require MFA for role assumption.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Add a statement condition requiring "Bool": {"aws:MultiFactorAuthPresent": "true"} in the role trust policy.
Why this is correct
The aws:MultiFactorAuthPresent context key is a boolean set by IAM to reflect whether the caller authenticated with an MFA device. Adding a condition requiring "Bool": {"aws:MultiFactorAuthPresent": "true"} in the role trust policy ensures that only principals who completed MFA during their own authentication can assume the role. If the caller did not use MFA, the key is either absent or false, and the trust policy evaluation fails, blocking sts:AssumeRole even if the identity is otherwise authorized.
- ✗
Add a condition requiring "StringEquals": {"aws:PrincipalOrgID": "o-example"} without any MFA condition.
Why it's wrong here
Filtering by aws:PrincipalOrgID controls which identities (via organization) can assume the role, but it does not validate whether MFA was used in the authentication flow. Non-MFA sessions from the same org could still satisfy the trust.
When this WOULD be correct
This option would be correct if the question asked: 'Which condition restricts role assumption to principals belonging to a specific AWS Organization?'
- ✗
Add a statement that denies sts:AssumeRole when the requested role session name contains the text "dev".
Why it's wrong here
The role session name is supplied by the caller via the RoleSessionName parameter of sts:AssumeRole and can be set to any arbitrary string. It is not an AWS-generated indicator of authentication strength, so denying assume role when it contains "dev" does not verify whether MFA was used. A caller who authenticated without MFA could simply omit "dev" from the session name or use a different label, bypassing the check entirely while still lacking MFA protection.
When this WOULD be correct
In a scenario where an organization wants to restrict role assumption to only developers (e.g., by requiring the session name to include 'dev' as a naming convention), a condition like this could be used in the trust policy to allow or deny based on session name.
- ✗
Require HTTPS by setting a condition on "aws:SecureTransport": "true" in the trust policy.
Why it's wrong here
The aws:SecureTransport condition key in the trust policy only verifies that the AssumeRole API request was sent over HTTPS/TLS. While HTTPS is a good transport security practice, it does not provide any information about whether the caller used MFA; a non-MFA session can easily make HTTPS requests through the AWS CLI, SDK, or console. Therefore, this condition prevents insecure transport but does not enforce the MFA requirement that the policy needs, leaving the role assumable by non-MFA principals.
When this WOULD be correct
A question asks: 'You need to ensure that all API calls to assume a role are made over encrypted connections. Which condition should you add to the trust policy?' In that case, aws:SecureTransport would be the correct answer.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.
✓Add a statement condition requiring "Bool": {"aws:MultiFactorAuthPresent": "true"} in the role trust policy.Correct answer▾
Why this is correct
The aws:MultiFactorAuthPresent context key is a boolean set by IAM to reflect whether the caller authenticated with an MFA device. Adding a condition requiring "Bool": {"aws:MultiFactorAuthPresent": "true"} in the role trust policy ensures that only principals who completed MFA during their own authentication can assume the role. If the caller did not use MFA, the key is either absent or false, and the trust policy evaluation fails, blocking sts:AssumeRole even if the identity is otherwise authorized.
✗Add a condition requiring "StringEquals": {"aws:PrincipalOrgID": "o-example"} without any MFA condition.Wrong answer — click to see why▾
Why this is wrong here
Option B does not enforce MFA; it restricts the role to principals from a specific AWS Organization, which is unrelated to MFA requirements.
★ When this WOULD be the correct answer
This option would be correct if the question asked: 'Which condition restricts role assumption to principals belonging to a specific AWS Organization?'
Why candidates choose this
Candidates may confuse organizational controls with security requirements like MFA, or think that restricting by organization inherently includes MFA enforcement.
✗Add a statement that denies sts:AssumeRole when the requested role session name contains the text "dev".Wrong answer — click to see why▾
Why this is wrong here
This option denies AssumeRole based on the role session name containing 'dev', which does not enforce MFA. The question specifically asks for an MFA enforcement condition, not a naming restriction.
★ When this WOULD be the correct answer
In a scenario where an organization wants to restrict role assumption to only developers (e.g., by requiring the session name to include 'dev' as a naming convention), a condition like this could be used in the trust policy to allow or deny based on session name.
Why candidates choose this
Candidates might think that restricting session names is a way to control access, but they overlook that the question explicitly requires MFA enforcement, not naming conventions.
✗Require HTTPS by setting a condition on "aws:SecureTransport": "true" in the trust policy.Wrong answer — click to see why▾
Why this is wrong here
Requiring HTTPS (aws:SecureTransport) ensures encrypted transport but does not enforce MFA. The question specifically asks for MFA enforcement, so this condition does not address the requirement.
★ When this WOULD be the correct answer
A question asks: 'You need to ensure that all API calls to assume a role are made over encrypted connections. Which condition should you add to the trust policy?' In that case, aws:SecureTransport would be the correct answer.
Why candidates choose this
Candidates may confuse security best practices (like using HTTPS) with specific MFA requirements, or think that transport encryption implies authentication strength.
Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
About these practice questions
This SAA-C03 question is part of Courseiva's 935-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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 SAA-C03 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 SAA-C03 exam.