mediummultiple choiceObjective-mapped

Your organization uses IAM permission boundaries to prevent privilege escalation. A deployment role was created with a permission boundary. After an incident, you discover that an operator was later able to remove or change the permission boundary (the operator has iam:PutRolePermissionsBoundary permissions). You need to ensure operators cannot remove or change the permission boundary after it is set. What is the best security control to add?

Question 1mediummultiple choice
Full question →

Your organization uses IAM permission boundaries to prevent privilege escalation. A deployment role was created with a permission boundary. After an incident, you discover that an operator was later able to remove or change the permission boundary (the operator has iam:PutRolePermissionsBoundary permissions). You need to ensure operators cannot remove or change the permission boundary after it is set. What is the best security control to add?

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

Distractor review

Grant operators iam:PutRolePermissionsBoundary so they can reapply the boundary if needed.

Allowing iam:PutRolePermissionsBoundary gives operators the ability to modify the permission boundary, which directly contradicts the goal of preventing boundary removal or changes.

B

Best answer

Add an explicit IAM Deny for operators on both iam:PutRolePermissionsBoundary and iam:DeleteRolePermissionsBoundary for all affected roles.

An explicit Deny prevents permission boundary updates or removal, even if the operator has allow permissions elsewhere. This directly protects the permission boundary integrity and maintains the privilege-limiting guardrail.

C

Distractor review

Rely only on the role’s trust policy so operators cannot assume the role.

The trust policy controls who can assume the role. It does not prevent operators from changing the role’s permission boundary, which can enable privilege escalation for future role usage.

D

Distractor review

Attach a more permissive permission boundary so the roles remain functional after changes.

Making the boundary more permissive undermines the purpose of the control and does not stop operators from removing or changing the boundary.

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 an explicit IAM Deny for operators on both iam:PutRolePermissionsBoundary and iam:DeleteRolePermissionsBoundary for all affected roles. — If an operator can call iam:PutRolePermissionsBoundary (and possibly iam:DeleteRolePermissionsBoundary), they can remove or change the permission boundary after role creation. The strongest control is to add an explicit IAM Deny for those actions against the relevant operators and roles. Because IAM explicit Deny overrides any Allow, it prevents boundary tampering and keeps the permissions cap in effect. Option A enables the exact modification capability you must prevent. Option C does not protect the boundary; it only affects role assumption. Option D relaxes the boundary rather than preventing its removal or alteration, defeating the prevention goal.

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.