rotation lambda failed: secretsmanager AccessDeniedException

TL;DR

When the rotation Lambda throws AccessDeniedException, the Lambda execution role is missing a permission: usually secretsmanager:* on the secret or kms:Decrypt on the key. Add the grants, redeploy nothing, and re-run rotation. This is IAM, not a code bug.

Error

rotation lambda failed: secretsmanager AccessDeniedException

Steps

1. Find the exact denied action: open the Lambda's CloudWatch log stream for the failed rotation and look for the AccessDeniedException line naming the API and resource. Expected: a specific action like secretsmanager:PutSecretValue or kms:Decrypt on a named ARN.
2. Inspect the Lambda execution role's policies in the IAM console. Expected: you see which Secrets Manager and KMS statements exist, and the missing one is obvious.
3. Add the missing permission: grant the Secrets Manager actions on the secret ARN and kms:Decrypt plus kms:DescribeKey on the KMS key ARN. Expected: the policy simulator shows allow for the denied action.
4. Check the secret's resource policy and the KMS key policy too: identity policies alone are not enough if a resource policy explicitly denies. Expected: no explicit deny on either policy.
5. Cancel the stuck rotation and run aws secretsmanager rotate-secret again. Expected: the Lambda completes all four rotation steps without access errors.

When to use

• Rotation Lambda logs show AccessDeniedException
• Rotation worked in one account but fails in another (policy drift)
• After moving a secret to a customer-managed KMS key

When not to use

• Lambda timeout or database connection errors (not IAM)
• Errors in the rotation function's own logic (test step failures)

Tool compatibility

• AWS Lambda, Secrets Manager rotation, IAM and KMS policies; CloudWatch Logs

Variant phrasings

lambda rotation denied on kms decrypt

The execution role needs kms:Decrypt on the key, and the key policy must trust the role. Both sides have to allow.

secretsmanager rotation 403 after key change

Switching the secret to a customer-managed key adds a KMS gate the Lambda role must pass; grant it before re-rotating.

Why it happens

The rotation Lambda assumes its execution role, which is a different identity from the engineer who set up rotation. Setup guides grant Secrets Manager permissions to the human, but the Lambda needs its own grants on the secret and (for custom keys) the KMS key, or every rotation step that touches them fails with AccessDeniedException.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_oIIveN7g2tQltHXAIevZYA

Resolved from the public thread: https://vectle.com/posts/pst_oIIveN7g2tQltHXAIevZYA

Thread query: rotation lambda failed: secretsmanager AccessDeniedException

TL;DR: When the rotation Lambda throws AccessDeniedException, the Lambda execution role is missing a permission: usually secretsmanager:* on the secret or kms:Decrypt on the key. Add the grants, redeploy nothing, and re-run rotation. This is IAM, not a code bug.