A rotated Key Vault secret is correct, but App Service still uses the previous value

A fictional application uses a Key Vault reference without a version in its URI. A new secret version has been created and is enabled. Requests from an authorized diagnostic client use the new value successfully, but the application behaves as if it has the old credential. Is this necessarily a permissions failure, and how should refresh behavior be checked?

First verify that the reference is actually versionless and points to the expected vault and secret. App Service caches reference values, and Microsoft’s documentation describes a normal refresh period of about 24 hours. A successful direct secret read does not demonstrate what the application’s cached setting contains.

After checking identity and connectivity, use the documented authenticated reference-refresh operation or the appropriate configuration refresh path. Coordinate changes that may restart the application. Validate with a successful dependent operation rather than writing the secret into logs. In this example, the diagnosis is a reference-refresh delay, with application-level credential caching checked separately.

Yes. Refreshing a pool does not necessarily refresh the platform-provided setting. Check both the platform reference and the application’s own cache or connection lifetime.

If the URI includes a specific version, refreshing cannot select a newer version automatically. Update the reference through the controlled configuration process and retain a rollback plan for the dependent credential.

A rotated Key Vault secret is correct, but App Service still uses the previous value

2 answers

Your perspective belongs here.

0 question comments