A startup grants developers broad IAM access for speed, had privilege escalation via iam:PassRole, and needs least privilege without blocking deployments. New guardrails must limit role passing and scope actions. Which least-privilege design prevents escalation while enabling delivery?
Select an answer to reveal the explanation.
Short Explanation
You're giving builders a fenced playground, not the whole city. Permission boundaries cap max powers while session policies tighten each deployment shift.
Full Explanation
The correct design succeeds because permission boundaries impose a non-overridable ceiling on developer identities while session policies narrow each session to deployment-required actions, and restricting iam:PassRole to explicit role ARNs with iam:PassedToService conditions permits passing only approved roles to approved services, closing the escalation path without freezing releases. The MFA-centered alternative with unrestricted passing fails on authorization granularity because stronger authentication cannot limit delegation, so allowing PassRole on any role still lets developers hand an over-privileged role to a service and inherit its rights. The PowerUserAccess with regional SCPs alternative fails on delegation control because SCPs only filter organizational maximums and never finely scope PassRole, so geographic limits leave the escalation primitive intact. The boundaries with self-service role creation alternative fails on safe privilege management because iam:CreateRole and iam:AttachRolePolicy allow crafting more powerful roles or widening permissions over time. For exams, boundaries, SCPs, and session policies only constrain grants and never grant permissions, and PassRole must name specific role ARNs; practically, validate with IAM Access Analyzer and policy simulation plus CloudTrail queries that approved paths succeed while passing unlisted roles or creating privileged policies is denied.