Você opera um conjunto de dimensionamento de VM (VM scale set) e vários Function Apps que devem acessar o Azure Key Vault e o Azure Storage com uma identidade comum e reutilizável entre recursos e regiões. A identidade deve sobreviver a qualquer recurso individual. As cargas de trabalho também precisam obter tokens OAuth para chamar uma API parceira que confia no Entra ID, sem armazenar segredos. O que você deve fazer? Cada resposta correta apresenta parte da solução.

A criação de uma identidade gerenciada atribuída pelo usuário (User-Assigned Managed Identity - UAMI) é a solução correta porque ela pode ser criada uma vez e atribuída a vários recursos (VM scale set e Function Apps), permitindo uma identidade comum e reutilizável que sobrevive a recursos individuais. As funções Key Vault Secrets User e Storage Blob Data Contributor concedem as permissões necessárias. Solicitar tokens para a API parceira a partir do código usando o endpoint da identidade gerenciada (IMDS para VMs ou o endpoint de token do App Service) é o método correto para obter tokens OAuth sem armazenar segredos, pois a identidade gerenciada lida com a autenticação subjacente. As identidades gerenciadas atribuídas ao sistema não são ideais porque são vinculadas ao ciclo de vida de um único recurso e não podem ser compartilhadas entre eles. Criar um registro de aplicativo com um segredo de cliente e armazená-lo no Key Vault introduz a complexidade de gerenciar e recuperar o segredo, o que as identidades gerenciadas evitam. Usar a API legada do Azure AD Graph é incorreto, pois o Microsoft Graph é a API recomendada e as identidades gerenciadas suportam a obtenção de tokens para qualquer recurso que confie no Entra ID.