Laboratório Técnico: Implement a load balancing rule
Questões
Questão 1 — Múltipla Escolha
Um engenheiro configura um Azure Load Balancer público para distribuir tráfego HTTP entre três máquinas virtuais. Após a implantação, ele percebe que todas as requisições de um mesmo cliente sempre chegam à mesma VM, mesmo com múltiplas sessões abertas em momentos distintos.
Qual configuração da regra de balanceamento é responsável por esse comportamento?
A) O protocolo da regra está definido como TCP em vez de HTTP
B) A opção Session persistence está definida como Client IP
C) O Floating IP está habilitado na regra de balanceamento
D) O Idle timeout está configurado com valor abaixo do padrão
Questão 2 — Cenário Técnico
Um arquiteto precisa publicar um serviço interno que roda na porta 8080 em três VMs, mas deseja que os clientes acessem o serviço pela porta 80. O Load Balancer é do tipo interno (ILB).
Qual é a configuração correta a ser aplicada na regra de balanceamento?
Frontend IP: 10.0.1.10
Frontend port: ?
Backend port: ?
Protocol: TCP
A) Frontend port: 80 / Backend port: 80, pois as portas devem ser idênticas em regras TCP
B) Frontend port: 8080 / Backend port: 80, mapeando a porta de origem para a de destino
C) Frontend port: 80 / Backend port: 8080, permitindo que o Load Balancer traduza a porta entre frontend e backend
D) Frontend port: 80 / Backend port: 0, pois a porta zero instrui o Load Balancer a preservar a porta original do cliente
Questão 3 — Verdadeiro ou Falso
Uma regra de balanceamento do Azure Load Balancer (SKU Standard) pode ser criada sem que um health probe esteja associado a ela. Nesse caso, o Load Balancer distribui o tráfego entre todas as instâncias do backend pool independentemente de seu estado de saúde.
Questão 4 — Cenário Técnico
Um time de operações mantém um cluster de servidores que processam transações financeiras. Eles utilizam um Azure Load Balancer Standard com a seguinte regra configurada:
Protocol: TCP
Frontend port: 443
Backend port: 443
Session persistence: None
Floating IP: Enabled
Ao inspecionar os logs nas VMs, o time observa que o endereço IP de destino dos pacotes recebidos é o IP do frontend do Load Balancer, e não o IP privado da própria VM. Esse comportamento está causando falhas na aplicação, que espera receber pacotes endereçados ao seu próprio IP.
Qual é a causa raiz do problema?
A) O protocolo TCP não é compatível com o SKU Standard para tráfego na porta 443
B) A opção Floating IP está habilitada, fazendo com que o Load Balancer não realize DNAT e entregue o pacote com o IP de destino original do frontend
C) A ausência de Session persistence impede que o Load Balancer reescreva o cabeçalho IP corretamente
D) O backend pool não possui um Network Security Group permitindo tráfego na porta 443, causando reescrita incorreta do endereço
Questão 5 — Múltipla Escolha
Ao configurar uma regra de balanceamento em um Azure Load Balancer Standard público, qual é o efeito de habilitar a opção "HA Ports"?
A) A regra passa a balancear todos os protocolos e todas as portas simultaneamente, substituindo a necessidade de regras individuais por porta; esse recurso está disponível apenas em Load Balancers internos
B) A regra habilita balanceamento de alta disponibilidade exclusivamente para tráfego UDP em todas as portas, mantendo TCP com regras individuais
C) A regra replica automaticamente a configuração para todas as regiões do Azure onde o Load Balancer possui backends registrados
D) A regra passa a aceitar conexões em qualquer porta do frontend, mas ainda exige que o backend esteja configurado com portas individuais correspondentes
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
A opção Session persistence (também chamada de sticky sessions ou source affinity) controla como o Load Balancer distribui requisições de um mesmo cliente. Quando configurada como Client IP, o algoritmo garante que todas as requisições originadas do mesmo endereço IP sejam sempre encaminhadas para a mesma instância de backend, independentemente de se tratar de sessões novas ou distintas.
O principal equívoco representado pelos distratores é confundir comportamento de persistência com configurações de protocolo ou timeout. O protocolo TCP (alternativa A) não tem relação com afinidade de sessão. O Floating IP (alternativa C) altera o comportamento de DNAT, não o roteamento por cliente. O Idle timeout (alternativa D) controla apenas o encerramento de conexões ociosas.
Escolher um distrator aqui levaria o engenheiro a modificar parâmetros irrelevantes sem resolver o comportamento observado.
Gabarito — Questão 2
Resposta: C
O Azure Load Balancer suporta mapeamento assimétrico de portas entre frontend e backend. Isso permite que o frontend exponha uma porta diferente da que os servidores de backend realmente escutam. No cenário descrito, o cliente acessa a porta 80, e o Load Balancer traduz e encaminha o tráfego para a porta 8080 nas VMs.
A alternativa A está errada porque as portas não precisam ser idênticas. A alternativa B inverte a lógica do mapeamento (cliente acessa 8080, backend recebe 80, o que não corresponde ao requisito). A alternativa D é inválida: a porta 0 não é um valor aceito em regras de balanceamento padrão para esse fim.
Esse recurso é frequentemente subutilizado, mas é essencial para cenários onde a aplicação não pode ou não deve escutar em portas privilegiadas.
Gabarito — Questão 3
Falso
No Azure Load Balancer SKU Standard, um health probe é obrigatório para que uma regra de balanceamento funcione corretamente. Sem um probe associado, o Load Balancer considera todas as instâncias do backend pool como indisponíveis e não encaminha tráfego algum.
Esse comportamento difere do SKU Basic, que em alguns cenários permite operação sem probe com comportamento menos restritivo. A afirmação da questão descreve um comportamento que não ocorre no SKU Standard, tornando-a falsa.
Compreender essa distinção é crítico em cenários de troubleshooting onde o tráfego simplesmente não chega ao backend após a criação de uma regra.
Gabarito — Questão 4
Resposta: B
O Floating IP (também conhecido como Direct Server Return em algumas documentações) altera fundamentalmente o comportamento de tradução de endereços do Load Balancer. Com essa opção habilitada, o Load Balancer não realiza DNAT no endereço IP de destino do pacote. O pacote chega à VM com o IP de destino sendo o IP do frontend do Load Balancer, e não o IP privado da interface de rede da VM.
Esse recurso é projetado para cenários específicos, como clusters SQL AlwaysOn e outros padrões que exigem que a aplicação processe o endereço de frontend diretamente. Aplicações que não foram desenvolvidas para esse modelo falharão ao receber pacotes endereçados a um IP que não reconhecem como seu.
As alternativas C e D introduzem causalidades incorretas: session persistence e NSGs não têm relação com a reescrita de endereços IP de destino.
Gabarito — Questão 5
Resposta: A
A funcionalidade HA Ports permite criar uma única regra de balanceamento que cobre todos os protocolos (TCP e UDP) e todas as portas simultaneamente, em vez de exigir uma regra separada por porta e protocolo. Esse recurso é especialmente útil para Network Virtual Appliances (NVAs) que precisam processar tráfego arbitrário.
A restrição crítica e frequentemente negligenciada é que HA Ports está disponível exclusivamente em Load Balancers internos (ILB). Um Load Balancer público não suporta essa configuração.
A alternativa B está errada porque HA Ports abrange TCP e UDP, não apenas UDP. A alternativa C descreve um comportamento de replicação geográfica que não existe nesse contexto. A alternativa D contradiz a natureza da funcionalidade, que elimina exatamente a necessidade de especificar portas individualmente no backend.