Supply the principal type when a just-created identity's Azure role assignment races replication

Source facts

Microsoft documents that role assignment can fail immediately after service-principal creation because replication to another region may not yet have completed. A script that creates a managed identity and then assigns a role can encounter this condition; replication delay is a possible cause, not a diagnosis for every failure.

For this scenario, the documented Azure CLI request supplies –assignee-object-id and sets –assignee-principal-type to ServicePrincipal. The intended role and scope remain separate inputs. Microsoft Learn.

Applicability

Confirm that the failing assignment follows new identity creation and that the object ID belongs to the intended principal. Examine the actual error and caller’s assignment authority before selecting the remedy.

DSE recommendation

DSE recommends making object identity and principal type explicit in the supported automation path. Preserve the least-privileged role and approved scope rather than substituting a broader role to work around a timing problem. If the failure persists, investigate its specific cause instead of repeatedly creating identities or assuming every authorization error is replication lag.

Verification

In an approved test, inspect the created identity and resulting assignment using their stable identifiers. Confirm that the assignment references the expected principal, role and scope, then test the intended access separately. Record failures and timing without claiming a fixed replication delay. A successful assignment should not be reported as proof that all resource-specific access prerequisites have been met.

Official references

Microsoft Learn: Assign Azure roles using Azure CLI – Azure RBAC. Source retrieved September 9, 2026.