Failed to provision revision for container app 'app-name'. Error details: Identity with resource ID 'system-environment' not found for registry registry-name.. (Code: ContainerAppOperationError)

Question

Failed to provision revision for container app 'app-name'. Error details: Identity with resource ID 'system-environment' not found for registry registry-name.. (Code: ContainerAppOperationError)

Seelam, Bharath 0

I have a private Azure Container Registry and I am deploying a container app which pulls image from the registry. The container app uses a user assigned managed identity with AcrPull Permissions on the registry and the user assigned managed identity is configured on the Container Apps Environment. The container app is successfully pulling image from the registry and getting deployed in one environment(like dev env), but getting the below error while deploying in another environment(like stage env). Is this a bug from Azure Side ??

{

"code": "ContainerAppOperationError",

"message": "Failed to provision revision for container app '<app-name>'. Error details: Identity with resource ID 'system-environment' not found for registry <registry-name>"

}

Seelam, Bharath 0 Reputation points

2026-03-16T12:43:24.9533333+00:00
Hi @Praveen Kumar Gudipudi ,
Thank you for your response on this.
For your information, I am deploying the container app using Azure Bicep. So I am only changing the resource names like container app name and user assigned managed identity name as per the environment. The rest of the configuration is same for all envs.

System Assigned Managed Identity on the container apps environment is also disabled. And User Assigned Managed Identity is enabled on the Container Apps Environment with AcrPull permission.

While configuring the registry configuration on the container app, we are referencing directly to the resource id of the user assigned managed identity like in the below image.

Even after the deployment failure due to system-environment identity, the exported bicep template of the container app actually shows the user assigned managed identity being configured on the registry. Not sure why it is referring system-environment.
Praveen Kumar Gudipudi 2,275 Reputation points Microsoft External Staff Moderator

2026-03-16T16:44:28.74+00:00

Hello Seelam, Bharath,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Seelam, Bharath 0

The issue was fixed after we ran the bicep deployment for multiple times. Actually this error was caused due to a shift from System Assigned Managed Identity(SAMI) to User Assigned Managed Identity(UAMI). Here is what Copilot said:

On the first run, ARM sent the full resource PUT for each of the 4 apps. ACA began provisioning a new revision immediately and evaluated registry credentials using what was already in the running app's configuration — system-environment from the pre-UAMI revision — before the new registry config from the PUT had taken effect. The system-assigned identity was already disabled, so it failed.

On the retry, the ARM deployment was picking up from a fresh state for those 4 apps (the failed first attempt left no partial revision). This time ARM's PUT updated configuration.registries to the UAMI first, and ACA used that updated config when pulling the image for the new revision — succeeding.

In short: a transient ordering issue in how ACA applies configuration vs. provisions revisions. The retry hit the correct ordering where the registry identity update landed before the image pull was attempted. This also means the underlying environment is healthy — the UAMI, ACR access, and app bicep are all correct — the failure was a one-time race condition on first application of the new registry config to an existing app that still carried system-environment.

2 answers

Your answer

Seelam, Bharath 0 Reputation points

2026-03-16T12:43:24.9533333+00:00

Hi @Praveen Kumar Gudipudi ,
Thank you for your response on this.
For your information, I am deploying the container app using Azure Bicep. So I am only changing the resource names like container app name and user assigned managed identity name as per the environment. The rest of the configuration is same for all envs.

System Assigned Managed Identity on the container apps environment is also disabled. And User Assigned Managed Identity is enabled on the Container Apps Environment with AcrPull permission.

While configuring the registry configuration on the container app, we are referencing directly to the resource id of the user assigned managed identity like in the below image.

Even after the deployment failure due to system-environment identity, the exported bicep template of the container app actually shows the user assigned managed identity being configured on the registry. Not sure why it is referring system-environment.
Praveen Kumar Gudipudi 2,275 Reputation points Microsoft External Staff Moderator

2026-03-16T16:44:28.74+00:00

Hello Seelam, Bharath,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
Seelam, Bharath 0 Reputation points

2026-03-18T06:37:19.4133333+00:00

The issue was fixed after we ran the bicep deployment for multiple times. Actually this error was caused due to a shift from System Assigned Managed Identity(SAMI) to User Assigned Managed Identity(UAMI). Here is what Copilot said:

On the first run, ARM sent the full resource PUT for each of the 4 apps. ACA began provisioning a new revision immediately and evaluated registry credentials using what was already in the running app's configuration — system-environment from the pre-UAMI revision — before the new registry config from the PUT had taken effect. The system-assigned identity was already disabled, so it failed. On the retry, the ARM deployment was picking up from a fresh state for those 4 apps (the failed first attempt left no partial revision). This time ARM's PUT updated configuration.registries to the UAMI first, and ACA used that updated config when pulling the image for the new revision — succeeding. In short: a transient ordering issue in how ACA applies configuration vs. provisions revisions. The retry hit the correct ordering where the registry identity update landed before the image pull was attempted. This also means the underlying environment is healthy — the UAMI, ACR access, and app bicep are all correct — the failure was a one-time race condition on first application of the new registry config to an existing app that still carried system-environment.

Answer 1

Hello Seelam, Bharath,

This behavior is typically not an Azure bug, but rather a configuration difference between environments.

The error message indicates that the Container App is attempting to use the environment system identity (system-environment) to authenticate with the private Azure Container Registry (ACR):

Identity with resource ID 'system-environment' not found for registry <registry-name>

Even though a User Assigned Managed Identity (UAMI) with AcrPull permissions is configured, the container app in the failing environment appears to be referencing the environment identity instead of the user-assigned identity.

In the environment where deployment succeeds (e.g., Dev), one of the following is likely true:

The container app registry configuration explicitly references the User Assigned Managed Identity, or

The Container Apps Environment system-assigned identity is enabled and has AcrPull permission on the ACR.

In the environment where deployment fails (e.g., Stage), the container app registry configuration is likely set to:

identity: system-environment

If the Container Apps Environment system identity is not enabled, Azure cannot resolve this identity and the revision provisioning fails.

Recommended checks:

Verify the container app registry configuration:

az containerapp show --name <app-name> --resource-group <rg> --query properties.configuration.registries

If the output shows:

"identity": "system-environment"

then the app is using the environment identity.

If you intend to use the User Assigned Managed Identity, explicitly configure it for the registry:

az containerapp registry set --name <app-name> --resource-group <rg> --server <registry-name>.azurecr.io --identity <user-managed-identity-resource-id>

Alternatively, enable the system-assigned identity on the Container Apps Environment and grant it the AcrPull role on the ACR.

Once the registry authentication identity is aligned with the identity that actually exists in the environment, the container app revision should provision successfully.

Please accept as answer and do a Thumbs-up to upvote this response if you are satisfied with the community help. Your upvote will be beneficial for the community users facing similar issues.

Answer 2

The error indicates that the container app is configured to use a managed identity named system-environment for the registry, but that identity does not exist or is not correctly configured in the staging environment. It is an environment/configuration issue, not a general Azure bug.

Key points from the platform behavior:

To pull from Azure Container Registry using managed identity, the identity must be:
- Enabled on the container app (system-assigned or user-assigned), and
- Granted the AcrPull role on the target registry.
When using managed identity with a registry in Container Apps, the registry configuration must reference either:
- system for the system-assigned identity, or
- The resource ID of a user-assigned identity.

In the working (dev) environment, the configuration and identity assignments are correct. In the failing (stage) environment, the registry configuration is trying to use an identity with resource ID system-environment, which is not a valid built-in keyword (system is) and does not match an existing user-assigned identity resource ID.

To fix the staging environment:

Verify the managed identity on the container app:
- Ensure the correct user-assigned identity is added to the container app (or system-assigned identity is enabled) in the staging environment.
- For system-assigned identity, configure it as shown in the managed identity documentation (Identity → System assigned → On, or via az containerapp identity assign --system-assigned).
Verify AcrPull role assignment:
- Confirm that the same identity (system or user-assigned) has the AcrPull role on the staging registry, similar to the documented pattern:
  - Assign AcrPull to the identity principal ID at the registry scope.
Correct the registry configuration for the container app in staging:
- If using system-assigned identity, ensure the registry is configured with identity: system (not system-environment) as in the documented az containerapp registry set example.
- If using a user-assigned identity, ensure the registry configuration uses the user-assigned identity’s resource ID, not a placeholder or environment name.
Redeploy or create a new revision after fixing the identity/registry configuration so the platform can provision the revision and pull the image successfully.

This mismatch between the identity reference (system-environment) and actual identities configured in the staging environment is the cause of the error.

References:

Share via

Failed to provision revision for container app 'app-name'. Error details: Identity with resource ID 'system-environment' not found for registry registry-name.. (Code: ContainerAppOperationError)

2 answers

Your answer