Laboratório de Troubleshooting: Deploy resources by using an Azure Resource Manager template or a Bicep file
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de infraestrutura executa o deploy de um ARM template via Azure CLI para criar uma conta de armazenamento em uma assinatura de desenvolvimento. O template foi utilizado com sucesso na semana anterior na mesma assinatura. Desta vez, o comando retorna erro imediatamente, sem chegar a criar o resource group.
O ambiente usa uma política de nomenclatura corporativa aplicada via Azure Policy com efeito deny. A conta de armazenamento segue o padrão stgdeveastus001. O engenheiro responsável tem a role Contributor na assinatura. A região de destino é eastus. A versão da Azure CLI instalada é 2.57.0.
Comando executado:
az deployment sub create \
--location eastus \
--template-file main.bicep \
--parameters @params.dev.json
Saída:
ERROR: {"code":"InvalidDeploymentParameterValue","message":"The value '...' provided for the deployment parameter 'location' is not valid."}
O arquivo params.dev.json contém:
{
"location": {
"value": "East US"
}
}
Qual é a causa raiz do erro?
a) A role Contributor não possui permissão para executar deployments no escopo de assinatura (sub).
b) O valor do parâmetro location usa formatação com espaço e letra maiúscula em vez do identificador canônico esperado pelo template.
c) A Azure Policy com efeito deny está bloqueando o deploy da conta de armazenamento por violação de nomenclatura.
d) A versão da Azure CLI está desatualizada e não suporta deployments Bicep no escopo de assinatura.
Cenário 2 — Causa Raiz
Um engenheiro tenta fazer o deploy de uma solução completa usando um template ARM com recursos aninhados (nested templates). O deployment é iniciado com sucesso, todos os recursos aparecem como Running no portal por alguns minutos e, em seguida, o deployment falha com o status Conflict.
O template cria, na seguinte ordem declarada: uma VNet, uma subnet, um NSG e uma NIC associada à subnet. A assinatura não possui locks. O engenheiro possui a role Owner. Os logs do deployment no portal mostram:
Resource Microsoft.Network/networkInterfaces/nic-prod-001
OperationId: a3f2...
StatusCode: Conflict
Message: Another operation on this or dependent resource is in progress.
Nos últimos 30 dias, não houve alterações nas políticas da assinatura. A conta de armazenamento de diagnóstico referenciada no template existe e está acessível. O template não utiliza a propriedade dependsOn em nenhum recurso.
Qual é a causa raiz da falha?
a) O deployment falhou porque a conta de armazenamento de diagnóstico estava sendo acessada simultaneamente por outro processo.
b) A role Owner não é suficiente para criar recursos de rede no escopo de resource group quando o deployment é iniciado no escopo de assinatura.
c) A NIC está tentando se associar à subnet antes que esta e a VNet tenham concluído o provisionamento, pois não há dependsOn definido entre eles.
d) O status Conflict indica que já existe uma NIC com o mesmo nome na assinatura, causando colisão de recurso.
Cenário 3 — Decisão de Ação
Durante uma janela de manutenção programada de 30 minutos em produção, um engenheiro identifica que o deployment de um template Bicep falhou no recurso de número 7 de 12. A causa foi confirmada: o parâmetro sku do App Service Plan foi passado como F1 (camada gratuita), que não é permitida nesta assinatura por uma Azure Policy com efeito deny. Os recursos 1 a 6 foram criados com sucesso e estão em uso. A janela de manutenção termina em 12 minutos.
O engenheiro tem acesso ao arquivo de parâmetros e ao repositório Git. A pipeline de CI/CD que disparou o deployment está acessível. O ambiente não permite alterações manuais diretas nos recursos (enforce via policy de deployIfNotExists com auditoria ativa). Não há aprovação pendente de change request para este deployment.
Qual é a ação correta a tomar neste momento?
a) Corrigir o valor do parâmetro sku diretamente no portal Azure e reexecutar o deployment pelo portal para aproveitar o tempo restante da janela.
b) Atualizar o arquivo de parâmetros com o valor S1, realizar commit, abrir um change request e aguardar aprovação antes de reexecutar.
c) Corrigir o parâmetro sku no arquivo de parâmetros local e reexecutar o deployment via CLI dentro da janela, sem alterar o repositório.
d) Registrar o incidente, encerrar a janela sem concluir o deployment e agendar nova janela após corrigir o parâmetro no repositório e revalidar o template.
Cenário 4 — Impacto Colateral
Um engenheiro resolve um problema de deployment recorrente adicionando "mode": "Complete" ao ARM template de um resource group que gerencia 14 recursos de produção. O template declarado cobre apenas os 9 recursos que precisavam ser atualizados. O deployment é executado com sucesso e os 9 recursos são atualizados conforme esperado.
Qual consequência secundária essa ação pode causar?
a) O deployment no modo Complete exige que todos os recursos estejam no estado Succeeded antes de iniciar, o que pode causar falha se algum recurso estiver em estado de manutenção.
b) Os 5 recursos presentes no resource group mas ausentes do template serão excluídos pelo Azure Resource Manager ao final do deployment.
c) O Azure Resource Manager criará cópias dos 5 recursos não declarados no template como recursos órfãos em outro resource group.
d) O modo Complete impede que deployments futuros no modo Incremental sejam executados no mesmo resource group até que o lock seja removido manualmente.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: b
O erro InvalidDeploymentParameterValue indica que o valor fornecido para o parâmetro location é inválido. A pista decisiva está no arquivo params.dev.json: o valor "East US" usa espaço e maiúsculas, enquanto o ARM e o Bicep esperam o identificador canônico da região, que é "eastus" (tudo minúsculo, sem espaços). Essa discrepância de formato é suficiente para reprovar a validação do parâmetro antes mesmo de o deployment ser submetido à plataforma.
A informação sobre a Azure Policy com efeito deny é irrelevante neste cenário: a falha ocorre na fase de validação do parâmetro, antes de qualquer recurso ser avaliado pela policy. Se a policy fosse a causa, o erro teria código RequestDisallowedByPolicy, não InvalidDeploymentParameterValue.
O distrator mais perigoso é a alternativa c. Em ambientes com Azure Policy ativa, é tentador atribuir qualquer falha à policy, especialmente quando o enunciado menciona explicitamente uma policy de nomenclatura. O raciocínio correto é sempre observar o código e a mensagem de erro antes de assumir a causa.
A role Contributor é suficiente para deployments no escopo de assinatura e a versão 2.57.0 da CLI suporta Bicep normalmente. Ambos os distratores representam o erro de focar em detalhes do ambiente em vez de ler a mensagem de erro com atenção.
Gabarito — Cenário 2
Resposta: c
O log indica que a NIC tentou ser criada enquanto a subnet (ou a VNet) ainda estava em provisionamento. O Azure Resource Manager, por padrão, faz o deploy de recursos em paralelo quando não há dependências explícitas declaradas. Sem dependsOn, a NIC inicia sua criação antes que a VNet e a subnet estejam no estado Succeeded, o que gera o conflito de operação concorrente sobre recursos dependentes.
A pista no enunciado é direta: o template não utiliza a propriedade dependsOn em nenhum recurso, e a mensagem de erro diz literalmente Another operation on this or dependent resource is in progress.
A informação sobre a conta de armazenamento de diagnóstico é irrelevante: ela existe, está acessível e não aparece na cadeia de erro relatada.
O distrator mais perigoso é a alternativa d. A mensagem Conflict pode sugerir colisão de nome, mas o código HTTP 409 (Conflict) no contexto de operações de rede do Azure frequentemente indica conflito de operação concorrente, não duplicidade de recurso. Agir com base nesse distrator levaria o engenheiro a procurar e deletar um recurso inexistente, desperdiçando tempo.
Gabarito — Cenário 3
Resposta: d
O conjunto de restrições do cenário é determinante: o ambiente não permite alterações manuais diretas (policy de deployIfNotExists com auditoria ativa), não há change request aprovado, e o tempo restante é insuficiente para um ciclo completo de correção, commit, aprovação e reexecução segura.
A ação correta é encerrar a janela de forma controlada, registrar o incidente e agendar nova janela após corrigir e revalidar o template no repositório oficial.
A alternativa a viola a restrição de alterações manuais diretas. A alternativa c produz um estado de divergência entre o que foi executado e o que está versionado no repositório, o que é especialmente perigoso em ambientes com auditoria ativa. A alternativa b seria a correta em um contexto sem janela de manutenção prestes a encerrar, mas abrir um change request com 12 minutos restantes e aguardar aprovação não é viável e pode resultar em um deploy parcial ainda mais arriscado.
O distrator mais perigoso é c: corrigir localmente e reexecutar parece eficiente, mas cria divergência entre o estado real da infraestrutura e o repositório, quebrando o princípio de infraestrutura como código e dificultando auditorias futuras.
Gabarito — Cenário 4
Resposta: b
O modo Complete instrui o Azure Resource Manager a reconciliar o estado do resource group com o que está declarado no template. Recursos presentes no resource group mas ausentes do template são excluídos. Como o template cobre apenas 9 dos 14 recursos existentes, os 5 restantes serão removidos ao final do deployment bem-sucedido.
Esse é um dos impactos colaterais mais destrutivos e silenciosos do ARM, porque o deployment reporta sucesso, não erro. Nenhum alerta é emitido sobre os recursos excluídos durante a execução.
Os demais distratores descrevem comportamentos que não existem no ARM: o modo Complete não verifica o estado dos recursos existentes antes de iniciar, não cria recursos órfãos em outros resource groups e não impede deployments incrementais futuros.
O distrator mais perigoso é a, pois descreve um comportamento que parece plausível para um modo que "completa" o estado. Na prática, o modo Complete não verifica pré-condições dos recursos existentes.
Árvore de Troubleshooting: Deploy com ARM Templates e Bicep
Legenda de cores:
- Azul escuro: sintoma inicial (ponto de entrada)
- Azul: pergunta de diagnóstico (nó de decisão)
- Laranja: verificação intermediária ou estado a validar
- Vermelho: causa identificada
- Verde: ação recomendada ou resolução
Diante de um problema real, comece pelo nó raiz e responda cada pergunta com base no que é diretamente observável: o momento em que o erro ocorre, o código retornado, o comportamento dos recursos durante e após o deployment. Cada bifurcação elimina uma classe inteira de causas. Nunca pule para uma causa sem percorrer as perguntas intermediárias, pois sintomas visualmente semelhantes como Conflict e Policy têm origens e correções completamente distintas.