DOP-C02 Practice Question 40: Permissions Boundary Role Delegation

This is the delegation pattern the IAM documentation describes: "You can use permissions boundaries to delegate permissions management tasks, such as user creation, to IAM users in your account. This permits others to perform tasks on your behalf within a specific boundary of permissions." The iam:PermissionsBoundary condition key makes attaching the approved boundary a precondition of creating the role, so a role created with AdministratorAccess attached still has effective permissions limited to "the intersection of both policy types", nothing outside the boundary works. The two explicit denies close the loop: without them an application team could edit the boundary policy or call DeleteRolePermissionsBoundary and escape it. There is no review queue because the constraint is enforced at the API call.

Option A gives up the goal. Removing self-service is the status quo the platform team is trying to get away from, and it puts the platform team back in the path of every change.

Option B blocks role creation rather than bounding it. Application teams still cannot create roles, so the tickets continue; an SCP denies, it cannot say "you may create roles, but only constrained ones" the way the boundary condition does.

Option D attaches the boundary to the wrong entity and in the wrong role. A permissions boundary "limits the user's permissions but does not provide permissions on its own", and attaching it as an ordinary permissions policy constrains nothing about the roles those teams go on to create.

Reference: Permissions boundaries for IAM entities