mediummultiple choiceObjective-mapped

Your CI system assumes an IAM role RoleForDeploy using STS AssumeRole and includes a session tag called Project=blue. The role’s permissions policy uses an ABAC condition like aws:PrincipalTag/Project to allow access only to resources tagged with the same project.

AssumeRole succeeds, but deployments fail with AccessDenied. CloudTrail shows the role was assumed, yet the effective session does not contain the Project tag.

Which change most directly fixes this issue?

Question 1mediummultiple choice
Full question →

Your CI system assumes an IAM role RoleForDeploy using STS AssumeRole and includes a session tag called Project=blue. The role’s permissions policy uses an ABAC condition like aws:PrincipalTag/Project to allow access only to resources tagged with the same project.

AssumeRole succeeds, but deployments fail with AccessDenied. CloudTrail shows the role was assumed, yet the effective session does not contain the Project tag.

Which change most directly fixes this issue?

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 permissions for sts:TagSession to the IAM role so the CI pipeline is allowed to pass the Project session tag during AssumeRole.

Session tags are not automatically granted; the role needs sts:TagSession permission to allow passing tags into the session.

B

Distractor review

Remove the ABAC condition using aws:PrincipalTag/Project so the policy ignores session tags.

Removing the condition would broaden access and violates the ABAC design that restricts actions to the correct project.

C

Distractor review

Move the aws:PrincipalTag/Project condition into the trust policy so it applies during the AssumeRole call.

Even if conditions exist in the trust policy, the session tags must be allowed and provided. The failure indicates the tag was not populated.

D

Distractor review

Add kms:Decrypt permission to the CI role because missing tags are typically caused by KMS authorization failures.

The observed symptom is that the session tag is missing, not that KMS decryption is denied. These are unrelated controls.

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 permissions for sts:TagSession to the IAM role so the CI pipeline is allowed to pass the Project session tag during AssumeRole. — ABAC based on aws:PrincipalTag requires that the session tag be present in the assumed-role session. When using STS AssumeRole with tags, the role (or calling principal, depending on setup) must allow sts:TagSession; otherwise, the session tags are not passed/available even if AssumeRole succeeds. Adding sts:TagSession enables the CI pipeline to include Project=blue, allowing the permissions policy condition aws:PrincipalTag/Project to match the intended resources. This preserves least privilege without disabling the ABAC logic. Why others are wrong: Option B disables ABAC and would likely allow access across projects. Option C incorrectly assumes moving conditions to the trust policy will populate session tags; trust-policy conditions evaluate what is already present. Option D is a red herring: KMS permissions affect encryption/decryption, not the existence of session tags used by IAM conditions.

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.