A role has two identity policies. One allows ec2:RebootInstances. The other explicitly denies ec2:RebootInstances. A reboot is denied. Why does the allow lose?
Select an answer to reveal the explanation.
Short Explanation
An explicit deny is a locked gate, and a second policy that says allow does not unlock it. You have both on the same role, so the reboot stays denied. Attaching the allow later does not make it stronger.
Full Explanation
IAM evaluates all applicable policies. An explicit Deny wins over Allow, including when the two statements are in different identity policies on the same principal. The reboot is denied because of that deny, not because a second policy disables identity policies. The order the policies were attached does not rank them. Denies are not limited to bucket policies; an identity-based deny is fully effective. Caveat: if the deny is broader than the team meant, narrow that statement rather than stacking more allows. Operational check: in the policy simulator, evaluate ec2:RebootInstances as this role and confirm the decision cites the deny statement. The simulator lists the statement that produced the deny, which is the one to edit. Removing the allow does nothing while the deny remains. If the deny was meant for a different action, narrow its Action list rather than deleting the whole policy. After the edit, a reboot in a non-production account should succeed for this role and still fail for a role you intended to block.