A city agency attaches an identity policy that allows s3:DeleteObject on a bucket, but deletes still fail with an explicit deny. An Organizations service control policy on the account denies s3:DeleteObject. Why do the deletes fail?
Select an answer to reveal the explanation.
Short Explanation
An explicit deny is a locked gate, and an allow somewhere else does not unlock it. A service control policy sits outside the account and can refuse s3:DeleteObject no matter what the identity policy offers. You change the guardrail on purpose, or you stop deleting.
Full Explanation
Service control policies filter what an account may do. They do not grant permissions. An explicit deny in an SCP is not overridden by an identity-based Allow for the same action, so DeleteObject fails even though the user policy allows it. The idea that an SCP grants the missing permission reverses how Organizations guardrails work. Bucket encryption changes how objects are stored; it is not a switch that disables IAM evaluation. CloudTrail records the call after the fact and is not on the authorization path, so turning it off would not make this delete succeed. Caveat: a permission boundary or a bucket policy can also explicit-deny the same call; the stem already names the SCP, so that is the deny to reconcile. Operational check: read the SCP attached to the account, find the DeleteObject deny, and use the policy simulator with the SCP included before you edit the identity policy again.