Laboratório de Troubleshooting: Configure Public IP Addresses
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de infraestrutura reporta que uma aplicação web hospedada em uma VM no Azure parou de responder externamente após uma operação de manutenção noturna. A VM foi desalocada e reiniciada como parte de uma janela de patching. O NSG associado à interface de rede não foi alterado e continua com as mesmas regras de entrada na porta 443. O administrador verifica o status da VM no portal e confirma que ela está no estado Running. O DNS externo aponta para o mesmo endereço IP que funcionava antes.
Saída do comando executado após a falha:
az network public-ip show \
--resource-group rg-webapp \
--name pip-webapp \
--query "{ip: ipAddress, method: publicIpAllocationMethod, sku: sku.name}" \
--output table
Ip Method Sku
------------ --------- -----
20.85.110.44 Dynamic Basic
O administrador confirma que o DNS externo ainda aponta para 20.85.110.67, que era o endereço antes da manutenção. A VM foi migrada para um hardware diferente durante o patching. O storage account vinculado à VM tem redundância LRS configurada.
Qual é a causa raiz da falha de acesso externo?
A) O NSG foi redefinido para o estado padrão durante a realocação de hardware e está bloqueando a porta 443. B) O endereço IP público com atribuição Dinâmica foi alterado após a desalocação da VM, e o DNS externo ainda aponta para o IP antigo. C) A migração para hardware diferente gerou uma nova interface de rede, invalidando o vínculo entre o IP público e a VM. D) O SKU Basic não suporta reinicializações em hardware diferente e precisa ser recriado manualmente após migrações de host.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: o Public IP Address associado ao Load Balancer Standard de produção está configurado com SKU Basic. A equipe percebeu isso ao tentar habilitar zonas de disponibilidade no Load Balancer, operação que falhou com a seguinte mensagem:
Code: PublicIPAddressCannotBeUsedWithStandardLoadBalancer
Message: The public IP address 'pip-lb-prod' with sku 'Basic' cannot be
used with a resource that has sku 'Standard'.
O ambiente é de produção ativa, com tráfego real de usuários. Não há janela de manutenção programada nas próximas 6 horas. Existe um segundo endereço IP público de SKU Standard disponível no mesmo resource group, já criado e sem associação. O IP Basic atual tem o endereço 40.112.88.203, que está registrado no DNS externo da empresa com TTL de 3600 segundos.
Qual é a ação correta a tomar neste momento?
A) Atualizar o SKU do IP existente de Basic para Standard diretamente pelo portal do Azure para evitar mudança de endereço.
B) Substituir imediatamente o IP Basic pelo IP Standard disponível no Load Balancer, atualizando o DNS externo em seguida.
C) Documentar o problema, registrar o IP Standard disponível como solução aprovada e aguardar a próxima janela de manutenção para realizar a troca com impacto controlado.
D) Criar um novo IP Standard com o mesmo endereço 40.112.88.203 para evitar atualização do DNS antes de realizar a troca.
Cenário 3 — Causa Raiz
Um administrador recebe um alerta de que uma VM de produção está inacessível via SSH. Ele verifica o portal e observa que a VM está no estado Running. O NSG da subnet permite SSH na porta 22 de qualquer origem. O administrador tenta conectar diretamente pelo IP público e recebe timeout. Nenhuma alteração de NSG foi feita nas últimas 24 horas.
O administrador executa o seguinte comando para verificar o IP público:
az network public-ip show \
--resource-group rg-infra \
--name pip-vm-linux \
--query "{ip: ipAddress, state: provisioningState, sku: sku.name}" \
--output table
Ip State Sku
---- --------- --------
None Succeeded Standard
A VM foi criada há três semanas e funcionava normalmente. O disco OS da VM foi expandido de 64 GB para 128 GB ontem à tarde. O administrador confirma que o IP público pip-vm-linux aparece como recurso existente no resource group e seu provisioningState é Succeeded.
Qual é a causa raiz da inacessibilidade via SSH?
A) A expansão do disco OS causou um reboot forçado que corrompeu a configuração de rede interna da VM.
B) O SKU Standard bloqueia SSH por padrão e um NSG precisa ser associado diretamente à interface de rede, não apenas à subnet.
C) O Public IP Address existe como recurso, mas não está associado a nenhuma interface de rede ou recurso ativo, resultando em campo ipAddress nulo.
D) O provisioningState Succeeded indica que o IP foi desprovisionado com sucesso e precisa ser recriado.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte relato: "Criamos um novo Public IP Address Standard e tentamos associá-lo a uma VM existente, mas a VM continua sem responder externamente."
Os passos de investigação disponíveis são:
- Passo P: Verificar se o IP público está de fato associado à interface de rede correta da VM via
az network nic ip-config show - Passo Q: Confirmar se existe um NSG associado à interface de rede ou subnet que permite o tráfego desejado
- Passo R: Verificar o campo
ipAddressdo recurso Public IP para confirmar se um endereço foi atribuído - Passo S: Testar conectividade externa para o IP atribuído a partir de uma origem fora da rede Azure
- Passo T: Confirmar se a VM está no estado Running e sem alertas de integridade no portal
Qual sequência de diagnóstico segue a lógica correta de progressão, do plano de controle para o plano de dados?
A) T -> P -> R -> Q -> S B) S -> R -> P -> Q -> T C) R -> T -> S -> P -> Q D) Q -> P -> T -> R -> S
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista definitiva está na saída do comando: o IP está configurado com Method: Dynamic e Sku: Basic. Com atribuição Dinâmica, o Azure libera o endereço IP quando a VM é desalocada e atribui um novo ao ser reiniciada. O DNS externo ainda apontava para o endereço anterior 20.85.110.67, enquanto o IP atual passou a ser 20.85.110.44.
A informação sobre o storage account com redundância LRS é propositalmente irrelevante e não tem relação alguma com o comportamento de endereçamento IP público.
O distrator A é perigoso porque NSG alterado é uma hipótese razoável em falhas pós-manutenção, mas o enunciado afirma explicitamente que o NSG não foi alterado. O distrator C é plausível para quem não conhece o comportamento de desalocação, mas a interface de rede não é recriada em migrações de host. O distrator D é falso: o SKU Basic não tem restrição de recriação após migração de hardware.
Agir com base no distrator A levaria o administrador a modificar regras de NSG que estão corretas, perdendo tempo e potencialmente abrindo brechas de segurança desnecessárias.
Gabarito — Cenário 2
Resposta: C
A restrição crítica do cenário é que o ambiente está em produção ativa e não há janela de manutenção nas próximas 6 horas. A substituição do IP em produção sem janela implica interrupção de serviço, pois o endereço IP mudará e o DNS externo tem TTL de 3600 segundos, o que significa até 1 hora de indisponibilidade para clientes com o registro em cache.
O distrator A é o mais perigoso: não existe atualização de SKU in-place para Public IP Addresses no Azure. A operação é impossível tecnicamente e levaria o administrador a perder tempo tentando algo que o portal simplesmente não permite.
O distrator B representa a ação correta no momento tecnicamente adequado (janela de manutenção), mas ignora a restrição de produção ativa declarada no enunciado. O distrator D é inviável porque não é possível criar um novo IP com um endereço específico: o Azure atribui endereços do seu pool e não permite reservar um IP previamente usado por outro recurso.
A ação correta preserva a estabilidade do ambiente produtivo e planeja a resolução com controle de impacto.
Gabarito — Cenário 3
Resposta: C
A pista central está no campo Ip: None na saída do comando. Um Public IP Address com SKU Standard pode existir como recurso válido (provisioningState Succeeded) sem estar associado a nenhuma interface de rede. Quando não associado, nenhum endereço IP é atribuído ao campo ipAddress, tornando o recurso inutilizável para comunicação externa.
A informação sobre a expansão do disco OS é propositalmente irrelevante. Expansão de disco não afeta configuração de rede e não causa reboot forçado em VMs no Azure.
O distrator B contém um elemento verdadeiro (SKU Standard é secure by default e requer NSG), mas não é a causa raiz aqui: o problema é anterior, o IP nem está associado à VM. O distrator D representa uma leitura equivocada do campo provisioningState: Succeeded significa que o recurso foi criado com sucesso, não que foi removido. O distrator A atribuiria a causa a um evento irrelevante incluído propositalmente no enunciado.
O principal erro de raciocínio dos distratores é focar nos eventos recentes (expansão de disco, comportamento do NSG) em vez de verificar o estado atual da associação do recurso de IP.
Gabarito — Cenário 4
Resposta: A
A sequência correta é T -> P -> R -> Q -> S, que segue a progressão do plano de controle para o plano de dados:
| Ordem | Passo | Lógica |
|---|---|---|
| 1 | T | Confirmar que a VM está operacional antes de investigar rede |
| 2 | P | Verificar se a associação entre IP e NIC foi feita corretamente |
| 3 | R | Confirmar se o IP público tem um endereço atribuído |
| 4 | Q | Verificar se NSG permite o tráfego desejado |
| 5 | S | Testar conectividade real apenas após validar todos os pré-requisitos |
Começar pelo teste de conectividade externo (Passo S), como propõe o distrator B, é o erro mais comum: testar antes de validar a configuração gera resultados negativos que não indicam onde está o problema.
O distrator D começa pela verificação do NSG (Q), o que é prematuro: se o IP não está associado à NIC, o NSG é irrelevante para o diagnóstico imediato. A sequência correta garante que cada verificação só faça sentido após a anterior confirmar o estado esperado.
Árvore de Troubleshooting: Configure Public IP Addresses
Legenda:
- Azul escuro: sintoma inicial, ponto de entrada na arvore
- Azul: pergunta de diagnostico, respondida com sim ou nao
- Vermelho: causa identificada e acao corretiva associada
- Verde: validacao ou resolucao confirmada
Para usar esta arvore diante de um problema real, comece sempre pelo nó raiz e responda cada pergunta com base no que é observável diretamente: estado da VM, saída de comandos az network, registros DNS e testes de conectividade. Percorra as ramificações sem pular etapas. Cada nó vermelho indica tanto a causa quanto a ação corretiva, garantindo que o diagnóstico e a resolução caminhem juntos.