easymultiple choiceObjective-mapped

Account A hosts an IAM role (RoleInAccountA). The trust policy in Account A correctly allows a specific principal from Account B to call sts:AssumeRole. However, when Account B’s application calls sts:AssumeRole, it receives an AccessDenied error. What is the most likely missing requirement in Account B?

Question 1easymultiple choice
Full question →

Account A hosts an IAM role (RoleInAccountA). The trust policy in Account A correctly allows a specific principal from Account B to call sts:AssumeRole. However, when Account B’s application calls sts:AssumeRole, it receives an AccessDenied error. What is the most likely missing requirement in Account B?

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

Account B’s calling principal must have an identity-based policy that allows sts:AssumeRole on RoleInAccountA’s role ARN.

Cross-account role assumption is authorized on both sides: the trust policy allows who can assume, and the caller’s identity policy must allow sts:AssumeRole on the target role ARN.

B

Distractor review

Account A must attach an S3 bucket policy statement to allow sts:AssumeRole from Account B.

S3 bucket policies do not control STS AssumeRole. STS authorization is evaluated using the target role’s trust policy and the caller’s identity-based permissions (plus any applicable permissions boundaries/SCPs).

C

Distractor review

Account B must add kms:Decrypt permissions to the caller to satisfy AssumeRole.

kms:Decrypt is only relevant when decrypting KMS-encrypted data. AssumeRole authorization does not require KMS decrypt permissions.

D

Distractor review

Account B must create an SCP in the organization to allow sts:AssumeRole.

SCPs can restrict allowed actions, but if a trust policy is already correct, the most common reason for AccessDenied is missing identity-based sts:AssumeRole permissions in Account B. SCPs typically produce explicit denies when they block an action, not the standard missing-permission scenario described here.

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: Account B’s calling principal must have an identity-based policy that allows sts:AssumeRole on RoleInAccountA’s role ARN. — For cross-account AssumeRole, AWS authorization is evaluated in two places: (1) the IAM role’s trust policy in Account A must allow the calling principal, and (2) the calling principal in Account B must have an identity-based permission that allows sts:AssumeRole for the specific target role ARN. Since the trust policy is already correct, the most likely missing requirement is the caller’s identity permission to call sts:AssumeRole. B is unrelated to STS authorization. C introduces an unrelated KMS permission that does not govern AssumeRole. D suggests an SCP change; SCPs restrict, but the scenario most directly matches a missing sts:AssumeRole permission on the caller in Account B.

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.