Plan for an ACI restart when changing managed identities

Source facts

Microsoft documents that enabling or updating managed identities on a running Container Instances group causes that group to restart. An identity change therefore has a documented runtime consequence, even when the container application itself is unchanged.

Enabling the identity is separate from granting it access to an Azure resource. Microsoft’s guidance requires the identity to receive access to the service resource it will use. Microsoft Learn.

Applicability

Identify the exact container group, current identity configuration, intended target resource, and workload owner. Review the source’s identity setup procedure for that scenario. Do not assume that a successful identity update also demonstrates that the application has resumed useful work.

DSE recommendation

DSE recommends scheduling the change around the workload’s restart tolerance. Record the existing identity configuration and approved target permissions before updating the group. Ask the application owner to define how in-flight work will be checked and what evidence will demonstrate recovery. Keep credential values and access tokens out of the change record.

Verification

In an authorized test group, observe the identity update and resulting restart, then exercise the intended service operation from the application. Check both the approved operation and a deliberately unauthorized operation. Reconcile application progress before and after the change, and record the identity and resource scope used for the test rather than relying solely on a portal success notification.

Official references

Microsoft Learn: Enable Managed Identity in a Container Group. Source retrieved September 9, 2026.