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

Question

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

Srinivasan Arumugam 0

We are blocked deploying a development Azure Container App and manual Container Apps Job in UK South. Both resources use the same user-assigned managed identity and versionless Azure Key Vault secret references.

The runtime identity has Key Vault Secrets User assignments scoped to each exact secret. Existing application/database Key Vault references using the same vault and identity work. Role assignments have no conditions and have been propagated for more than 36 hours. The target secrets are enabled and unexpired, the vault uses Azure RBAC, and its public network endpoint is enabled.

During one controlled update on 19 July 2026, both Microsoft.App writes failed with the generic message that the managed identity was unable to fetch four of the new Key Vault references.

Redacted identifiers for Microsoft investigation:

Region: UK South
Activity Log correlation ID: 99680d7e-826f-31ac-23d4-05b4bc3a2eb7
Container App operation status ID: 0e029a6d-e0f6-4621-aed4-fd39f9ba1a3e
Operation window: 2026-07-19T07:15:39Z through 2026-07-19T07:15:56Z
Resources: one development Container App and one manual development Container Apps Job

Key Vault AuditEvent diagnostics were enabled before that attempt. During the exact operation window, the exact runtime identity completed 13 SecretGet operations for all seven new integration-secret targets. Every event has ResultType=Success and ResultSignature=OK; there are no Key Vault authorization denials for that identity in the window.

The failed Microsoft.App operations and successful Key Vault reads share the same time window. Neither failed update changed the live workloads. This indicates that the error occurs after Key Vault successfully returns the secret, in the Microsoft.App / Container Apps secret-reference validation or provisioning path rather than in Key Vault RBAC.

Could Microsoft please:

correlate the supplied correlation and operation IDs with Microsoft.App backend telemetry;
confirm why Microsoft.App reports an identity fetch failure after Key Vault records successful reads;
advise whether this is a known Container Apps Key Vault-reference issue or constraint;
provide a supported least-privilege remediation that does not require vault-wide access, replacing the managed identity, or copying secret values into deployment configuration?

This post intentionally excludes the subscription ID, tenant ID, full resource names, managed-identity object/client IDs, Key Vault URI, secret URIs/versions, IP addresses, secret payloads, logs containing payloads, and customer data. Those identifiers can be provided privately to Microsoft support if a case is opened.

Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-07-21T04:19:34.7766667+00:00

Hello @Srinivasan Arumugam Following up to see if the above provided information was helpful. If you have any further queries do let us know.
Srinivasan Arumugam 0 Reputation points

2026-07-21T11:55:16.92+00:00

Thanks Rukmini, I have sent a private message with the details and am working on the input provided.

thanks
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-07-22T06:33:57.3+00:00

Hello @Sina Salam We are actively working with the customer and troubleshooting the issue offline as it seems to be a backend issue.
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-07-22T07:27:12.82+00:00

Hello @Srinivasan Arumugam Lets continue over private messages!
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-07-22T07:34:42.3766667+00:00

Hello @Alex Burlachenko We are actively working with the customer and troubleshooting the issue offline as it seems to be a backend issue.
Srinivasan Arumugam 0 Reputation points

2026-07-22T09:40:05.01+00:00

Update 22 July 2026: we completed the recommended disposable, version-pinned isolation test. A manual-only Container Apps Job used the existing development UAMI, exactly one Key Vault reference pinned to a recorded secret version, the existing exact-secret Key Vault Secrets User grant, and the reviewed immutable image.

Microsoft.App/jobs/write started at 2026-07-22T09:22:10.2783533Z and failed BadRequest at 2026-07-22T09:22:12.403342Z. Correlation ID: 65bfa5ac-c3f9-4f24-1ce8-0834ec6b5d42. The error remained InvalidParameterValueInContainerTemplate / managed identity unable to fetch the reference.

During the same write window, Key Vault AuditEvent—filtered to the development runtime client—recorded one SecretGet with ResultType=Success and ResultSignature=OK at 2026-07-22T09:22:11.8869871Z, approximately 0.52 seconds before the failed write. No URI, payload, caller IP, subscription, tenant, or identity IDs are included here.

The job was not created or started and has zero executions. This reproduces the failure with a version-pinned URI, so versionless-reference/token-cache handling is not a remediation. Please escalate this correlation to the Microsoft.App product group and advise a supported least-privilege fix. We will not broaden vault access, replace the identity, or copy secret values into deployment configuration.
Srinivasan Arumugam 0 Reputation points

2026-07-22T12:01:02.33+00:00

Thanks Alex.
We completed the recommended version-pinned disposable-job test and reproduced the failure.

Microsoft.App correlation ID: 65bfa5ac-c3f9-4f24-1ce8-0834ec6b5d42

The job write failed at 2026-07-22T09:22:12.403342Z, while Key Vault recorded a successful SecretGet by the runtime identity at 2026-07-22T09:22:11.8869871Z. The job was not created or started.

Microsoft Support case 2607220040001265 is now open, and we have requested Microsoft.App backend correlation and a supported least-privilege remediation. We are retaining secret-scoped RBAC and will not broaden vault access or replace the identity.

Thanks for confirming the correct escalation path.
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-07-23T04:55:24.19+00:00

Hello @Srinivasan Arumugam Please check private messages!
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-07-26T02:43:54.6633333+00:00

Hello @Srinivasan Arumugam

Please confirm whether your issue is resolved or still facing any errors.
timothy jones 20 Reputation points

2026-07-26T03:52:39.0966667+00:00

Thank you and the very project i had in mind was thrust into life and there is actually a agent that has been trained to systematically destroy anything you have espousals academic career home life or whatever is posable I didn't now but whatever it might cost hopefully me quieting school and just putting everything away now more.

4 answers

Your answer

Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-07-21T04:19:34.7766667+00:00

Hello @Srinivasan Arumugam Following up to see if the above provided information was helpful. If you have any further queries do let us know.
Srinivasan Arumugam 0 Reputation points

2026-07-21T11:55:16.92+00:00

Thanks Rukmini, I have sent a private message with the details and am working on the input provided.

thanks
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-07-22T06:33:57.3+00:00

Hello @Sina Salam We are actively working with the customer and troubleshooting the issue offline as it seems to be a backend issue.
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-07-22T07:27:12.82+00:00

Hello @Srinivasan Arumugam Lets continue over private messages!
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-07-22T07:34:42.3766667+00:00

Hello @Alex Burlachenko We are actively working with the customer and troubleshooting the issue offline as it seems to be a backend issue.
Srinivasan Arumugam 0 Reputation points

2026-07-22T09:40:05.01+00:00

Update 22 July 2026: we completed the recommended disposable, version-pinned isolation test. A manual-only Container Apps Job used the existing development UAMI, exactly one Key Vault reference pinned to a recorded secret version, the existing exact-secret Key Vault Secrets User grant, and the reviewed immutable image.

Microsoft.App/jobs/write started at 2026-07-22T09:22:10.2783533Z and failed BadRequest at 2026-07-22T09:22:12.403342Z. Correlation ID: 65bfa5ac-c3f9-4f24-1ce8-0834ec6b5d42. The error remained InvalidParameterValueInContainerTemplate / managed identity unable to fetch the reference.

During the same write window, Key Vault AuditEvent—filtered to the development runtime client—recorded one SecretGet with ResultType=Success and ResultSignature=OK at 2026-07-22T09:22:11.8869871Z, approximately 0.52 seconds before the failed write. No URI, payload, caller IP, subscription, tenant, or identity IDs are included here.

The job was not created or started and has zero executions. This reproduces the failure with a version-pinned URI, so versionless-reference/token-cache handling is not a remediation. Please escalate this correlation to the Microsoft.App product group and advise a supported least-privilege fix. We will not broaden vault access, replace the identity, or copy secret values into deployment configuration.
Srinivasan Arumugam 0 Reputation points

2026-07-22T12:01:02.33+00:00

Thanks Alex.
We completed the recommended version-pinned disposable-job test and reproduced the failure.

Microsoft.App correlation ID: 65bfa5ac-c3f9-4f24-1ce8-0834ec6b5d42

The job write failed at 2026-07-22T09:22:12.403342Z, while Key Vault recorded a successful SecretGet by the runtime identity at 2026-07-22T09:22:11.8869871Z. The job was not created or started.

Microsoft Support case 2607220040001265 is now open, and we have requested Microsoft.App backend correlation and a supported least-privilege remediation. We are retaining secret-scoped RBAC and will not broaden vault access or replace the identity.

Thanks for confirming the correct escalation path.
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-07-23T04:55:24.19+00:00

Hello @Srinivasan Arumugam Please check private messages!
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-07-26T02:43:54.6633333+00:00

Hello @Srinivasan Arumugam

Please confirm whether your issue is resolved or still facing any errors.
timothy jones 20 Reputation points

2026-07-26T03:52:39.0966667+00:00

Thank you and the very project i had in mind was thrust into life and there is actually a agent that has been trained to systematically destroy anything you have espousals academic career home life or whatever is posable I didn't now but whatever it might cost hopefully me quieting school and just putting everything away now more.

Answer 1

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:

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
Set actual non-empty values for all 4 secrets
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.

Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-07-30T02:59:18.1566667+00:00

Hello @Srinivasan Arumugam

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.

Answer 2

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.

Answer 3

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.

Answer 4

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/