Laboratório Técnico: Identify appropriate use cases for Azure Load Balancer
Questões
Questão 1 — Múltipla Escolha
Uma equipe de infraestrutura precisa distribuir tráfego TCP na porta 1433 entre três instâncias de SQL Server hospedadas em máquinas virtuais dentro de uma mesma rede virtual. O requisito é que o balanceamento opere na camada de transporte e que as sessões de um mesmo cliente sejam sempre direcionadas para a mesma instância durante a conexão.
Qual combinação de recurso e configuração atende corretamente a esse requisito?
A) Azure Application Gateway com afinidade de sessão baseada em cookie
B) Azure Load Balancer interno com regra de balanceamento e Session Persistence configurada como "Client IP"
C) Azure Load Balancer público com regra de NAT de entrada e persistência desabilitada
D) Azure Traffic Manager com método de roteamento "Session" apontando para as VMs diretamente
Questão 2 — Cenário Técnico
Um engenheiro configurou um Azure Load Balancer público para distribuir tráfego HTTP entre duas VMs. As VMs estão no backend pool, as health probes estão configuradas na porta 80 e as regras de balanceamento estão ativas. No entanto, após o deploy, nenhuma requisição chega às VMs.
O engenheiro verifica o seguinte:
Health probe status: Degraded
Backend pool: 2 VMs associadas
Load balancing rule: porta 80 -> porta 80
Frontend IP: associado a um Public IP
Ao inspecionar as VMs, ele constata que o Network Security Group (NSG) associado à NIC de cada VM não possui nenhuma regra de entrada explícita.
Qual é a causa mais provável da falha?
A) O Load Balancer público requer que as VMs estejam em um Availability Set obrigatoriamente
B) A health probe não consegue alcançar as VMs porque o NSG bloqueia o tráfego de entrada, incluindo as sondas do Load Balancer
C) O frontend IP público não pode ser associado a um Load Balancer sem um Azure Firewall na frente
D) As regras de balanceamento exigem que a porta de frontend e a porta de backend sejam diferentes
Questão 3 — Verdadeiro ou Falso
O Azure Load Balancer Standard suporta regras de balanceamento de carga para tráfego em todas as portas simultaneamente, utilizando um único objeto de regra com a opção HA Ports habilitada, sendo esse recurso disponível tanto no SKU interno quanto no SKU público.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
Uma empresa financeira opera um conjunto de microserviços em VMs distribuídas em duas regiões do Azure: East US e West Europe. O requisito de negócio exige que, em caso de falha completa de uma região, o tráfego seja redirecionado automaticamente para a região saudável. A latência entre as regiões é aceitável para o failover.
O arquiteto propõe usar exclusivamente Azure Load Balancer para resolver esse requisito.
Qual é o problema com essa abordagem?
A) O Azure Load Balancer Standard não suporta backends com IPs públicos em outras regiões
B) O Azure Load Balancer opera dentro de uma única região e não possui mecanismo nativo de roteamento ou failover entre regiões
C) O Azure Load Balancer exige que todas as VMs estejam na mesma rede virtual, o que impossibilita o uso entre regiões
D) O Azure Load Balancer não suporta protocolos TCP em cenários de alta disponibilidade com múltiplos backends
Questão 5 — Múltipla Escolha
Uma solução de streaming de vídeo utiliza o protocolo UDP para transmissão de pacotes em tempo real. A equipe precisa balancear esse tráfego entre um conjunto de servidores de mídia em uma rede virtual do Azure, sem inspecionar o conteúdo das requisições.
Qual serviço do Azure é o mais adequado para esse cenário?
A) Azure Application Gateway, pois oferece suporte nativo a protocolos de mídia
B) Azure Load Balancer, pois opera na camada 4 e suporta balanceamento de tráfego UDP
C) Azure Front Door, pois é otimizado para streaming global com baixa latência
D) Azure API Management, pois permite roteamento de tráfego com base em políticas customizadas
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O Azure Load Balancer opera exclusivamente na camada 4 (transporte), o que o torna adequado para tráfego TCP em qualquer porta, incluindo a 1433. A configuração de Session Persistence com o modo "Client IP" garante que requisições originadas do mesmo endereço IP de origem sejam sempre encaminhadas para o mesmo backend, atendendo ao requisito de afinidade de sessão.
O principal equívoco representado pelos distratores é confundir camada de atuação: o Application Gateway (A) opera na camada 7 e usa cookies HTTP para afinidade, o que não se aplica a tráfego TCP puro como o do SQL Server. O Traffic Manager (D) é um serviço de DNS e não possui visibilidade de sessão nem conectividade direta com VMs. A opção C ignora o requisito de persistência de sessão.
Escolher o Application Gateway nesse cenário geraria overhead desnecessário e potencialmente incompatibilidade com o protocolo TDS usado pelo SQL Server.
Gabarito — Questão 2
Resposta: B
As health probes do Azure Load Balancer são originadas de um endereço IP reservado da infraestrutura do Azure (168.63.129.16). Quando um NSG está associado à NIC da VM e não possui regra de entrada explícita permitindo esse tráfego, as sondas são bloqueadas. Como resultado, o Load Balancer marca os backends como não saudáveis e para de encaminhar tráfego para eles.
O erro conceitual representado pelos demais distratores é atribuir a falha a restrições estruturais inexistentes: Availability Sets (A) não são obrigatórios para o Load Balancer público; Azure Firewall (C) não é pré-requisito para associação de IP público; e a correspondência de portas frontend/backend (D) é opcional, não obrigatória.
A consequência prática de não compreender esse comportamento é implantar soluções aparentemente corretas que falham silenciosamente por bloqueio de NSG, o que é uma das causas mais comuns de diagnóstico incorreto em ambientes Azure.
Gabarito — Questão 3
Resposta: Falso
O recurso de HA Ports está disponível apenas no Azure Load Balancer Standard na modalidade interna (Internal Load Balancer). Ele não é suportado no Load Balancer público. Essa restrição existe porque HA Ports foi projetado para cenários de appliances de rede virtual (NVAs) em topologias hub-and-spoke, onde o balanceador interno precisa inspecionar e distribuir tráfego de qualquer protocolo e porta sem configurar regras individuais.
Assumir que HA Ports funciona no SKU público leva a erros de design em arquiteturas de segurança de rede, especialmente quando se tenta expor um conjunto de firewalls ou NVAs diretamente para a internet usando essa abordagem.
Gabarito — Questão 4
Resposta: B
O Azure Load Balancer é um recurso regional. Ele distribui tráfego entre backends dentro de uma mesma região e não possui capacidade de roteamento geográfico, detecção de falha regional ou redirecionamento de tráfego entre regiões. Para esse requisito, o serviço correto é o Azure Traffic Manager (baseado em DNS) ou o Azure Front Door (baseado em anycast global com failover de camada 7).
Os demais distratores introduzem restrições técnicas incorretas: o Load Balancer Standard suporta backends com IPs públicos via funcionalidade de backend pool baseado em IP (A é parcialmente impreciso no contexto); VMs em redes virtuais distintas podem ser adicionadas ao backend pool via peering ou IP direto (C é incorreto); e o suporte a TCP em cenários de alta disponibilidade é exatamente um dos pontos fortes do Load Balancer (D é incorreto).
Usar exclusivamente o Load Balancer para failover entre regiões resultaria em indisponibilidade total durante uma falha regional, sem qualquer mecanismo automático de recuperação.
Gabarito — Questão 5
Resposta: B
O Azure Load Balancer opera na camada 4 do modelo OSI e suporta os protocolos TCP e UDP, sem inspecionar o conteúdo das requisições. Isso o torna diretamente adequado para balancear tráfego UDP de streaming de vídeo entre servidores de mídia em uma rede virtual.
O equívoco central nos demais distratores é aplicar serviços de camada 7 a um problema de camada 4: o Application Gateway (A) não suporta UDP; o Front Door (C) também opera na camada 7 com foco em HTTP/HTTPS e não é projetado para tráfego UDP de streaming interno; o API Management (D) é voltado para APIs REST/SOAP e não tem capacidade de roteamento de tráfego UDP.
Escolher um serviço de camada 7 para tráfego UDP resultaria em falha completa de conectividade, pois esses serviços simplesmente não processam esse tipo de protocolo.