Laboratório Técnico: Troubleshoot Load Balancing
Questões
Questão 1 — Múltipla Escolha
Um administrador configurou um Azure Load Balancer público com uma regra de balanceamento na porta 80 apontando para um backend pool com três VMs. Após a implantação, nenhuma das VMs recebe tráfego externo, embora todas estejam em execução e com o serviço web ativo.
Qual componente ausente ou mal configurado é a causa mais provável?
A) A SKU do Load Balancer é Standard, mas as VMs usam endereços IP públicos Basic
B) Não existe uma health probe configurada ou ela está falhando em todas as instâncias do backend pool
C) O backend pool está associado a uma subnet diferente da subnet do Load Balancer
D) O Load Balancer não possui uma regra de NAT de entrada configurada para a porta 80
Questão 2 — Cenário Técnico
Uma equipe configurou um Azure Application Gateway com dois backend pools: pool-api e pool-web. O listener está configurado para roteamento baseado em caminho com as seguintes regras:
/api/* → pool-api
/static/* → pool-web
Durante os testes, requisições para /api/users retornam HTTP 502. Requisições para /static/logo.png funcionam normalmente. Os servidores no pool-api estão em execução e respondem corretamente quando acessados diretamente pelo IP privado na porta 80.
Qual é a causa mais provável do erro 502?
A) O listener do Application Gateway está configurado com o protocolo HTTPS, mas o backend pool usa HTTP
B) A health probe personalizada do pool-api aponta para um caminho inexistente no servidor, fazendo com que o Application Gateway remova todas as instâncias do pool
C) O NSG associado à subnet do Application Gateway está bloqueando o tráfego de saída para o pool-api
D) O roteamento baseado em caminho não suporta o caractere curinga * em regras de URL
Questão 3 — Verdadeiro ou Falso
Um Azure Load Balancer interno com SKU Standard, ao detectar que todas as instâncias do backend pool estão com a health probe falhando, passa a distribuir o tráfego igualmente entre todas as instâncias do pool, independentemente do status da probe, para evitar interrupção total do serviço.
Essa afirmação é verdadeira ou falsa?
Questão 4 — Cenário Técnico
Um administrador está investigando por que uma VM específica de um backend pool nunca recebe conexões, mesmo com a health probe retornando sucesso para ela. A configuração do Load Balancer é a seguinte:
SKU: Standard
Regra de balanceamento:
- Protocolo: TCP
- Porta frontend: 443
- Porta backend: 443
- Session persistence: Client IP and protocol
- Idle timeout: 30 min
O tráfego de teste é gerado por um único cliente com IP fixo realizando chamadas repetidas. As outras duas VMs do pool recebem conexões normalmente.
Qual é a explicação mais provável para a VM nunca receber tráfego?
A) A VM está em uma Availability Zone diferente das demais, e o Load Balancer não tem redundância de zona habilitada
B) A VM foi adicionada ao backend pool após as sessões dos clientes já terem sido estabelecidas, e o hash de sessão fixou o tráfego nas demais instâncias
C) O algoritmo de session persistence baseado em IP de cliente cria um hash que consistentemente mapeia aquele IP para as outras instâncias, excluindo essa VM do fluxo desse cliente
D) A regra de balanceamento com idle timeout de 30 minutos impede a redistribuição de conexões ativas para novas instâncias
Questão 5 — Múltipla Escolha
Um administrador precisa expor três aplicações distintas via HTTPS na mesma porta 443 e no mesmo endereço IP público, roteando o tráfego com base no hostname da requisição (app1.contoso.com, app2.contoso.com, app3.contoso.com). Cada aplicação tem seu próprio conjunto de servidores backend.
Qual serviço do Azure atende esse requisito de forma nativa?
A) Azure Load Balancer Standard com três regras de balanceamento distintas, uma por hostname
B) Azure Traffic Manager com perfil de roteamento por prioridade configurado para cada hostname
C) Azure Application Gateway com listeners de múltiplos sites e regras de roteamento por hostname
D) Azure Load Balancer Standard com Network Address Translation (NAT) rules configuradas por hostname
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
A health probe é o mecanismo pelo qual o Load Balancer determina quais instâncias do backend pool estão aptas a receber tráfego. Se nenhuma health probe estiver configurada ou se ela estiver falhando em todas as instâncias, o Load Balancer remove todas do pool ativo e nenhuma requisição é encaminhada, mesmo com as VMs em execução.
O principal equívoco representado pelas alternativas incorretas é confundir conectividade de plano de dados com a lógica de distribuição do Load Balancer. A alternativa A é plausível em outros contextos, mas a incompatibilidade de SKU afeta a criação de recursos, não o tráfego em si após a implantação. A alternativa C está incorreta porque o Load Balancer opera na camada 4 e não exige colocação na mesma subnet do backend. A alternativa D confunde regras de balanceamento com regras de NAT de entrada, que têm finalidades distintas.
Gabarito — Questão 2
Resposta: B
O erro HTTP 502 no Application Gateway indica que o gateway não conseguiu obter uma resposta válida do backend. Quando a health probe aponta para um caminho que retorna status diferente de 2xx/3xx, o Application Gateway considera todas as instâncias do pool não saudáveis e rejeita as requisições com 502, mesmo que os servidores estejam funcionando corretamente em outros endpoints.
O fato de os servidores responderem diretamente pelo IP privado elimina problemas de rede básicos e torna B a causa mais provável. A alternativa A descreveria um problema de incompatibilidade de protocolo, que geralmente gera erro de handshake e não 502 limpo. A alternativa C seria improvável se outras regras do mesmo gateway funcionam normalmente, pois o NSG bloquearia todo o tráfego de saída da subnet. A alternativa D é falsa: o Application Gateway suporta curingas em caminhos de roteamento.
Gabarito — Questão 3
Resposta: Falso
O comportamento correto do Azure Load Balancer Standard quando todas as instâncias do backend pool falham na health probe é diferente conforme o tipo de probe: para probes TCP e HTTP, o Load Balancer realmente passa a enviar tráfego para todas as instâncias do pool como mecanismo de recuperação parcial. Porém, esse comportamento de "all-down" não equivale a uma operação normal e é documentado como um estado degradado, não como garantia de disponibilidade.
A afirmação é falsa porque descreve esse comportamento como uma decisão intencional de evitar interrupção total, quando na realidade ele representa um estado de falha generalizado com comportamento imprevisível. Além disso, a afirmação omite que esse comportamento se aplica apenas quando todas as instâncias falham simultaneamente, e não é equivalente ao funcionamento normal do balanceamento. Entender esse limite é crítico para dimensionar estratégias de alta disponibilidade.
Gabarito — Questão 4
Resposta: C
O session persistence baseado em "Client IP and protocol" usa um hash de cinco tuplas (ou duas, dependendo da configuração) para mapear de forma determinística um cliente a uma instância do backend pool. Se o hash resultante para aquele IP específico nunca aponta para a VM em questão, essa instância simplesmente não receberá tráfego desse cliente, independentemente do status da health probe ou do tempo de idle.
A alternativa B descreve um comportamento plausível em teoria, mas o session persistence opera com base no hash no momento da requisição, não no momento de adição da VM ao pool. A alternativa A poderia causar problemas de latência ou falha de zona, mas não excluiria permanentemente uma VM do recebimento de tráfego. A alternativa D está incorreta porque o idle timeout controla o encerramento de conexões inativas, não a distribuição de novas conexões.
Gabarito — Questão 5
Resposta: C
O Azure Application Gateway opera na camada 7 e suporta nativamente listeners de múltiplos sites, permitindo que um único endereço IP e porta 443 receba tráfego de diferentes hostnames e roteie cada um para seu respectivo backend pool com base no cabeçalho Host da requisição HTTP.
O Azure Load Balancer (alternativas A e D) opera na camada 4 e não tem visibilidade do hostname HTTP, sendo incapaz de rotear com base nesse critério. O Azure Traffic Manager (alternativa B) é um balanceador de tráfego DNS e opera fora do fluxo de dados, não sendo adequado para multiplexar hostnames no mesmo IP e porta. Escolher o Load Balancer nesse cenário resultaria na impossibilidade de distinguir as aplicações, exigindo IPs ou portas distintos para cada uma.