Laboratório de Troubleshooting: Create a public IP address
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um engenheiro tenta associar um endereço IP público existente a um novo Azure Load Balancer que está sendo criado via portal do Azure. O Load Balancer é configurado como Standard e a região escolhida é East US. O grupo de recursos já contém outros recursos funcionando normalmente, incluindo duas VMs e uma Virtual Network.
Durante a associação, o portal exibe a seguinte mensagem de erro:
Cannot associate public IP address 'pip-lb-frontend' with this load balancer.
The resource is not compatible with the selected configuration.
O engenheiro verifica que o IP público existe, está na mesma região e não está associado a nenhum outro recurso no momento. Ele também confirma que o grupo de recursos tem permissões adequadas e que não há políticas de bloqueio ativas.
Qual é a causa raiz do erro observado?
A) O IP público está em um grupo de recursos diferente do Load Balancer, o que impede a associação direta
B) O IP público foi criado com SKU Basic, tornando-o incompatível com um Load Balancer de SKU Standard
C) O IP público não possui uma zona de disponibilidade configurada, o que é obrigatório para Load Balancers Standard
D) O Load Balancer Standard requer que o IP público esteja pré-associado a uma interface de rede antes de ser vinculado ao frontend
Cenário 2 — Sequência de Diagnóstico
Uma equipe recebe um chamado relatando que uma aplicação web hospedada em uma VM no Azure parou de responder a requisições externas. A VM está operacional, o serviço está ativo e os logs da aplicação não registram nenhum erro interno. A VM possui um IP público associado diretamente à sua interface de rede.
O engenheiro responsável precisa investigar se o problema está relacionado ao endereço IP público. Os seguintes passos de investigação estão disponíveis:
- Verificar se o IP público está associado à NIC correta da VM
- Tentar acessar a aplicação via IP privado a partir de outra VM na mesma VNet
- Confirmar se o IP público tem alocação Dinâmica e se o endereço mudou após uma reinicialização recente
- Verificar se o NSG associado à NIC ou à subnet bloqueia a porta da aplicação
- Consultar o endereço IP público atual atribuído ao recurso no portal
Qual sequência representa a ordem correta de investigação para diagnosticar progressivamente o problema, partindo do mais externo para o mais específico?
A) 1, 5, 3, 2, 4
B) 2, 4, 5, 3, 1
C) 5, 3, 1, 4, 2
D) 3, 1, 5, 4, 2
Cenário 3 — Causa Raiz
Durante a criação de um endereço IP público via CLI, um engenheiro executa o seguinte comando:
az network public-ip create \
--resource-group rg-networking \
--name pip-appgw-prod \
--sku Standard \
--allocation-method Dynamic \
--location brazilsouth
O comando retorna o seguinte erro:
(InvalidPublicIpAllocationMethod) Dynamic allocation method is not supported
for Standard SKU public IP.
Error Code: InvalidPublicIpAllocationMethod
O engenheiro observa que o mesmo comando funcionou sem erros há seis meses em outro ambiente. Ele verifica que o grupo de recursos existe, a região Brazil South está disponível para a assinatura e o nome do recurso segue as convenções aceitas pelo Azure.
Qual é a causa raiz do erro?
A) A região Brazil South não suporta endereços IP públicos de SKU Standard com nenhum método de alocação
B) O SKU Standard exige obrigatoriamente alocação Estática, e o comando especificou alocação Dinâmica, que é incompatível com esse SKU
C) O parâmetro --allocation-method Dynamic foi descontinuado na CLI e precisa ser substituído por --allocation-method Automatic
D) O comando funcionou há seis meses porque a assinatura tinha uma configuração de política diferente que permitia alocação Dinâmica para SKU Standard
Cenário 4 — Decisão de Ação
A causa foi identificada: um endereço IP público de SKU Basic está associado a um Application Gateway Standard_v2 em produção. O Application Gateway Standard_v2 exige SKU Standard para o IP público, e a incompatibilidade está causando falhas intermitentes no provisionamento de novas regras de roteamento. O ambiente atende usuários externos com SLA ativo e qualquer interrupção deve ser comunicada com 30 minutos de antecedência.
O time de operações confirma que não há outra janela de manutenção disponível nas próximas 4 horas e que o Application Gateway está respondendo normalmente no momento, mas novas regras não podem ser adicionadas. O IP público atual está registrado no DNS externo da empresa com TTL de 3600 segundos.
Qual é a ação correta a tomar neste momento?
A) Excluir imediatamente o IP público Basic e criar um novo IP Standard, pois o Application Gateway continuará respondendo durante a troca
B) Atualizar o SKU do IP público diretamente no portal de Basic para Standard, preservando o endereço IP e evitando impacto no DNS
C) Criar um novo IP público Standard, atualizar o registro DNS apontando para o novo endereço e planejar a desassociação do IP Basic para a próxima janela de manutenção, comunicando o impacto conforme o SLA
D) Adicionar o novo IP público Standard como endereço secundário no Application Gateway enquanto o Basic permanece ativo, realizando a migração sem downtime
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
Explique:
- O erro de incompatibilidade ocorre porque o Azure impõe que Load Balancers Standard sejam associados exclusivamente a endereços IP públicos de SKU Standard. Um IP público de SKU Basic não pode ser vinculado a um recurso que exige o nível Standard.
- A pista decisiva no enunciado é a confirmação de que o Load Balancer é Standard e que o IP existe e está desassociado. A ausência de zona configurada não é o problema: um IP Standard sem zona (non-zonal) é perfeitamente compatível com um Load Balancer Standard.
- A informação sobre as VMs e a Virtual Network no grupo de recursos é propositalmente irrelevante e não influencia a compatibilidade de SKU entre IP público e Load Balancer.
- A alternativa C representa o erro de diagnóstico mais perigoso: zonas de disponibilidade são opcionais para IPs Standard, e confundir "non-zonal" com "incompatível" levaria o engenheiro a criar um IP Standard com zona desnecessariamente, sem resolver o problema se o IP original continuasse sendo Basic.
- Agir com base no distrator A (grupo de recursos diferente) faria o engenheiro mover recursos desnecessariamente, perdendo tempo sem chegar à causa real.
Gabarito — Cenário 2
Resposta: C
Explique:
- A sequência correta parte do estado atual do IP público (passo 5), verifica se houve mudança de endereço por alocação Dinâmica após reinicialização (passo 3), confirma se o IP está associado à NIC correta (passo 1), verifica bloqueios de NSG na camada de rede (passo 4) e só então testa a conectividade interna para isolar se o problema é externo ou na aplicação (passo 2).
- A lógica diagnóstica correta parte do componente mais externo e mais provável de ter mudado (o endereço IP público com alocação Dinâmica) antes de avançar para camadas internas como NSG e conectividade privada.
- A alternativa B inverte completamente a ordem ao começar pelo teste interno, o que pode confirmar que a aplicação funciona internamente, mas não identifica o problema externo sem antes verificar o IP.
- A alternativa D começa pelo passo mais específico (mudança de IP) sem antes confirmar qual é o IP atual atribuído, o que dificulta a comparação.
- Começar pelo passo 2 (teste interno) antes de verificar o IP público seria um erro clássico de diagnóstico de dentro para fora, que pode gerar conclusões falsas sobre a saúde da aplicação quando o problema real está na camada de endereçamento externo.
Gabarito — Cenário 3
Resposta: B
Explique:
- O SKU Standard de endereços IP públicos no Azure suporta exclusivamente alocação Estática. Não existe combinação válida de SKU Standard com alocação Dinâmica. Essa é uma restrição da plataforma, não uma política de assinatura.
- A pista mais importante é a mensagem de erro explícita:
Dynamic allocation method is not supported for Standard SKU public IP. O enunciado descreve o sintoma com precisão técnica suficiente para identificar a causa sem ambiguidade. - A informação de que o mesmo comando funcionou seis meses antes é propositalmente irrelevante e visa induzir o leitor a buscar uma causa externa como política de assinatura (alternativa D). Na prática, se o comando funcionou anteriormente com essa combinação, o recurso criado era SKU Basic, não Standard, ou o parâmetro de SKU era diferente.
- A alternativa C é um distrator plausível porque descreve um comportamento real de depreciação de CLIs, mas não corresponde a nenhuma mudança real na interface da Azure CLI para esse parâmetro.
- Agir com base na alternativa D levaria o engenheiro a abrir chamados com a Microsoft ou investigar políticas inexistentes, desperdiçando tempo enquanto a correção real é simplesmente substituir
DynamicporStaticno comando.
Gabarito — Cenário 4
Resposta: C
Explique:
- A restrição crítica é o TTL de 3600 segundos no DNS externo. Qualquer troca de endereço IP exige que o novo registro DNS seja propagado antes que o endereço antigo seja removido. Excluir o IP atual sem respeitar o TTL causaria indisponibilidade real para usuários externos enquanto o DNS ainda aponta para o endereço antigo.
- A ação correta é criar o novo IP Standard, atualizar o DNS com antecedência suficiente para cobrir o TTL, e só então desassociar o IP Basic em uma janela planejada, com comunicação conforme o SLA.
- A alternativa B é o distrator mais perigoso porque descreve algo tecnicamente impossível: o SKU de um IP público não pode ser alterado após a criação. Um engenheiro que acreditar nisso irá ao portal, não encontrará a opção, e perderá tempo tentando uma ação inexistente.
- A alternativa A ignora o TTL do DNS e causaria downtime imediato, violando o SLA ativo.
- A alternativa D é tecnicamente inválida: um Application Gateway não aceita dois endereços IP públicos frontend simultâneos de SKUs diferentes como estratégia de migração transparente.
- O ponto central desta decisão é reconhecer que a restrição de DNS é o fator limitante, não a compatibilidade técnica do novo IP.
Árvore de Troubleshooting: Create a public IP address
Legenda:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta de diagnóstico |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado e siga as perguntas de diagnóstico respondendo sim ou não com base no que você consegue verificar diretamente no portal ou via CLI. Os nós laranja indicam etapas de coleta de informação antes de avançar para a próxima pergunta. Cada caminho termina em uma causa identificada (vermelho) seguida de uma ação específica (verde). Nunca pule diretamente para uma ação sem percorrer o caminho de perguntas, pois sintomas idênticos podem ter causas distintas dependendo da configuração do ambiente.