Laboratório Técnico: Create and Configure an Azure Load Balancer
Questões
Questão 1 — Múltipla Escolha
Uma equipe de plataforma precisa distribuir tráfego TCP na porta 443 entre instâncias de máquinas virtuais localizadas em diferentes zonas de disponibilidade dentro da mesma região. O requisito exige que a solução suporte endereço IP público e garanta resiliência zonal.
Qual SKU e tipo de frontend devem ser usados?
A. SKU Basic com frontend de IP público estático
B. SKU Standard com frontend de IP público configurado como zona-redundante
C. SKU Basic com frontend de IP público configurado como zona-redundante
D. SKU Standard com frontend de IP público dinâmico
Questão 2 — Cenário Técnico
Um engenheiro configurou um Azure Load Balancer Standard interno para distribuir tráfego entre três VMs em um backend pool. A health probe está configurada com protocolo TCP na porta 80. Após o deploy, os logs mostram que o tráfego não está chegando a nenhuma das VMs, embora todas estejam em execução e respondam na porta 80 localmente.
Frontend IP: 10.0.1.10 (internal)
Backend pool: VM1, VM2, VM3
Health probe: TCP / porta 80 / intervalo 5s / limiar 2 falhas
Load balancing rule: porta 80 -> porta 80, Session persistence: None
NSG na subnet das VMs: sem regra explícita de entrada para 10.0.1.10
Qual é a causa mais provável do problema?
A. O SKU Standard não suporta Load Balancer interno
B. O NSG na subnet das VMs está bloqueando o tráfego de probe e de dados proveniente do Load Balancer
C. O protocolo TCP não é suportado em health probes de Load Balancers internos
D. A ausência de Session persistence impede o roteamento correto do tráfego
Questão 3 — Verdadeiro ou Falso
Um Azure Load Balancer do SKU Standard, ao ser criado sem nenhuma regra de saída (outbound rule) configurada, fornece automaticamente conectividade de saída à internet para as VMs no backend pool, desde que essas VMs não possuam IP público individual.
Questão 4 — Cenário Técnico
Uma aplicação financeira requer que todas as requisições de um mesmo cliente sejam sempre direcionadas para a mesma instância de VM durante a sessão, para preservar estado local. O arquiteto configurou o Load Balancer com a seguinte regra:
Protocolo: TCP
Porta frontend: 443
Porta backend: 443
Session persistence: Client IP and protocol
Idle timeout: 4 minutos
Após três semanas em produção, usuários relatam perda de sessão esporádica em conexões longas. O código da aplicação não tem problemas identificados.
Qual ajuste na configuração do Load Balancer resolve o problema descrito?
A. Alterar Session persistence para None para distribuir a carga de forma mais uniforme
B. Aumentar o valor de Idle timeout além de 4 minutos para cobrir conexões mais longas
C. Substituir o Load Balancer por um Application Gateway, pois o Load Balancer não suporta persistência de sessão
D. Alterar o protocolo da health probe de TCP para HTTP para detectar falhas de sessão
Questão 5 — Múltipla Escolha
Um Load Balancer Standard público possui uma regra de balanceamento de carga configurada com Floating IP habilitado. Um desenvolvedor precisa entender como o tráfego chega às VMs do backend pool com essa configuração ativa.
O que diferencia o comportamento do Floating IP em relação ao comportamento padrão?
A. O pacote entregue à VM tem como IP de destino o endereço IP do frontend do Load Balancer, e não o IP da VM
B. O Load Balancer encapsula o pacote original em um novo header IP antes de entregá-lo à VM
C. O tráfego é distribuído apenas para a VM com menor utilização de CPU no momento da conexão
D. A VM recebe o pacote com o IP de destino reescrito para o seu próprio IP privado, como no comportamento padrão
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O SKU Standard é o único que suporta zonas de disponibilidade e permite configurar o IP público do frontend como zona-redundante, garantindo que o Load Balancer continue operacional mesmo se uma zona falhar. O SKU Basic não tem suporte a zonas de disponibilidade, tornando as alternativas A e C inválidas independentemente da configuração de IP. A alternativa D está errada porque um IP público dinâmico não é suportado como frontend de Load Balancer Standard; o Standard exige IP estático. A escolha equivocada do SKU Basic em ambientes com requisito de resiliência zonal é um erro de arquitetura com impacto direto em SLA.
Gabarito — Questão 2
Resposta: B
O Azure Load Balancer Standard usa o endereço IP 168.63.129.16 como origem das health probes, mas o tráfego de dados originado pelo Load Balancer interno chega às VMs com o IP do cliente como origem e o IP do frontend como destino. NSGs nas subnets das VMs que não possuem regra explícita permitindo tráfego do range do Load Balancer ou do IP de probe podem silenciosamente descartar os pacotes. O resultado é que as probes falham, o Load Balancer marca todas as instâncias como unhealthy e o tráfego para. A alternativa A é falsa: SKU Standard suporta configuração interna. A alternativa C é falsa: TCP é um protocolo válido para health probes. A alternativa D representa um equívoco comum: Session persistence afeta o hash de distribuição, não o roteamento em si.
Gabarito — Questão 3
Resposta: Falso
A partir de setembro de 2025, o Azure removeu o SNAT padrão implícito para VMs em backend pools de Load Balancers Standard sem outbound rules configuradas. Com o SKU Standard, VMs sem IP público individual e sem outbound rule explícita ou NAT Gateway associado não possuem conectividade de saída à internet. Esse comportamento é oposto ao do SKU Basic, que ainda fornece SNAT implícito. Confiar no SNAT implícito do Standard para garantir saída de tráfego é um erro de design que pode resultar em falhas silenciosas de conectividade em workloads que precisam acessar serviços externos.
Gabarito — Questão 4
Resposta: B
O Idle timeout do Azure Load Balancer define por quanto tempo uma conexão TCP inativa pode ser mantida antes de ser encerrada pelo Load Balancer. O valor padrão de 4 minutos é insuficiente para aplicações com conexões longas ou períodos de inatividade maiores. Aumentar o Idle timeout (até 30 minutos no SKU Standard) mantém o mapeamento de sessão ativo por mais tempo. A alternativa A eliminaria a persistência de sessão, agravando o problema. A alternativa C é incorreta: o Load Balancer suporta persistência de sessão via hash de IP ou IP e protocolo. A alternativa D é um distrator plausível, mas health probes verificam disponibilidade da instância, não o estado da sessão individual do usuário.
Gabarito — Questão 5
Resposta: A
Com Floating IP habilitado (também referenciado em alguns contextos como Direct Server Return), o Load Balancer entrega o pacote à VM com o IP de destino preservado como o IP do frontend, sem reescrever para o IP privado da VM. Isso exige que a própria VM tenha o IP do frontend configurado em sua interface de rede ou loopback para aceitar e processar o pacote corretamente. Essa configuração é necessária em cenários como SQL Server Always On Availability Groups e outras topologias que requerem que a VM "veja" o IP virtual. A alternativa B descreve encapsulamento, que não é o mecanismo utilizado. A alternativa C descreve balanceamento por métricas de CPU, que não é suportado no Load Balancer. A alternativa D descreve exatamente o comportamento padrão sem Floating IP.