App Service cannot read a Key Vault secret: a diagnostic path that preserves least privilege

An unresolved Key Vault reference can look like an ordinary application setting problem. The setting may contain a reference expression instead of the expected value, or the application may report missing credentials. Adding a broad role to your own account rarely fixes this: App Service retrieves the secret as its configured identity, along the network path available to the app.

Establish which identity is making the request

Record the app, deployment slot, reference URI and time of failure without copying the secret. Check whether the app uses its system-assigned identity or a user-assigned identity selected by keyVaultReferenceIdentity. The latter setting expects the identity resource ID. A role on a similarly named identity or on a different slot does not establish access for this request.

For a vault using Azure RBAC, reading a secret’s value requires a data-plane role such as Key Vault Secrets User at an appropriate scope. Key Vault Contributor manages the resource but does not supply secret-value access. Check the vault’s authorization mode before applying advice written for access policies. Keep secret readers separate from the people allowed to change role assignments.

Verify DNS and the application network path

For a private vault, confirm the app’s VNet integration and name resolution from that integration path. A successful lookup on your laptop proves only your laptop’s DNS configuration. Linux apps that use a private endpoint generally need routing configuration appropriate to their hosting plan; the Flex Consumption exception and current platform behavior are documented in Microsoft’s guide.

Key Vault audit logs can show an initial public-address denial followed by a successful private request. Correlate the sequence and final result before treating every 403 as an outage. Do not temporarily expose the vault to all networks as a diagnostic shortcut.

Distinguish a stale reference from a failed retrieval

Versionless references are cached and are ordinarily refreshed within about 24 hours. Changing a secret does not prove the application has already loaded it. After validating permissions and routing, use the documented authenticated reference-refresh operation or an appropriate configuration change, then verify the application behavior. A restart can affect availability, so schedule it deliberately.

Close the investigation with evidence: the effective identity, the least-privileged role, the DNS result, the resolved reference status and a successful operation that uses the secret. Preserve identifiers and timings in the incident record, while excluding secret values and authorization headers.