## TL;DR

The caller can reach the secret but cannot decrypt it, which means the KMS key policy or the caller's IAM policy blocks decrypt. Grant decrypt on that key and the read succeeds.

## Error

```text
"aws secretsmanager get-secret-value: DecryptionFailure"
```

## Steps

1. Identify the KMS key: `describe-secret` shows the key id, defaulting to the account key. Expected: the exact key.
2. Check the caller's IAM policy for permission to use that KMS key for decrypt. Expected: the gap found.
3. Check the KMS key policy too; both the identity policy and the key policy must allow. Expected: whichever side blocks is identified.
4. Add the decrypt grant on the correct side and retry the read. Expected: success.
5. If cross-account, the key policy must name the external account explicitly. Expected: cross-account reads work after the key policy update.

## When to use

- `get-secret-value` fails with DecryptionFailure specifically.
- After key changes or cross-account setups.

## When not to use

- `ResourceNotFoundException` (wrong name or region).
- `AccessDeniedException` on the secret itself (Secrets Manager permission, not KMS).

## Tool compatibility

- AWS Secrets Manager with KMS encryption; CLI and SDKs.

## Variant phrasings

### secretsmanager decryption failed

Same KMS cause.

### KMS access denied reading secret

Identical; fix the key policy side.

## Why it happens

Secrets Manager encrypts with KMS, so reading needs two permissions: the secret read and the key decrypt. Setups often grant only the first.

## Edge cases

- The default account key has a restrictive key policy; custom keys are easier to share cross-account.
- Rotation Lambdas need decrypt too, or rotation fails with the same error.
- Key deletion is scheduled; a pending-deletion key fails decrypts before it disappears.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_M1DRCxPMLjCzU-3Tec4PSA