Azure Container Apps reports Key Vault managed-identity fetch failure despite successful SecretGet audit events

hi Srinivasan Arumugam & thx for sharing urs issue here at Q&A portal,

The Key Vault evidence is pretty conclusive here. The managed identity authenticated successfully and Key Vault returned the requested secrets, so increasing RBAC scope or replacing the identity isn’t a justified fix. Key Vault Secrets User is the documented role for Container Apps Key Vault references. This looks like a failure inside the Microsoft.App provisioning path after the SecretGet calls complete. Possible causes include validation of the returned reference, secret-reference state handling, or a regional backend issue, but customer-side logs can’t identify which one. I’d open a Container Apps support case and include the correlation ID, operation status ID, exact UTC window, failed ARM payload with values redacted, and the matching Key Vault audit records. Microsoft needs to correlate those with backend telemetry. The public troubleshooting guidance doesn’t expose the internal stage that failed here.

I wouldn’t grant vault-wide access as a workaround unless Microsoft can document why secret-scoped RBAC is unsupported for this operation. Based on the successful reads, permissions aren’t the blocker.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

and at my blog https://ctrlaltdel.blog/

Hello Srinivasan Arumugam,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your Azure Container Apps reports Key Vault managed-identity fetch failure despite successful SecretGet audit events.

This is not a normal Key Vault RBAC, managed identity, or secret permission issue. Azure Container Apps supports Key Vault secret references using managed identity, and the managed identity only needs permission to read the required Key Vault secrets. https://learn.microsoft.com/en-us/azure/container-apps/manage-secrets, https://learn.microsoft.com/en-us/azure/container-apps/managed-identity

At this point, you do not need to reconfigure Key Vault broadly, switch to legacy access policies, or copy secrets into Container Apps. Validate the secret reference shape, prove Key Vault success, isolate one failing secret, and escalate to Microsoft with the Activity Log correlation ID and Container Apps operation status ID.

Anyhow, you can try to resolve it without Azure Support by pinning the Key Vault secret version, recreating the Container Apps secret references with the full user-assigned identity resource ID, and forcing a new revision or recreating the Container App/Job. But if Key Vault continues to show successful SecretGet while Microsoft.App still reports secret fetch failure, then there is Azure support is only way that can reveal or fix the internal Microsoft.App backend failure. In that case, the precise ownership shifts to Microsoft Product Group investigation.

I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.

Your evidence is enough to stop treating this as an ordinary Key Vault authorization failure. Container Apps requires the identity assigned to the app or job, referenced by identityref, granted Key Vault Secrets User, and a supported secret URI. You meet those requirements, and successful SecretGet events confirm Key Vault authenticated and authorized that identity.

As an isolation test, pin one failing reference to an exact secret version and deploy only that reference to a disposable app or job. If it still fails while the matching SecretGet succeeds, retain the per-secret role assignments; broader vault access is neither required nor justified.

Capture the rendered ARM or YAML secret configuration, Container Apps diagnostics, operation window, correlation ID, and status ID, then open an Azure technical support request for Microsoft.App. Only the service team can correlate the backend validation stage. Microsoft documentation provides no client-side remediation for this exact success-then-provisioning-failure pattern.

Hey @Srinivasan Arumugam

This issue was found to be related to the secret values stored in your Azure Key Vault (kv-cm-np-cm65062). Investigation confirmed that the Azure Container Apps service successfully connected to your Key Vault using the configured User-Assigned Managed Identity and received HTTP 200 (success) responses for all secret retrieval operations — consistent with the Key Vault AuditEvent logs you observed. However, the actual values returned for the following 4 secrets were empty strings (""):

• development-brevo-api-key
• development-finexer-api-key
• development-google-client-secret
• development-google-client-id

Azure Container Apps validates that Key Vault secret references resolve to non-empty values during deployment. Since these secrets returned empty values, the validation rejected the deployment. Notably, three other secrets from the same vault using the same identity (development-twilio-account-sid, development-twilio-auth-token, development-twilio-from-number) were fetched successfully because they contain non-empty values. Your Key Vault Secrets User RBAC configuration scoped at the individual secret level is working correctly and does not need changes. No platform action is needed.

Recommended remediation:

1. Verify the values of the 4 failing secrets using: az keyvault secret show --vault-name kv-cm-np-cm65062 --name development-brevo-api-key --query value
2. Set actual non-empty values for all 4 secrets
3. Retry the Container App and Job deployment

If the resolution was helpful, kindly take a moment to click on and click on Yes for was this answer helpful. And, if you have any further query do let us know.