A platform team lets application teams create their own IAM roles for their workloads, but wants a guarantee that none of those self-created roles can ever be granted IAM administrative permissions or access to one specific sensitive S3 bucket, no matter what identity-based policy an application team attaches later. Which IAM feature is designed for this?
- A service control policy attached directly to each application team's individual IAM role
- An IAM policy simulator report that a reviewer runs manually before every deployment
- A permissions boundary attached to the roles that caps their maximum possible permissions regardless of what identity-based policies are attached afterward
- A resource-based policy added to every future resource those roles might ever need to access
Why C? And why not the others?
Correct answer: C. A permissions boundary attached to the roles that caps their maximum possible permissions regardless of what identity-based policies are attached afterward
A permissions boundary is a managed policy attached to an IAM user or role that sets the maximum permissions that identity can ever have; any identity-based policy attached later, however permissive, is intersected with the boundary, so permissions outside the boundary — such as IAM administration or the sensitive bucket — can never take effect. This makes it the correct tool for letting teams self-manage roles within a hard ceiling. The option describing a service control policy attached to individual roles is wrong because SCPs are attached to AWS Organizations entities such as accounts or organizational units, not to individual IAM roles, so this configuration is not even possible. The option describing a manually run policy simulator is wrong because it is only an analysis tool that reports what a policy would allow; it enforces nothing and depends on a human remembering to run it every time, which is not a guarantee. The option describing a resource-based policy on every future resource is wrong because it would need to be recreated correctly on every new resource those roles might touch, which does not scale and provides no guarantee against a future oversight.
Source: AWS IAM documentation: Permissions boundaries for IAM entities