SAA-C03 Practice Question 42: IAM Permissions Boundary
AWS Certified Solutions Architect – Associate (SAA-C03) · Test 5 · question 2 of 10
A platform team wants application developers to create IAM roles for their own Lambda functions so they stop filing tickets. The developers must not be able to create a role with more privilege than they themselves hold, and must not be able to escalate by attaching AdministratorAccess to a role they create. The control must apply to roles the developers create, not only to the developers themselves, and it must not require the platform team to review each role.
What should the solutions architect implement?
Show answer and explanation
Answer:
A permissions boundary is a managed policy that sets the *maximum* permissions an identity can have. The effective permissions of a role are the intersection of its policies and its boundary, so a developer can attach AdministratorAccess to a role they create and it still grants nothing beyond the boundary. Conditioning the developers' iam:CreateRole permission on iam:PermissionsBoundary (and denying them the ability to delete or change that boundary) makes the constraint self-enforcing on every role they create, with no review step. This is the documented pattern for delegating role creation safely.
Option A detects escalation after it has happened. A daily Config check leaves a window in which an over-privileged role exists and is usable, and it puts the platform team back in the review loop the requirement removes.
Option C meets the security goal by cancelling the business goal. Denying iam:CreateRole returns the developers to filing tickets, which is the problem being solved.
Option D is a different delegation model that does not satisfy the requirement. iam:PassRole lets developers attach roles the platform team already built; it does not let them create roles, so the ticket queue remains.
Reference: Permissions boundaries for IAM entities