A platform team grants federated contractors admin-like roles for deployments but must cap maximum privileges and scope each session to a single microservice without rewriting identity policies per request. Which least-privilege IAM policy combination should the architect interpret and implement?
Select an answer to reveal the explanation.
Short Explanation
You're giving valet keys that can't open the safe, thanks to boundaries. Permission boundaries set the ceiling while session policies narrow each ride so you'll stay least-privilege without rewrites.
Full Explanation
The correct combination works because identity policies grant needed deployment permissions while permission boundaries impose a maximum ceiling the role cannot exceed even when its identity policy is broad, and session policies passed during AssumeRole intersect further down to a single microservice for that session only without modifying stored policies, satisfying least privilege and operational efficiency together. The choice pairing identity policies with session policies correctly narrows each session but leaves admin-like permissions without a boundary cap, so a broad role or future policy addition still allows excessive maximum privileges and fails the capping requirement by concept. The choice pairing identity policies with permission boundaries correctly caps the maximum but provides no per-session narrowing mechanism, so every session retains access to all microservices allowed by the role and fails the single-microservice scoping requirement. The choice using boundaries while rewriting identity policies per request achieves cap and narrow scope in theory but directly violates the requirement to avoid per-request rewrites, creating version churn, propagation delay, and audit burden that session policies are specifically designed to prevent. For exams, remember boundaries and session policies only intersect and never grant access alone, distinct from SCPs that constrain entire accounts, and watch for capping maximum versus scoping a single session as separate signals. As a practical check, assume the contractor role with the intended session policy and run IAM Policy Simulator plus a dry-run deployment to confirm denial outside the target microservice and denial of any action beyond the boundary before production use.