Pular para o conteúdo principal

Laboratório Técnico: Map requirements to features and capabilities of Azure Load Balancer

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe de arquitetura precisa distribuir tráfego TCP de entrada na porta 443 para um conjunto de máquinas virtuais em uma sub-rede privada. O requisito é que nenhum endereço IP público seja exposto nas VMs e que o balanceador opere na camada 4. Além disso, o tráfego de origem é exclusivamente interno à rede virtual.

Qual SKU e tipo de Azure Load Balancer atendem corretamente a esse cenário?

A. SKU Basic, tipo público
B. SKU Standard, tipo público
C. SKU Standard, tipo interno
D. SKU Basic, tipo interno

Questão 2 — Cenário Técnico​

Um engenheiro configurou um Azure Load Balancer Standard público com o seguinte backend pool e health probe:

Health Probe:
  Protocol: TCP
  Port: 80
  Interval: 5s
  Unhealthy threshold: 2

Backend Pool:
  VM-A: respondendo na porta 80
  VM-B: firewall local bloqueando a porta 80
  VM-C: respondendo na porta 80

Após alguns minutos, os usuários relatam que aproximadamente um terço das requisições falha com timeout. O engenheiro verifica que o load balancer está ativo e as VMs estão ligadas.

Qual é a causa mais provável do problema?

A. O intervalo do health probe está muito curto, causando falsos negativos em todas as VMs
B. VM-B não está respondendo ao health probe e continua recebendo tráfego por falha na remoção do backend
C. VM-B está sendo excluída corretamente do pool, mas o algoritmo hash redistribui o tráfego de forma desproporcional
D. O SKU Standard exige que o health probe use HTTP em vez de TCP para detectar falhas corretamente

Questão 3 — Verdadeiro ou Falso​

Um Azure Load Balancer Standard interno, sem nenhuma regra de saída configurada, garante automaticamente conectividade de saída à internet para as VMs no backend pool, da mesma forma que o SKU Basic faz por padrão.

Questão 4 — Cenário Técnico​

Uma aplicação financeira exige que todas as conexões de um mesmo cliente sejam sempre processadas pela mesma instância de backend durante a sessão, pois o estado da transação é mantido localmente na VM. O ambiente usa Azure Load Balancer Standard público.

O engenheiro configura a regra de balanceamento da seguinte forma:

Load Balancing Rule:
  Frontend IP: pip-finance-prod
  Protocol: TCP
  Port: 443
  Backend Port: 443
  Session Persistence: None
  Idle Timeout: 4 min

Após a implantação, usuários relatam perda de sessão intermitente.

Qual alteração resolve o problema com a menor mudança de configuração?

A. Aumentar o Idle Timeout para 30 minutos
B. Alterar Session Persistence para "Client IP"
C. Alterar Session Persistence para "Client IP and Protocol"
D. Substituir o Load Balancer por um Application Gateway com afinidade de sessão baseada em cookie

Questão 5 — Múltipla Escolha​

Uma organização precisa que o Azure Load Balancer encaminhe tráfego de entrada diretamente para a interface de rede de cada VM individualmente, em vez de usar um endereço IP virtual compartilhado no frontend. O objetivo é preservar o IP de destino original do pacote para que a aplicação o inspecione.

Qual recurso do Azure Load Balancer permite esse comportamento?

A. Outbound Rules
B. Floating IP (Direct Server Return)
C. High Availability Ports
D. Inbound NAT Rules

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: C

Um Load Balancer interno (ILB) não expõe endereço IP público e distribui tráfego dentro da rede virtual ou de redes conectadas via peering ou VPN. O SKU Standard é obrigatório quando há requisitos de produção com SLA, suporte a zonas de disponibilidade e integração com outros recursos como NAT Gateway. O SKU Basic não oferece SLA formal e tem limitações de escala e segurança. O tipo público seria inadequado porque exigiria um IP público no frontend, contrariando o requisito. A combinação Basic interno seria funcionalmente possível em cenários simples, mas não é a escolha correta para ambientes que exigem robustez e está sendo descontinuada pela Microsoft.

Gabarito — Questão 2​

Resposta: B

O health probe TCP na porta 80 verifica periodicamente se cada VM responde. VM-B tem o firewall local bloqueando essa porta, então o probe falha para ela. Quando o número de falhas consecutivas atinge o unhealthy threshold (2 neste caso), o Load Balancer remove VM-B do pool ativo e para de enviar tráfego a ela.

O erro conceitual dos distratores está em supor que o Load Balancer ignora o resultado do probe ou que o protocolo TCP é insuficiente. Na configuração descrita, o intervalo de 5 segundos com threshold de 2 é perfeitamente funcional. A alternativa C descreve um comportamento que não existe: após a remoção de VM-B, o tráfego é redistribuído igualmente entre VM-A e VM-C. A alternativa D é falsa: o SKU Standard suporta health probes TCP normalmente.

O sintoma de "um terço das requisições falha" indica que VM-B ainda recebia tráfego antes de ser marcada como não saudável, durante a janela entre as verificações. Uma vez removida, as falhas cessam.

Gabarito — Questão 3​

Resposta: Falso

Este é um ponto de ruptura importante entre os SKUs. O SKU Basic fornece conectividade de saída padrão (default outbound access) para VMs em seu backend pool, sem configuração explícita. O SKU Standard não fornece esse comportamento: VMs em um Load Balancer Standard interno ou sem regras de saída configuradas não têm conectividade de saída garantida pelo balanceador.

Para garantir saída à internet com SKU Standard, é necessário configurar explicitamente Outbound Rules no Load Balancer público, associar um NAT Gateway à sub-rede, ou atribuir um IP público individual à NIC da VM. Assumir que o comportamento do Basic se aplica ao Standard é um erro operacional que pode causar falhas silenciosas de conectividade em produção.

Gabarito — Questão 4​

Resposta: B

A configuração com Session Persistence: None usa o algoritmo de hash de 5 tuplas (IP de origem, porta de origem, IP de destino, porta de destino, protocolo). Como a porta de origem muda a cada nova conexão TCP, o mesmo cliente pode ser direcionado a VMs diferentes em reconexões, quebrando o estado local da sessão.

Alterar para "Client IP" instrui o Load Balancer a usar hash de 2 tuplas (IP de origem e IP de destino), garantindo que todas as conexões do mesmo IP de cliente sejam sempre encaminhadas à mesma VM.

A alternativa C ("Client IP and Protocol") usa 3 tuplas e seria adequada se o cliente usasse múltiplos protocolos, o que não é o caso aqui. Aumentar o Idle Timeout (A) não resolve o problema de afinidade em novas conexões. Substituir por Application Gateway (D) resolveria o problema, mas representa uma mudança arquitetural desproporcional quando a solução está disponível no próprio Load Balancer.

Gabarito — Questão 5​

Resposta: B

O Floating IP, também conhecido como Direct Server Return (DSR), altera o comportamento padrão do Load Balancer ao preservar o IP de destino do frontend no pacote entregue à VM. Sem Floating IP, o Load Balancer realiza DNAT e substitui o IP de destino pelo IP da VM antes da entrega. Com Floating IP habilitado, o pacote chega à NIC da VM com o IP virtual do frontend como destino, permitindo que a aplicação inspecione o endereço original.

Outbound Rules (A) controlam apenas o tráfego de saída. High Availability Ports (C) habilitam balanceamento de todos os protocolos e portas em um único Load Balancer interno, sem relação com a preservação do IP de destino. Inbound NAT Rules (D) mapeiam portas específicas do frontend para instâncias individuais, mas também realizam DNAT sem preservar o IP original.