TL;DR: The run is trying to decrypt a KMS key in another account or region, and your role isn't allowed to. This almost always means stack discovery walked into an environment you shouldn't be parsing. Scope the run to your environment; don't widen KMS access to fix a discovery problem.

```text
ERROR  Call to function "sops_decrypt_file" failed:
ERROR  * error decrypting key: ... arn:aws:kms:[region]:[account]:key/[key id]:
ERROR    AccessDeniedException: User: arn:aws:sts::[caller account]:assumed-role/[ci role]/...
ERROR    is not authorized to perform: kms:Decrypt on the resource ... because the resource
does not exist in this Region, no resource-based policies allow access, or a
resource-based policy explicitly denies access
```

## Steps

1. Identify whose key it is: the key ARN's account/region vs your role's account.
   Expected: it's another environment's key (e.g. prod key while you work in dev).
2. Check whether the run should be parsing that environment at all. If not, narrow discovery with `--filter` so the runner pool stays in your environment.
   Expected: the foreign `sops_decrypt_file` is never evaluated.
3. If the run LEGITIMATELY needs that environment's secrets, grant your role `kms:Decrypt` on that key (key policy or IAM policy) in the right region.
   Expected: decryption succeeds.
4. Re-run.
   Expected: no more AccessDenied.

## When this applies

- `sops_decrypt_file` fails naming a KMS key ARN in a different account or region.
- CI roles are scoped per-account/per-environment.

## When it doesn't apply

- Age-based SOPS (no KMS involved): check the age key file / SOPS_AGE_KEY env var instead.
- The key is in YOUR account and region: then it's a genuine policy gap; add the `kms:Decrypt` grant.

## Tool versions

All Terragrunt versions with `sops_decrypt_file`.

## Why it happens

`sops_decrypt_file` evaluates at config-parse time, so merely discovering a unit decrypts its secrets. A per-account CI role hitting another account's key gets AccessDenied before Terragrunt ever decides whether that unit was in scope.

## Edge cases

- "does not exist in this Region" sometimes literally means region mismatch: the key exists, but your SDK is pointed at the wrong region. Check `AWS_REGION` before rewriting policies.
- KMS grants are eventually consistent; a just-added grant can still AccessDenied for a few minutes.