An engineer added an SCP that only contains Allow statements and expects those statements to grant S3 access in a member account. The account's identities have no identity policy allowing S3. Puts still fail. Why?
Select an answer to reveal the explanation.
Short Explanation
An SCP is a filter, not a grant. Allow in the SCP means the account is permitted to use an action that some identity policy must still grant. Nobody granted S3 in the member account, so the put fails and you write the identity policy, not a louder SCP.
Full Explanation
Service control policies set the maximum permissions for member accounts. They do not grant access by themselves. An SCP that only allows S3 does not give any role s3:PutObject; an identity policy or resource policy still has to allow it. The expectation that the SCP Allow is enough is the mistake. SCPs do affect member accounts; they do not affect the management account, which is the reverse of the distractor. Versioning does not turn SCP evaluation on. Caveat: a Deny in an SCP is absolute, and an empty or missing SCP is not how you grant a new service. Operational check: attach an identity policy that allows the put, keep the SCP from denying it, and confirm the put succeeds as that role. Give the role an identity policy that allows the S3 action, and leave the SCP as a filter that does not deny it. An SCP full of Allow statements is not a grant and is easy to misread as one. Full-access SCPs are often replaced by deny-list SCPs that only block what the organization forbids. After the identity policy is attached, the put should succeed and a denied Region should still fail.