Permission Boundary
A policy limiting the maximum permissions an identity can have, used so that the ability to create roles does not become the ability to grant unlimited privilege.
The specific problem it solves: delegating role creation to a team is useful, and without a bound it is equivalent to granting administrator. A developer who can create a role and attach a policy can create one with full privileges and assume it.
A permission boundary caps the effective permissions of any identity created within it. The delegated team can create roles freely; those roles can never exceed the boundary, regardless of the policies attached.
The mental model worth holding: effective permissions are the intersection of the identity policy, the permission boundary, and any organisation-level policy such as an SCP. Each is a ceiling, and a grant absent from any of them does not exist.
Where it is essential: self-service platforms, CI/CD pipelines that create infrastructure, and any account where role creation is delegated. Without one, "can create IAM roles" is the most powerful permission in the account and it is routinely handed out as an ordinary developer capability.
The related escalation paths worth auditing at the same time: iam:PassRole without a resource
constraint, the ability to modify one's own policies, and the ability to invoke a compute service that
runs with a more privileged role.