Pré-vôo: validação do servidor antes da implantação

No ARM (Azure Resource Manager), a validação do lado do servidor consiste em duas partes distintas:

  • Validação estática, que é a operação com a qual os desenvolvedores interagem.
  • Validação de simulação do provedor de recursos, que é a fase de validação interna do provedor de recursos.

A validação estática verifica aspectos do modelo que o ARM pode avaliar sem chamar provedores de recursos, como:

  • Estrutura de modelo e correção de esquema
  • Definições de parâmetro e restrições básicas de valor
  • Avaliação de expressão e consistência de modelo

Essas verificações garantem que o modelo seja sintaticamente e estruturalmente válido antes que ocorra uma validação mais profunda.

A validação de pré-vôo é um processo interno do ARM (Azure Resource Manager) executado durante a fase de validação. Sua finalidade é acelerar a detecção de erros impedindo implantações conhecidas por falharem. Durante essa etapa, o ARM invoca os provedores de recursos relevantes para verificar se a implantação é viável, sem criar ou modificar nenhum recurso. Esta parte valida:

  • Conflitos de nome de recurso: durante a simulação, o ARM avalia os nomes de recursos finais e resolvidos e verifica se eles violam a exclusividade imposta pelo provedor ou as regras de nomenclatura. Essa verificação ocorre após expressões como concat() ou uniqueString() são resolvidas. A validação de pré-vôo geralmente falha quando:

    • Um nome global exclusivo (por exemplo, um nome de conta de armazenamento) já foi obtido
    • Um nome de recurso viola restrições de nomenclatura específicas do provedor
  • Correção do escopo: a validação de pré-vôo garante que os recursos estejam sendo implantados em um escopo válido e que o comando de implantação corresponda aos tipos de recursos declarados no modelo. Essa validação inclui:

    • Se o escopo de implantação (grupo de recursos, assinatura, grupo de gerenciamento, locatário) é compatível com os tipos de recursos
    • Se existem os escopos principais necessários. Por exemplo, implantar um recurso cujo escopo é limitado a um grupo de recursos, no escopo da assinatura, sem envolver um grupo de recursos.
  • Permissões RBAC (se você pode implantar esses tipos de recursos): durante o pré-vôo, o ARM verifica se o chamador tem permissões suficientes no escopo de implantação para criar ou modificar os recursos solicitados. Se a identidade não tiver permissões, a implantação será rejeitada antes da execução. As falhas típicas de permissão de pré-vôo incluem:

    • Permissões de gravação ausentes para um tipo de recurso
    • Permissões insuficientes no escopo alvo
    • Provedores de recursos necessários não registrados
  • Compatibilidade básica do provedor e da API: a validação de pré-vôo confirma que:

    • Os provedores de recursos referenciados são registrados
    • As versões de API especificadas são válidas e têm suporte
    • O tipo de recurso é reconhecido por Azure Resource Manager

    Se um provedor não estiver registrado ou a versão da API for inválida, o ARM falhará na implantação durante o pré-lançamento.

Se qualquer uma dessas verificações falhar, a implantação nunca será iniciada.

Limitações

A validação pré-implantação é um processo de máximo esforço e não identifica todos os erros que podem ocorrer durante a implantação. Ele não pode detectar falhas de runtime (por exemplo, erros em uma extensão de script personalizada durante a execução) e sua validação pode estar incompleta quando os recursos dependem de valores que ainda não estão disponíveis, como propriedades geradas dinamicamente de outros recursos.

Permissões RBAC herdadas por meio de grupos de gerenciamento

Quando a validação de pré-lançamento é executada para os recursos no escopo do locatário ou do grupo de gerenciamento, o Azure Resource Manager avalia as permissões no escopo da solicitação de validação. Em alguns casos, o ARM não resolve toda a cadeia ancestral do grupo de gerenciamento durante essa avaliação. Como resultado, as atribuições de função RBAC herdadas por meio da hierarquia do grupo de gerenciamento talvez não sejam reconhecidas durante o pré-lançamento, mesmo que essas mesmas permissões sejam respeitadas durante a implantação real.

Esse comportamento pode fazer com que o pré-lançamento falhe com um erro de autorização (HTTP 401 ou 403) para as identidades que têm permissões suficientes por meio da herança do grupo de gerenciamento. A implantação real do mesmo modelo teria êxito porque o pipeline de criação de recursos padrão avalia totalmente as permissões herdadas.

Solução alternativa: atribua a função necessária (por exemplo, Colaborador ou Proprietário) diretamente no escopo da assinatura ou do grupo de recursos, em vez de depender exclusivamente das permissões herdadas do grupo de gerenciamento. Como alternativa, use a opção --validation-level Template (CLI do Azure 2.76.0+) ou -ValidationLevel Template (Azure PowerShell 13.4.0+) com os comandos what-if e validate para ignorar as verificações de permissão de pré-lançamento.

Executar a verificação preliminar

A validação de simulação é executada automaticamente quando você usa a validação de implantação ou comandos de estilo teste de hipóteses. Por exemplo, essas operações executam a validação de pré-voo:

Erros de pré-vôo aparecem no log de atividades, mas não no histórico de implantação, porque a implantação nunca começou.

Próximas Etapas