Laboratório de Troubleshooting: Create a virtual network (VNet)
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de infraestrutura criou uma nova VNet chamada vnet-producao na região brazilsouth com o espaço de endereçamento 10.10.0.0/16. Em seguida, criaram três sub-redes:
| Sub-rede | Prefixo |
|---|---|
| snet-app | 10.10.1.0/24 |
| snet-data | 10.10.2.0/24 |
| snet-mgmt | 10.10.3.0/24 |
Dois dias depois, a equipe tentou adicionar uma quarta sub-rede chamada snet-firewall com o prefixo 10.10.4.0/24. A operação falhou. O engenheiro executou o comando abaixo para investigar:
az network vnet subnet list \
--resource-group rg-networking \
--vnet-name vnet-producao \
--output table
A saída retornou as três sub-redes existentes sem erros. O engenheiro então verificou que o grupo de recursos rg-networking tem uma política do Azure aplicada que restringe a criação de recursos a regiões específicas, mas brazilsouth está na lista de regiões permitidas. A assinatura está ativa e dentro dos limites de cota. O portal do Azure exibiu a seguinte mensagem de erro durante a tentativa:
The subnet 'snet-firewall' is invalid because its name is reserved for a specific Azure service.
Subnet name 'AzureFirewallSubnet' is required for Azure Firewall deployments.
Code: InvalidResourceName
Qual é a causa raiz da falha ao criar a sub-rede?
A) A política do Azure aplicada ao grupo de recursos está bloqueando a criação de novas sub-redes com nomes personalizados.
B) O nome snet-firewall não é aceito pelo Azure porque sub-redes destinadas ao Azure Firewall exigem o nome exato AzureFirewallSubnet.
C) O espaço de endereçamento 10.10.0.0/16 está esgotado após a criação das três sub-redes anteriores.
D) A cota de sub-redes por VNet foi atingida, impedindo a criação de uma quarta sub-rede.
Cenário 2 — Decisão de Ação
A equipe de rede identificou que a VNet vnet-hub e a VNet vnet-spoke-rh não conseguem estabelecer peering. A investigação confirmou que a causa é uma sobreposição de espaços de endereçamento: ambas usam 172.16.0.0/16.
O ambiente tem as seguintes restrições:
vnet-hubpossui 12 VMs em produção ativas com IPs dentro de172.16.0.0/16vnet-spoke-rhfoi criada há 2 horas e ainda não tem nenhum recurso implantado- A janela de manutenção disponível é de 4 horas, iniciando agora
- A equipe tem permissão para recriar recursos na
vnet-spoke-rh - Não há permissão para modificar a
vnet-hubsem aprovação de mudança de nível 2, que leva 48 horas
Qual é a ação correta a tomar dentro da janela de manutenção disponível?
A) Recriar a vnet-hub com um novo espaço de endereçamento e migrar as 12 VMs, aproveitando a janela de 4 horas.
B) Adicionar um segundo espaço de endereçamento em vnet-hub para resolver a sobreposição sem recriar recursos.
C) Recriar a vnet-spoke-rh com um espaço de endereçamento diferente, como 172.17.0.0/16, que não conflite com vnet-hub.
D) Solicitar aprovação de mudança de nível 2 imediatamente e aguardar 48 horas para modificar vnet-hub.
Cenário 3 — Causa Raiz
Um engenheiro relatou que, ao tentar implantar um recurso do Azure Bastion em uma VNet existente chamada vnet-acesso, a implantação falha consistentemente. A VNet foi criada há 3 meses com espaço de endereçamento 10.50.0.0/16 e contém as seguintes sub-redes:
| Sub-rede | Prefixo | Uso atual |
|---|---|---|
| snet-vms | 10.50.1.0/24 | 18 VMs ativas |
| snet-appgw | 10.50.2.0/24 | Application Gateway |
| AzureBastionSubnet | 10.50.3.0/27 | Vazio |
O engenheiro verificou que:
- O nome da sub-rede está correto
- Não há NSG aplicado à sub-rede
AzureBastionSubnet - A assinatura tem cota disponível para o Azure Bastion
- O recurso Azure Bastion Standard foi selecionado como SKU
A mensagem de erro retornada pelo portal é:
Deployment failed: The subnet '/subscriptions/.../AzureBastionSubnet'
does not have enough address space for the Azure Bastion resource.
Minimum required prefix length: /26.
Code: SubnetTooSmall
O engenheiro acredita que o problema é o NSG ausente, pois leu em um artigo que o Azure Bastion requer regras de NSG específicas.
Qual é a causa raiz real da falha?
A) A ausência de um NSG na sub-rede AzureBastionSubnet está impedindo a implantação do Azure Bastion.
B) O SKU Standard do Azure Bastion não é compatível com VNets que já contêm outros recursos implantados.
C) O prefixo /27 da sub-rede AzureBastionSubnet é menor que o mínimo exigido de /26 para o Azure Bastion.
D) O espaço de endereçamento 10.50.0.0/16 não é roteável pelo Azure Bastion por ser um bloco privado de classe B.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: "Criamos uma VNet nova com peering para a VNet de hub, mas as VMs na VNet nova não conseguem resolver nomes DNS de recursos internos na VNet de hub."
Os passos de investigação disponíveis são:
- Verificar se o peering está configurado nos dois lados e com status
Connected - Verificar as configurações de DNS da VNet nova para identificar qual servidor DNS está sendo usado
- Confirmar que as VMs na VNet nova conseguem alcançar o IP do servidor DNS configurado
- Testar resolução de nome diretamente a partir de uma VM na VNet nova usando
nslookupoudig - Verificar se o servidor DNS interno da organização tem zona configurada para os domínios internos relevantes
Qual é a sequência correta de investigação para esse sintoma?
A) 4 → 1 → 2 → 3 → 5
B) 1 → 2 → 3 → 4 → 5
C) 2 → 1 → 3 → 5 → 4
D) 1 → 4 → 2 → 3 → 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A mensagem de erro no enunciado é conclusiva: InvalidResourceName com a descrição indicando que o nome da sub-rede é reservado para uso pelo Azure Firewall. O Azure impõe que a sub-rede destinada ao Azure Firewall se chame exatamente AzureFirewallSubnet. O nome snet-firewall não atende a essa exigência.
A informação sobre a política do Azure restringindo regiões é irrelevante neste cenário, pois brazilsouth está na lista permitida e a mensagem de erro não indica bloqueio por política. Esse detalhe foi incluído propositalmente para desviar o foco.
A alternativa C é falsa porque 10.10.0.0/16 comporta centenas de sub-redes /24. A alternativa D é um distrator plausível, mas a cota padrão de sub-redes por VNet no Azure é de 3.000, muito acima de 4. O distrator mais perigoso é o A: um engenheiro que seguisse esse caminho gastaria tempo revisando políticas e abrindo chamados com o time de governança sem nunca chegar à causa real.
Gabarito — Cenário 2
Resposta: C
A causa está identificada e as restrições são precisas: vnet-hub não pode ser modificada sem aprovação de 48 horas, e vnet-spoke-rh foi criada há 2 horas sem nenhum recurso. A única ação tecnicamente válida e operacionalmente viável dentro da janela de 4 horas é recriar vnet-spoke-rh com um espaço de endereçamento que não conflite com vnet-hub.
A alternativa A ignora a restrição crítica: modificar vnet-hub exige aprovação de nível 2. Mesmo que a janela de 4 horas fosse suficiente tecnicamente, a ação seria inválida dentro das regras do ambiente. A alternativa B é tecnicamente incorreta: adicionar um segundo espaço de endereçamento em vnet-hub não resolve a sobreposição porque vnet-spoke-rh também usa 172.16.0.0/16. A alternativa D é válida como processo, mas desperdiça a janela de manutenção disponível e ignora que o problema pode ser resolvido agora sem esperar 48 horas.
Gabarito — Cenário 3
Resposta: C
A mensagem de erro é direta: SubnetTooSmall com indicação explícita de que o prefixo mínimo exigido é /26. A sub-rede AzureBastionSubnet foi criada com /27, que fornece apenas 32 endereços, abaixo do mínimo de 64 exigidos pelo Azure Bastion.
A informação de que o engenheiro acredita que o problema é o NSG ausente é uma armadilha explícita. O NSG no Azure Bastion é opcional e sua ausência não impede a implantação. Esse detalhe foi incluído para testar se o leitor ignora a crença do engenheiro e lê o log de erro com atenção.
A alternativa B é falsa; o SKU Standard é compatível com VNets compartilhadas. A alternativa D é tecnicamente absurda: blocos RFC 1918 são totalmente suportados pelo Azure. O distrator mais perigoso é o A: um engenheiro que seguisse essa direção criaria e configuraria um NSG sem resolver o problema, perdendo tempo em produção.
Gabarito — Cenário 4
Resposta: B
A sequência correta é 1 → 2 → 3 → 4 → 5, que segue a lógica de diagnóstico progressivo da camada de conectividade para a camada de aplicação:
- Primeiro confirmar que o peering está ativo nos dois lados, pois sem isso nenhuma comunicação é possível.
- Em seguida verificar qual servidor DNS está configurado na VNet, já que esse é o ponto central do problema relatado.
- Confirmar que o servidor DNS está alcançável a partir das VMs, validando conectividade de rede até o resolvedor.
- Somente então testar a resolução de nome diretamente, pois agora há base para interpretar o resultado.
- Por último, verificar se o servidor DNS interno tem a zona configurada, o que é uma investigação no lado do servidor, não da VNet.
A alternativa A começa pelo teste de sintoma sem validar nenhuma camada de suporte, o que pode levar a conclusões falsas. A alternativa C pula a validação do peering, que é o pré-requisito de tudo. A alternativa D inverte as etapas 2 e 4, testando resolução antes de saber qual DNS está sendo consultado, o que torna o diagnóstico cego.
Árvore de Troubleshooting: Create a virtual network (VNet)
Legenda de cores:
- Azul escuro: sintoma inicial ou ponto de entrada do diagnóstico
- Azul médio: pergunta diagnóstica ou ponto de decisão
- Vermelho: causa identificada
- Verde: ação recomendada ou resolução
- Laranja: verificação intermediária de validação
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma geral. Em cada nó azul, responda à pergunta com base no que você observa no ambiente, sem presumir a resposta. Siga o caminho correspondente até alcançar um nó vermelho, que identifica a causa, ou um nó verde, que indica a ação a tomar. Se o caminho levar a um nó laranja, realize a verificação indicada antes de prosseguir. A disciplina de seguir a sequência sem pular etapas é o que diferencia um diagnóstico correto de uma ação precipitada.