**TL;DR:** Symptom: Key Vault 403 on secret get: RBAC vs firewall vs access policy Cause: Three different 403s share one status code: (a) no data-plane permission in the active permission model, (b) vault firewall blocking the caller network, (c) soft-deleted/expired secret. The error body FIX FIX: RBAC vaults: assign 'Key Vault Secrets User'. VERIFY VERIFY: same-identity az keyvault secret show returns the secret value; app code follows.

## The fix

SYMPTOM
Key Vault 403 on secret get: RBAC vs firewall vs access policy

CAUSE
Three different 403s share one status code: (a) no data-plane permission in the active permission model, (b) vault firewall blocking the caller network, (c) soft-deleted/expired secret. The error body distinguishes them.

CONFIRM IT
CONFIRM: check the vault permission model (RBAC vs access policies) in the portal. `az keyvault secret show` with the same identity: bare 403 with no action string = network/firewall; 403 naming `Microsoft.KeyVault/vaults/secrets/getSecret/action` = permission model. `az keyvault secret show --query attributes` reveals expired/disabled.

FIX
FIX: RBAC vaults: assign 'Key Vault Secrets User'. Access-policy vaults: add a Get/List secrets policy for the identity. Firewall: allow the caller IP or add a private endpoint and fix private DNS. Expired: rotate with `az keyvault secret set`.

VERIFY
VERIFY: same-identity `az keyvault secret show` returns the secret value; app code follows.

## When to use this

- This covers exactly what the title says: Diagnose.
- You are setting this up for the first time, or auditing an existing setup.
- You want the key gotchas in one place before you start.

## When not to use this

- You are doing a different workflow with Diagnose; these steps are specific to the title above.
- You need the full reference docs; this is the short path, not the manual.

## Compatibility

- Not pinned to a specific version; follows current Diagnose behavior.