## TL;DR

The lookup name does not match any secret the caller can see. Verify the exact name, the region, and that the secret is not in pending deletion, then fix whichever one is wrong.

## Error

```text
"secrets manager can't find the specified secret"
```

## Steps

1. List secrets in the region and compare names character by character. Expected: you find the mismatch (suffix, typo, case).
2. Confirm the region on the call matches the secret's region. Expected: region-correct calls succeed.
3. Check deletion state: pending-deletion secrets are not returned by lookups. Expected: you learn whether a delete is in flight.
4. If the name comes from config or env, print the resolved value to see what the app actually asked for. Expected: the real lookup string, which often differs from what you assumed.
5. Fix the name, region, or restore the secret, then retry. Expected: the lookup succeeds.

## When to use

- Secret lookups by name fail in apps, scripts, or IaC.
- After renames or region migrations.

## When not to use

- Access-denied errors (the secret exists; you cannot read it).
- Decryption failures (KMS, not naming).

## Tool compatibility

- AWS Secrets Manager, GCP Secret Manager, Azure Key Vault; same triage shape.

## Variant phrasings

### secret not found in secrets manager

Same checks.

### specified secret does not exist

Often a region or naming issue.

## Why it happens

Secret names are scoped per region and per project, and human-entered names drift from the real ones through typos, suffixes, and renames.

## Edge cases

- IaC renames create new secrets; old references break silently until the lookup runs.
- Some managers version secrets; the name exists but the requested version does not.
- Cross-project or cross-account lookups need the full resource path, not the short name.

## Provenance

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