A municipal Lambda role is allowed kms:Decrypt by its identity policy, but sealed case PDFs still fail to open. An SCP on the account includes an explicit Deny for kms:Decrypt. What explains the failure?
Select an answer to reveal the explanation.
Short Explanation
In IAM, explicit Deny is the red stamp that cancels every Allow underneath it. An SCP or boundary Deny on kms:Decrypt will block the role no matter how friendly the identity policy looks. Fix the Deny path, not only the Allow.
Full Explanation
AWS authorization evaluation gives explicit Deny precedence over Allow. If a municipal Lambda role’s identity policy allows kms:Decrypt but an account SCP includes an explicit Deny for kms:Decrypt, attempts to open sealed case PDFs fail even though the role document “allows” decrypt. The organization boundary Deny wins—this is how platform teams enforce citywide cryptographic guardrails that application teams cannot locally override.
Allow statements do not override Deny. KMS does not ignore SCPs and does not evaluate only a Lambda resource policy for decrypt authorization. Explicit Deny is not limited to root users; it applies to roles and other principals within the SCP’s scope.
Exam caveat: when troubleshooting “role allows it but API still denies,” inspect SCPs, permissions boundaries, session policies, VPC endpoint policies, and key policies—not only the identity policy JSON attached to the role. Operational check: reproduce the decrypt failure with the SDK, list effective SCPs for the account/OU looking for Deny on kms:Decrypt, and validate in an approved sandbox without that Deny that the same role policy succeeds for a test ciphertext. For municipal workloads, document the chosen pattern in the runbook so the next on-call engineer applies the same control instead of inventing a weaker shortcut under pressure.