A startup grants developers broad IAM roles for velocity, but a breach review requires least privilege without breaking deployments, temporary elevation for on-call, and guardrails preventing privilege escalation. Which policy mechanism should the architect implement to enforce least privilege?

The correct mechanism pairs permission boundaries to cap the maximum permissions developer roles can ever attain with session policies to narrowly scope temporary elevated on-call sessions, preserving deployments because existing functional identity policies continue to work within the cap, enabling time-limited elevation that expires automatically, and blocking privilege escalation because the boundary denies any excess even if identity policies are misconfigured. Refining identity policies using Access Analyzer findings achieves least-privilege trimming while keeping workflows intact but fails as a guardrail because it leaves no enforced maximum and provides no temporary session scoping, allowing future edits to reintroduce broad access. Provisioning separate on-call roles assumed via short-lived STS tokens with MFA handles temporary elevation securely but fails to prevent escalation because without a boundary the role maximum remains broad and can be used to create further privileged identities. Enforcing service control policies that block IAM changes creates preventive organization guardrails but fails to deliver granular least privilege or temporary elevation and risks breaking deployments that legitimately provision infrastructure. For exams, remember boundaries, session policies, and service control policies never grant permissions, they only limit, and effective permissions are their intersection with identity policies. Practically, validate with the IAM policy simulator and CloudTrail access history to confirm capped maxima, workable deployments, and properly scoped elevated sessions.