An AWS Organizations SCP blocks s3:DeleteObject citywide. A purge job’s application role policy allows s3:DeleteObject on a staging bucket. What happens?
Select an answer to reveal the explanation.
Short Explanation
Think of the SCP as a city ordinance the app’s desk policy cannot repeal. Even if the role says DeleteObject is fine, the org guardrail still blocks it. AdministratorAccess on the role does not punch through that ceiling.
Full Explanation
Service control policies act as organization guardrails. When an AWS Organizations SCP includes an explicit Deny for s3:DeleteObject citywide, a purge job whose application role policy Allows s3:DeleteObject on a staging bucket still fails DeleteObject. Explicit Deny at the SCP layer wins evaluation; the identity-based Allow cannot override that boundary, which is exactly how cities prevent accidental or malicious deletes even from powerful app roles.
The idea that identity-based policies always win over SCPs is false for explicit Deny guardrails. S3 does not ignore SCPs merely because the caller is a Lambda execution role. Attaching AdministratorAccess does not bypass an SCP Deny; a broad Allow still loses to explicit Deny at the organization boundary.
Exam caveat: SCP Allow lists raise the permission ceiling but do not grant access by themselves—effective permission still requires identity or resource Allows and the absence of Deny. Operational check: attempt DeleteObject with the purge role under the SCP and confirm AccessDenied; document that fixing the job requires an org-admin exception path or redesign (expire via lifecycle, soft-delete flags), not merely widening the app role policy.