Laboratório de Troubleshooting: Choose an Appropriate Tier
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações relata que uma máquina virtual recém-criada não está recebendo tráfego externo, apesar de o Application Gateway estar respondendo normalmente para outras VMs no mesmo backend pool. O ambiente foi configurado há dois dias e funcionava corretamente até a migração do Load Balancer realizada ontem.
O engenheiro responsável coleta as seguintes informações:
Load Balancer SKU: Basic
VM adicionada ao backend pool: vm-prod-03
Availability Zone da VM: Zone 2
Regra de balanceamento: porta 80, protocolo TCP
NSG associado à NIC da vm-prod-03: permite HTTP inbound
Health probe: HTTP na porta 80 — status: Degraded
Durante a investigação, o engenheiro observa que as outras VMs no pool não estão em zonas de disponibilidade. A vm-prod-03 foi a única migrada para uma zona durante a atualização de ontem.
Qual é a causa raiz do problema observado?
A) O health probe está configurado com o protocolo errado; deveria ser TCP em vez de HTTP para o SKU Basic.
B) O Basic Load Balancer não suporta backends em Availability Zones, e por isso a vm-prod-03 não pode ser membro ativo do pool.
C) O NSG da NIC não está permitindo o tráfego do probe originado do endereço 168.63.129.16.
D) A regra de balanceamento está configurada para TCP, mas o health probe usa HTTP, o que cria conflito no Basic Load Balancer.
Cenário 2 — Decisão de Ação
A equipe identificou que um ExpressRoute circuit de 1 Gbps está sendo utilizado consistentemente acima de 90% da capacidade nos horários de pico, causando descarte de pacotes e degradação de aplicações críticas de ERP. O circuit é do tipo Provider-based e o provedor confirma disponibilidade de upgrade para 2 Gbps no mesmo peering location sem interrupção do BGP session.
O contexto operacional é:
Horário de pico: 08h00 às 18h00, dias úteis
Janela de manutenção aprovada: domingo 02h00 às 06h00
Dia atual: quinta-feira, 14h30
Aplicações críticas: em produção plena
SLA contratual: 99,95% de disponibilidade mensal
Aprovação do change já obtida para o upgrade de bandwidth
A causa do problema está identificada: o circuit está subdimensionado para a demanda atual.
Qual é a ação correta a tomar neste momento?
A) Iniciar o upgrade de bandwidth imediatamente junto ao provedor, pois a aprovação já foi obtida e o provedor confirmou que o BGP não será interrompido.
B) Aguardar a janela de manutenção aprovada no domingo para executar o upgrade, mesmo que o provedor possa fazê-lo sem interrupção.
C) Criar um segundo circuit ExpressRoute em paralelo e redistribuir a carga via BGP como solução de curto prazo até o domingo.
D) Reduzir o tráfego não crítico via QoS no gateway ExpressRoute para aliviar a saturação até a janela de manutenção.
Cenário 3 — Causa Raiz
Uma empresa opera um Virtual WAN do tipo Standard com dois hubs regionais: um em East US e outro em Brazil South. O time de segurança configurou recentemente o Routing Intent em ambos os hubs com Azure Firewall como next hop para tráfego privado e internet. Após a ativação, VMs no spoke conectado ao hub Brazil South perderam conectividade com um servidor on-premises conectado via VPN site-to-site ao hub East US.
O engenheiro coleta os dados abaixo:
Routing Intent: ativado em ambos os hubs
Azure Firewall Brazil South: provisionado, políticas ativas
Azure Firewall East US: provisionado, políticas ativas
Effective routes na VM (spoke Brazil South):
10.0.0.0/8 -> Next hop: Azure Firewall Brazil South
0.0.0.0/0 -> Next hop: Azure Firewall Brazil South
VPN Gateway East US: status Connected
BGP session com on-premises: Established
Spoke VNet Brazil South: peering com hub ativo
O time menciona que, na semana passada, uma nova política de tag de serviço foi adicionada ao Azure Firewall Brazil South bloqueando o prefixo 10.200.0.0/16, que é exatamente o range do servidor on-premises.
Qual é a causa raiz da perda de conectividade?
A) O Routing Intent está forçando o tráfego inter-hub pelo Azure Firewall, e a política do firewall em Brazil South está bloqueando o prefixo on-premises.
B) O BGP session entre o VPN Gateway e o servidor on-premises foi interrompido pela ativação do Routing Intent, que altera as rotas anunciadas pelo hub.
C) O peering entre o spoke VNet e o hub Brazil South foi invalidado pela ativação do Routing Intent, impedindo que as rotas on-premises sejam propagadas.
D) O Azure Firewall East US não tem uma regra de rede permitindo tráfego originado do range do spoke Brazil South, bloqueando o fluxo no hub de destino.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o relato de que VMs em uma VNet spoke não conseguem resolver nomes de outros recursos privados no Azure após uma reorganização da topologia de DNS. O ambiente usa Azure Private DNS Zone sem servidores DNS customizados.
Os seguintes passos de investigação estão disponíveis, fora de ordem:
Passo P: Verificar se a Private DNS Zone possui registros A para os recursos alvo
Passo Q: Confirmar se a VNet spoke possui um Virtual Network Link de resolucao com a Private DNS Zone
Passo R: Testar resolucao de DNS com nslookup a partir de uma VM no spoke
Passo S: Verificar se o servidor DNS configurado na VNet spoke aponta para 168.63.129.16
Passo T: Checar se ha sobreposicao de namespace entre a Private DNS Zone e uma zona publica de mesmo nome
Qual é a sequência correta de diagnóstico progressivo?
A) R -> S -> Q -> P -> T
B) S -> Q -> R -> P -> T
C) Q -> P -> S -> R -> T
D) P -> Q -> S -> T -> R
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista determinante no enunciado é que a vm-prod-03 foi colocada em uma Availability Zone durante a migração de ontem, enquanto as demais VMs não estão em zonas. O Basic Load Balancer não suporta backends que utilizam Availability Zones. Esse é um requisito estrutural do produto: qualquer backend em zona exige o SKU Standard.
A informação sobre o NSG permitindo HTTP é irrelevante para este diagnóstico e foi incluída propositalmente para desviar a atenção. O health probe em estado Degraded é consequência do problema, não a causa.
O distrator C é o mais perigoso: o endereço 168.63.129.16 é de fato a origem dos probes do Azure e um NSG mal configurado pode bloquear probes, mas o enunciado afirma explicitamente que o NSG permite HTTP inbound. O distrator A representa um equívoco sobre compatibilidade de protocolos entre probe e regra, o que não é uma limitação real do Basic Load Balancer. O distrator D mistura dois fatos verdadeiros de forma incorreta para criar uma causa falsa.
Agir com base no distrator C levaria o engenheiro a modificar o NSG sem resolver o problema real, potencialmente abrindo brechas de segurança desnecessárias.
Gabarito — Cenário 2
Resposta: B
A causa está identificada e a solução técnica está aprovada. O ponto crítico do cenário é a restrição de processo: existe uma janela de manutenção aprovada para domingo. Mesmo que o provedor confirme que o upgrade pode ser feito sem interrupção do BGP, executar uma mudança de infraestrutura crítica fora da janela aprovada viola o processo de gestão de mudanças e expõe a empresa a riscos de SLA e responsabilização.
O distrator A é o mais perigoso: a lógica técnica está correta, mas ignora completamente a restrição de processo. Em ambientes com SLA contratual e change management formal, a aprovação do change está vinculada à janela de manutenção, não apenas à natureza da mudança. O distrator C introduz complexidade operacional desnecessária e risco adicional sem ganho real. O distrator D é uma mitigação válida de curto prazo, mas o enunciado não pede mitigação, pede a ação correta dado o contexto completo.
Aguardar a janela é a decisão tecnicamente responsável e processualmente correta.
Gabarito — Cenário 3
Resposta: A
As effective routes confirmam que o tráfego da VM com destino a qualquer prefixo privado (10.0.0.0/8) está sendo encaminhado para o Azure Firewall Brazil South. O Routing Intent, quando ativado para tráfego privado, força todo o fluxo inter-hub e on-premises a passar pelo firewall do hub de origem antes de ser roteado. A política recém-adicionada bloqueia explicitamente o prefixo 10.200.0.0/16, que é exatamente o range do servidor on-premises. A combinação dessas duas condições é a causa raiz.
A informação sobre o BGP session estar Established é irrelevante e foi incluída propositalmente. O fato de o BGP estar ativo confirma que o problema não é de conectividade de controle, mas de filtragem no plano de dados pelo firewall.
O distrator B é o mais plausível superficialmente: o Routing Intent de fato altera rotas anunciadas, mas o BGP Established no enunciado elimina essa hipótese. O distrator D aponta para o firewall correto em topologia (o fluxo passa pelo East US depois), mas o bloqueio acontece antes, no firewall de saída do spoke, não no de destino. O distrator C confunde o efeito do Routing Intent com invalidação de peering, o que não ocorre.
Gabarito — Cenário 4
Resposta: A
A sequência correta é R -> S -> Q -> P -> T.
O raciocínio diagnóstico progressivo parte sempre do sintoma observável e vai eliminando camadas:
R confirma o sintoma com precisão: o nslookup falha, e revela se é falha de resolução total ou parcial. S valida a camada de configuração mais básica: se o DNS da VNet não aponta para 168.63.129.16, nenhuma Private DNS Zone será consultada, independentemente de qualquer outro ajuste. Q verifica se o link de resolução entre a VNet spoke e a zona privada existe, que é o requisito de vinculação. P confirma se os registros existem na zona. T investiga a possibilidade de conflito de namespace, que é a causa menos comum e mais difícil de detectar, devendo ser verificada por último.
O distrator B inverte S e Q, o que pode parecer razoável, mas validar o link antes do servidor DNS é investigar a camada de vínculo antes de confirmar que o resolvedor correto está sendo usado. O distrator C começa pela camada de vínculo sem confirmar o sintoma nem o resolvedor. O distrator D começa pelos registros, que é a camada mais interna, sem validar as camadas externas que podem estar bloqueando antes.
Árvore de Troubleshooting: Choose an Appropriate Tier
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou por estado) |
| 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 identificando o serviço afetado e responda cada pergunta de diagnóstico com base no que pode ser observado ou medido diretamente no ambiente. Siga o caminho correspondente à resposta até atingir um nó vermelho de causa identificada, depois avance para o nó verde de ação recomendada. Nós laranja indicam que a investigação precisa de dados adicionais antes de concluir o diagnóstico.