Laboratório de Troubleshooting: Interpret 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 template ARM via Azure CLI para provisionar uma Virtual Network com três subnets. O template foi validado com sucesso usando az deployment group validate e nenhum erro foi reportado. No entanto, ao executar o deploy real, o comando falha com a seguinte mensagem:
(InvalidTemplateDeployment) The template deployment failed because of policy violation.
PolicyDefinitionName: 'allowed-locations'
Resource: 'Microsoft.Network/virtualNetworks/myVnet'
RequestedLocation: 'brazilsouth'
AllowedLocations: 'eastus, westeurope'
O time nota que o arquivo de parâmetros usado no deploy contém a seguinte entrada:
"parameters": {
"vnetLocation": {
"value": "brazilsouth"
},
"vnetName": {
"value": "myVnet"
},
"addressPrefix": {
"value": "10.0.0.0/16"
}
}
O template usa [parameters('vnetLocation')] para definir a propriedade location da VNet. O template também foi usado com sucesso na semana anterior para criar uma VNet em eastus com um arquivo de parâmetros diferente. O repositório Git não registra nenhuma alteração no template desde então.
Qual é a causa raiz da falha no deploy?
A) O template contém um erro de sintaxe na função [parameters('vnetLocation')] que só é detectado em tempo de execução, não durante a validação.
B) O valor "brazilsouth" passado no arquivo de parâmetros viola uma Azure Policy aplicada ao escopo do resource group, que restringe os locais permitidos.
C) O comando az deployment group validate não valida parâmetros externos, portanto o arquivo de parâmetros foi ignorado e o deploy usou defaultValue incorreto.
D) A VNet myVnet já existe em eastus e o Azure bloqueou a tentativa de recriar o recurso em uma região diferente.
Cenário 2 — Decisão de Ação
Um administrador identifica que um deploy de template ARM falhou em produção com o seguinte erro:
(ResourceNotFound) The Resource 'Microsoft.Network/networkSecurityGroups/nsg-backend'
under resource group 'rg-prod' was not found.
O template implanta uma Virtual Machine que referencia um NSG existente via resourceId(). A investigação confirma que o NSG nsg-backend foi deletado acidentalmente por outro membro da equipe há 20 minutos. O ambiente de produção está parcialmente degradado porque novas VMs não podem ser provisionadas. A equipe tem um backup do template original que criou o NSG, armazenado no repositório. O Service Principal usado pelo pipeline tem permissão de Contributor no resource group.
Recriar o NSG imediatamente restauraria a capacidade de provisionar novas VMs, mas as regras de segurança associadas ao NSG precisam ser revisadas pelo time de segurança antes da aplicação. O time de segurança está disponível e pode revisar em até 30 minutos.
Qual é a ação correta a tomar neste momento?
A) Executar imediatamente o deploy do template de backup para recriar o NSG com todas as regras originais, restaurando o ambiente sem aguardar revisão.
B) Aguardar a revisão completa do time de segurança e só então recriar o NSG usando o template de backup, aceitando o período de degradação.
C) Recriar o NSG manualmente via portal Azure sem nenhuma regra de entrada ou saída, e aguardar a revisão do time de segurança antes de aplicar as regras via template.
D) Abrir um ticket de suporte à Microsoft para restaurar o NSG deletado a partir de um snapshot de infraestrutura gerenciado pela plataforma.
Cenário 3 — Causa Raiz
Um arquivo Bicep é compilado e deployado com sucesso. Após o deploy, um desenvolvedor tenta acessar o valor de saída storageKey via CLI com o seguinte comando:
az deployment group show \
--resource-group rg-dev \
--name main \
--query properties.outputs.storageKey.value
O comando retorna null. O arquivo Bicep contém o seguinte trecho:
resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
name: storageAccountName
location: resourceGroup().location
sku: { name: 'Standard_LRS' }
kind: 'StorageV2'
}
output storageKey string = storageAccount.listKeys().keys[0].value
O desenvolvedor confirma que o deploy foi concluído com status Succeeded. O resource group rg-dev contém apenas esse deploy. A storage account está visível no portal e operacional. O desenvolvedor tem a role Reader atribuída no resource group.
Qual é a causa raiz do retorno null para o output storageKey?
A) A função listKeys() não é suportada em blocos output de arquivos Bicep e o compilador a ignora silenciosamente, gerando um output vazio.
B) O nome do parâmetro no comando CLI está incorreto; o output correto seria storagekeys em letras minúsculas, pois Bicep normaliza nomes de output.
C) O desenvolvedor não tem permissão para ver o valor do output, pois listKeys() exige a action Microsoft.Storage/storageAccounts/listKeys/action, que não está incluída na role Reader.
D) O deploy foi executado por um Service Principal diferente e outputs gerados por outros principals ficam ocultos para usuários com role Reader.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte erro ao executar o deploy de um template ARM complexo com múltiplos recursos interdependentes:
(CircularDependency) Found circular dependency for resource
'Microsoft.Compute/virtualMachines/vm-app'.
Dependencies: vm-app -> nic-app -> pip-app -> vm-app
O engenheiro precisa investigar e corrigir o problema. Os passos disponíveis são:
- P1: Remover ou corrigir a dependência que fecha o ciclo, garantindo que o grafo de dependências seja um DAG (directed acyclic graph).
- P2: Localizar no template o recurso
vm-appe inspecionar seu blocodependsOn. - P3: Verificar se o recurso
pip-app(Public IP) referencia ou declara dependência explícita devm-app. - P4: Confirmar que o deploy executa com sucesso após a correção e que todos os recursos foram provisionados na ordem esperada.
- P5: Rastrear a cadeia de dependências declaradas a partir de
vm-apppara identificar onde o ciclo se fecha.
Qual é a sequência correta de investigação e resolução?
A) P2, P5, P3, P1, P4
B) P3, P2, P5, P4, P1
C) P5, P3, P1, P2, P4
D) P2, P3, P5, P4, P1
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A mensagem de erro é explícita: PolicyDefinitionName: 'allowed-locations' e RequestedLocation: 'brazilsouth'. Isso indica que uma Azure Policy aplicada ao escopo bloqueou o deploy porque a localização solicitada não está na lista de locais permitidos pela política. O arquivo de parâmetros passou "brazilsouth" corretamente ao template, e o template usou esse valor corretamente, mas a política de plataforma impediu a criação do recurso nessa região.
A informação irrelevante no cenário é o histórico de uso bem-sucedido em eastus na semana anterior. Esse fato confirma que o template é sintaticamente válido, mas não tem relação com a falha atual, que é de conformidade de política, não de sintaxe.
O principal erro de diagnóstico que os distratores representam é focar no template como origem do problema. A alternativa A confunde o comportamento da validação com erros de runtime de sintaxe, que não se aplicam aqui. A alternativa C descreve incorretamente o comportamento do validate, que sim considera arquivos de parâmetros externos quando fornecidos. A alternativa D é tecnicamente improvável e não está suportada por nenhuma evidência no enunciado.
O distrator mais perigoso é A, pois levaria o engenheiro a procurar um erro de sintaxe no template quando o problema real está na configuração de política da subscription ou do resource group.
Gabarito — Cenário 2
Resposta: B
O cenário estabelece duas restrições críticas: o ambiente está degradado (pressão para agir rápido) e as regras do NSG precisam de revisão de segurança (restrição de governança). A opção B respeita ambas as restrições, aceitando o período de degradação de até 30 minutos enquanto o time de segurança valida as regras antes de recriar o recurso com configuração verificada.
A opção A ignora a restrição de segurança explícita no enunciado. Em produção, recriar um NSG com regras não revisadas pode introduzir uma janela de exposição maior do que a degradação atual. A opção C é tecnicamente possível, mas cria um NSG sem regras, o que pode bloquear tráfego legítimo e agravar a degradação. A opção D é incorreta porque o Azure não oferece restauração automática de recursos deletados via suporte para NSGs.
A restrição de tempo de 30 minutos para a revisão é a pista-chave: ela torna a espera viável e retira a justificativa para agir imediatamente sem validação.
Gabarito — Cenário 3
Resposta: C
A função listKeys() em Bicep é uma listaction que, quando usada em um bloco output, exige que o principal que executa a consulta ao deploy tenha a permissão Microsoft.Storage/storageAccounts/listKeys/action. Essa permissão não está incluída na role Reader. Quando o usuário executa az deployment group show, o Azure avalia se ele tem permissão para ver o valor daquele output específico. Como não tem, retorna null em vez de um erro explícito.
A informação irrelevante é o status Succeeded do deploy e a visibilidade da storage account no portal. Ambos confirmam que o recurso foi criado corretamente, mas não têm relação com a capacidade de ler o valor do output que depende de uma listaction privilegiada.
A alternativa A é falsa: listKeys() é suportada em outputs de Bicep e não é ignorada silenciosamente. A alternativa B é falsa: Bicep preserva a capitalização dos nomes de output declarados. O distrator mais perigoso é A, pois levaria o engenheiro a reescrever o Bicep em vez de ajustar as permissões do usuário.
Gabarito — Cenário 4
Resposta: A — P2, P5, P3, P1, P4
A sequência correta parte do recurso identificado no erro (vm-app), inspeciona suas dependências declaradas, rastreia a cadeia completa para localizar onde o ciclo se fecha, identifica o recurso que cria o fechamento do ciclo (pip-app referenciando vm-app), corrige a dependência problemática e valida o deploy.
Começar por P3 (alternativa B) seria investigar um recurso intermediário antes de entender o ponto de origem declarado no erro, o que é diagnóstico desordenado. A alternativa C pula direto para rastrear a cadeia sem primeiro localizar o ponto de entrada no template, tornando o rastreamento mais difícil. A alternativa D adia a correção para depois de P4, o que não faz sentido pois P4 é a validação final.
A lógica correta é sempre partir do recurso identificado no erro, expandir o grafo progressivamente e corrigir antes de validar.
Árvore de Troubleshooting: Interpret an Azure Resource Manager template or a Bicep file
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Laranja | Validação ou verificação intermediária |
| Verde | Ação recomendada ou resolução |
Ao enfrentar um problema real com templates ARM ou arquivos Bicep, comece pelo nó raiz descrevendo o sintoma observado. A cada nó de pergunta, responda com base no que você pode verificar diretamente na mensagem de erro ou no comportamento do deploy. Siga o caminho que corresponde ao seu contexto até alcançar um nó vermelho (causa identificada) ou laranja (verificação necessária), e então avance para o nó verde correspondente, que indica a ação de resolução. O diagrama cobre os caminhos mais frequentes e pode ser percorrido em qualquer ordem conforme o sintoma apresentado.