Laboratório Técnico: Configure an internal or public load balancer
Questões
Questão 1 — Múltipla Escolha
Você precisa distribuir tráfego HTTPS entre três máquinas virtuais em uma mesma região do Azure. O requisito é que sessões de um mesmo cliente sempre sejam direcionadas para a mesma VM durante a conexão ativa, sem depender de cookies gerenciados pelo balanceador.
Qual combinação de configuração no Azure Load Balancer atende esse requisito?
A) Protocolo TCP, modo de distribuição Client IP B) Protocolo HTTP, modo de distribuição Client IP and protocol C) Protocolo TCP, modo de distribuição None (hash de cinco tuplas) D) Protocolo HTTP, modo de distribuição Client IP
Questão 2 — Cenário Técnico
Uma equipe configurou um Azure Load Balancer público com o seguinte conjunto de regras:
Frontend IP: 20.10.5.100 (Public IP SKU Standard)
Backend pool: vm-app-01, vm-app-02
Health probe: HTTP, porta 80, intervalo 15s, limite 2 falhas
Load balancing rule: TCP, porta 80 -> 80
Outbound rule: não configurada
Após o deploy, as VMs do backend pool conseguem receber requisições, mas não conseguem iniciar conexões de saída para a internet. Qual é a causa mais provável?
A) O health probe HTTP não é compatível com regras de balanceamento TCP B) O SKU Standard do Load Balancer bloqueia tráfego de saída por padrão e não há regra de outbound nem NAT Gateway associado C) O Backend pool precisa de ao menos três instâncias para que o tráfego de saída seja permitido D) Public IPs do SKU Standard não suportam tráfego de saída associado a Load Balancers
Questão 3 — Verdadeiro ou Falso
Um Internal Load Balancer no Azure pode ser configurado com um IP frontend estático dentro de uma subnet, e esse IP permanece acessível mesmo que todas as VMs do backend pool estejam com o health probe falhando.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
Você administra uma aplicação de três camadas no Azure. A camada de aplicação (app tier) não deve ser acessível diretamente da internet, mas precisa receber tráfego balanceado a partir da camada web. A camada de banco de dados deve receber tráfego somente da camada de aplicação.
Um colega propôs a seguinte arquitetura:
Internet -> Public Load Balancer -> Web VMs (subnet pública)
|
Internal Load Balancer
|
App VMs (subnet privada)
|
Internal Load Balancer
|
DB VMs (subnet privada)
Qual afirmação descreve corretamente o papel dos componentes nessa arquitetura?
A) O Public Load Balancer poderia ser substituído por um Internal Load Balancer com IP público atribuído ao frontend B) Os dois Internal Load Balancers devem obrigatoriamente estar na mesma VNet para que o roteamento funcione C) O Internal Load Balancer distribui tráfego apenas dentro de uma VNet ou rede conectada via peering ou VPN, sem expor um IP público D) O Internal Load Balancer requer que as VMs do backend pool estejam na mesma subnet que o seu frontend IP
Questão 5 — Múltipla Escolha
Ao criar um health probe em um Azure Load Balancer Standard, qual é o comportamento esperado quando todas as instâncias do backend pool falham na sonda de saúde simultaneamente?
A) O Load Balancer para de aceitar novas conexões no frontend e retorna erro TCP RST aos clientes B) O Load Balancer entra em modo de preservação e distribui o tráfego igualmente entre todas as instâncias, independentemente do status da sonda C) O Load Balancer remove o frontend IP temporariamente até que ao menos uma instância se recupere D) O Load Balancer mantém o frontend IP ativo, mas descarta silenciosamente os pacotes até que uma instância se recupere
Gabarito e Explicações
Gabarito — Questão 1
Resposta: A
O Azure Load Balancer suporta três modos de distribuição: hash de cinco tuplas (padrão), Client IP (duas tuplas: IP de origem e destino) e Client IP and protocol (três tuplas). Quando o requisito é afinidade de sessão sem cookies, o modo Client IP é o adequado, pois garante que requisições do mesmo IP de origem sempre cheguem à mesma VM.
A alternativa B introduz o protocolo como terceira tupla, o que quebraria a afinidade quando o mesmo cliente usa portas diferentes em conexões distintas HTTPS. As alternativas C e D usam o hash padrão ou combinações que não garantem afinidade por IP de origem isoladamente. O ponto crítico aqui é que cookies de afinidade são recurso do Application Gateway, não do Load Balancer.
Gabarito — Questão 2
Resposta: B
O Azure Load Balancer Standard não oferece conectividade de saída implícita. No SKU Basic, havia SNAT implícito; no Standard, isso foi eliminado intencionalmente para dar controle explícito ao administrador. Sem uma Outbound Rule configurada no Load Balancer ou um NAT Gateway associado à subnet, as VMs com IP privado não conseguem iniciar conexões para a internet.
A alternativa A é falsa: health probes HTTP e regras TCP coexistem sem conflito. A alternativa C inventa um requisito de quantidade mínima que não existe. A alternativa D está errada porque o problema não é o IP público em si, mas a ausência de rota de saída configurada para o tráfego originado nas VMs.
Gabarito — Questão 3
Resposta: Falso
Quando todas as instâncias de um backend pool falham no health probe, o Azure Load Balancer entra no comportamento de probe down recovery: ele volta a distribuir tráfego para todas as instâncias, tratando-as como se estivessem saudáveis. Esse comportamento evita que o serviço fique completamente inacessível por uma falha generalizada de sonda.
Portanto, o IP frontend permanece acessível, mas o mecanismo de proteção é diferente do que a afirmação sugere. A afirmação implica que o IP estaria acessível e o tráfego simplesmente seria descartado, o que não reflete o comportamento real. Compreender essa distinção é importante para diagnosticar cenários em que o tráfego chega a instâncias aparentemente inativas.
Gabarito — Questão 4
Resposta: C
O Internal Load Balancer opera exclusivamente com endereços IP privados. Seu frontend IP é alocado dentro de uma subnet da VNet e é acessível apenas a recursos dentro da mesma VNet, ou de redes conectadas via VNet Peering ou VPN/ExpressRoute. Ele nunca expõe um IP público.
A alternativa A está errada porque um Internal Load Balancer não aceita IP público no frontend, por definição. A alternativa B é incorreta: dois Internal Load Balancers podem estar em VNets diferentes conectadas via peering. A alternativa D representa um equívoco comum: as VMs do backend pool podem estar em subnets diferentes da subnet do frontend IP, desde que pertençam à mesma VNet ou a uma rede conectada.
Gabarito — Questão 5
Resposta: B
Este é o comportamento de probe down no Azure Load Balancer Standard: quando todas as instâncias falham simultaneamente, o balanceador não descarta o tráfego nem remove o frontend. Em vez disso, ele distribui as conexões entre todas as instâncias do pool, ignorando temporariamente o resultado das sondas. Esse mecanismo é chamado de "all down" behavior e foi projetado para evitar blackhole total do serviço.
A alternativa A descreve um comportamento que não ocorre: o frontend continua ativo. A alternativa C é falsa porque o IP frontend nunca é removido automaticamente pelo Load Balancer em resposta a falhas de sonda. A alternativa D confunde o comportamento com o de um firewall ou NSG, que descartam pacotes silenciosamente. O Load Balancer, nesse cenário, tenta entregar o tráfego, não descartá-lo.