easymultiple choiceObjective-mapped

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?

Question 1easymultiple choice
Full 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?

Answer choices

Why each option matters

Good practice is not just finding the correct option. The wrong answers often show the exact trap the exam wants you to fall into.

A

Best answer

Add a statement condition requiring "Bool": {"aws:MultiFactorAuthPresent": "true"} in the role trust policy.

aws:MultiFactorAuthPresent is a built-in IAM condition context key set when the caller authenticated with MFA. Requiring it to be true causes trust policy evaluation to fail for non-MFA sessions.

B

Distractor review

Add a condition requiring "StringEquals": {"aws:PrincipalOrgID": "o-example"} without any MFA condition.

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.

C

Distractor review

Add a statement that denies sts:AssumeRole when the requested role session name contains the text "dev".

Session name values are not a reliable indicator of authentication strength and can be modified by the caller. This does not verify that MFA was used.

D

Distractor review

Require HTTPS by setting a condition on "aws:SecureTransport": "true" in the trust policy.

aws:SecureTransport is used to enforce TLS usage for specific AWS API requests, but it does not enforce MFA or check authentication context. It addresses transport security, not MFA presence during AssumeRole.

Common exam trap

Common exam trap: authentication is not authorization

Logging in proves the user can authenticate. It does not automatically mean the user is allowed to enter privileged or configuration mode. Watch for AAA authorization, privilege level and command authorization details.

Technical deep dive

How to think about this question

This kind of question is testing the difference between identity and permission. A user may successfully log in to a router because authentication is working, but still fail to enter configuration mode because authorization is missing, misconfigured or mapped to a lower privilege level.

KKey Concepts to Remember

  • Authentication checks who the user is.
  • Authorization controls what the user is allowed to do after login.
  • Privilege levels affect access to EXEC and configuration commands.
  • AAA, TACACS+ and RADIUS can separate login success from command access.

TExam Day Tips

  • Do not assume successful login means full administrative access.
  • Look for words such as cannot enter configuration mode, privilege level, authorization or command access.
  • Separate login problems from permission problems before choosing the answer.

Related practice questions

Related SAA-C03 practice-question pages

Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.

More questions from this exam

Keep practising from the same exam bank, or move into a focused topic page if this question exposed a weak area.

FAQ

Questions learners often ask

What does this SAA-C03 question test?

Authentication checks who the user is.

What is the correct answer to this question?

The correct answer is: Add a statement condition requiring "Bool": {"aws:MultiFactorAuthPresent": "true"} in the role trust policy. — To require MFA for sts:AssumeRole, the trust policy must check whether MFA was used during the caller’s authentication. Option A uses the standard trust-policy condition key aws:MultiFactorAuthPresent set to true. This condition is evaluated during AssumeRole trust evaluation and prevents non-MFA sessions from being able to assume the role, regardless of who they are. Why others are wrong: Option B may restrict who can assume the role but does not enforce MFA. Option C uses a session-name pattern, which is not an authorization signal for MFA and can be bypassed. Option D (SecureTransport) concerns transport (TLS) rather than MFA authentication context, so it does not satisfy the stated MFA requirement.

What should I do if I get this SAA-C03 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.

Discussion

Loading comments…

Sign in to join the discussion.