You will deploy an application (App1) on multiple Azure virtual machines now and in the future. Requirements for these VMs: they must authenticate with Azure AD to access an Azure Key Vault, Azure Logic Apps, and an Azure SQL Database; you must avoid assigning new roles or credentials each time new VMs are added; secrets and certificates must not be stored on the VMs; and identity management overhead should be minimized. Which type of identity should you use?

A user-assigned managed identity is the correct choice because it can be created once and then assigned to multiple Azure resources, including virtual machines. This fulfills the requirement to avoid assigning new roles or credentials each time new VMs are added. It also centralizes identity management, minimizing overhead. Managed identities inherently avoid storing secrets or certificates on the VMs, as Azure manages the credentials. System-assigned managed identities are tied to the lifecycle of a single resource, meaning each new VM would get a new identity, violating the "avoid assigning new roles" requirement. Service principals with certificates or client secrets require manual credential management and rotation, increasing overhead and the risk of storing secrets on VMs, which contradicts the stated requirements.