A startup lets product teams create IAM roles for microservices but two teams escalated to admin by attaching AdministratorAccess. Security must allow delegation while capping maximum permissions and scoping session privileges. Which least-privilege design should the engineer enforce to allow safe role delegation?

The correct design succeeds because permission boundaries impose a non-bypassable maximum that no identity policy added by product teams can exceed, thereby neutralizing AdministratorAccess attachment, while still permitting delegation through creation conditioned on an approved boundary, and session policies intersect at assumption time to dynamically down-scope effective privileges per microservice call for true least privilege. The alternative combining boundaries with standardized identity policies provides good static hygiene yet misses dynamic session scoping, since identity policies alone cannot narrow each assumed session by context without intersection with a session policy. The alternative combining approved paths with session policies handles session narrowing well yet misses maximum capping, since resource paths only organize and authorize creation location and never limit permissions, leaving AdministratorAccess attachable. The alternative letting teams choose their own boundaries alongside session policies appears to use both controls yet misses effective capping, because a self-imposed ceiling is attacker-controlled and must instead be an administrator-owned boundary enforced with condition keys. As an exam caveat, distinguish account-level SCPs from role-level boundaries and session-specific session policies, as stems mentioning both capping delegation and constraining sessions demand the latter two together. As a practical check, attempt role creation without the mandated boundary and assume the role with a restrictive session policy to verify privileged actions are denied.