Pular para o conteúdo principal

Laboratório Técnico: Choose between public and internal load balancers

Questões​

Questão 1 — Múltipla Escolha​

Uma empresa hospeda uma API de pagamentos em máquinas virtuais dentro de uma subnet privada na Azure. Essa API é consumida exclusivamente por um serviço de back-end que roda em outra subnet da mesma VNet. O time de arquitetura precisa distribuir o tráfego entre as instâncias da API de forma resiliente.

Qual tipo de load balancer é o mais adequado para esse cenário, e por quê?

A) Public Load Balancer, porque oferece maior disponibilidade ao expor um IP público para balanceamento.

B) Internal Load Balancer, porque distribui tráfego entre recursos dentro da mesma VNet sem expor a carga ao tráfego externo.

C) Internal Load Balancer, mas somente se as VMs estiverem em zonas de disponibilidade diferentes.

D) Public Load Balancer com regras de NSG bloqueando acesso externo, garantindo segurança sem abrir mão do balanceamento.

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

Um engenheiro de rede configurou um Public Load Balancer para um conjunto de VMs que hospedam uma aplicação web voltada à internet. Após implantar a solução, ele percebe que as VMs não conseguem iniciar conexões de saída com endpoints externos, como APIs de terceiros, mesmo com as regras de NSG corretas.

Frontend IP: 20.x.x.x (Public)
Backend pool: vm-web-01, vm-web-02
Load balancing rule: TCP 80, TCP 443
Outbound rules: nenhuma configurada

Qual é a causa mais provável do problema?

A) As VMs precisam de um IP público próprio associado à NIC para ter acesso de saída.

B) O Public Load Balancer não suporta tráfego de saída sem que uma Outbound Rule ou um NAT Gateway esteja explicitamente configurado.

C) O NSG está bloqueando o tráfego de saída na subnet, o que impede qualquer comunicação externa independente do load balancer.

D) O Load Balancer Standard não permite que VMs sem IP público façam chamadas de saída para a internet.

Questão 3 — Verdadeiro ou Falso​

Um Internal Load Balancer na Azure pode receber um endereço IP de frontend que pertence a uma subnet diferente daquela onde estão as VMs do backend pool, desde que ambas as subnets façam parte da mesma VNet.

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

Uma organização possui uma arquitetura de três camadas: frontend público, camada de aplicação e banco de dados. O time precisa garantir que:

  • O frontend seja acessível pela internet
  • A camada de aplicação seja acessível apenas pelo frontend
  • O banco de dados seja acessível apenas pela camada de aplicação
Camada         | Tipo de Load Balancer sugerido
---------------|-------------------------------
Frontend       | ?
Aplicação      | ?
Banco de dados | ?

Qual combinação representa a arquitetura correta?

A) Public Load Balancer para todas as três camadas, usando NSGs para controlar o fluxo.

B) Public Load Balancer para o frontend; Internal Load Balancer para a camada de aplicação; sem load balancer no banco de dados.

C) Public Load Balancer para o frontend; Internal Load Balancer para a camada de aplicação; Internal Load Balancer para o banco de dados.

D) Internal Load Balancer para todas as três camadas, com um NAT Gateway provendo acesso externo ao frontend.

Questão 5 — Múltipla Escolha​

Ao comparar o Azure Load Balancer Basic SKU com o Standard SKU, qual afirmação descreve corretamente uma diferença relevante para a escolha entre public e internal no contexto de produção?

A) O SKU Basic suporta zonas de disponibilidade, enquanto o Standard não oferece esse recurso para Internal Load Balancers.

B) O SKU Standard é obrigatório para cenários com Internal Load Balancer em produção, pois o Basic não suporta backend pools com VMs em availability sets.

C) O SKU Standard oferece suporte a zonas de disponibilidade e SLA de 99,99%, enquanto o Basic não oferece SLA e não suporta zone-redundancy, o que o torna inadequado para cargas produtivas críticas.

D) O SKU Basic suporta regras de saída (Outbound Rules) para Public Load Balancers, o que o diferencia positivamente do Standard em cenários de saída controlada.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

Um Internal Load Balancer (ILB) recebe um endereço IP de frontend privado, roteável apenas dentro da VNet (ou redes conectadas via peering/VPN). Ele é a escolha natural quando o consumidor do serviço é interno à infraestrutura, pois nunca expõe o backend a tráfego originado da internet.

A alternativa A erra ao assumir que disponibilidade depende de exposição pública. A C introduz uma restrição falsa: o ILB não exige que as VMs estejam em zonas diferentes. A D representa um antipadrão perigoso: usar um IP público e confiar apenas em NSGs para isolar o tráfego é uma escolha arquitetural frágil e desnecessária quando o tráfego é puramente interno.

Gabarito — Questão 2​

Resposta: B

No Standard SKU, VMs associadas a um Public Load Balancer sem IP público próprio dependem de uma Outbound Rule configurada no próprio load balancer ou de um NAT Gateway na subnet para estabelecer conexões de saída. Sem isso, o tráfego de saída é bloqueado por padrão, o que é uma mudança de comportamento em relação ao SKU Basic.

A alternativa A é incorreta: associar um IP público diretamente à NIC funcionaria, mas não é necessário e representa uma solução de contorno, não a causa do problema. A C desvia o foco para o NSG sem evidência de que ele esteja mal configurado. A D confunde o comportamento do Standard com uma limitação inexistente: o problema não é a ausência de IP público nas VMs, mas a ausência de uma regra de saída.

Gabarito — Questão 3​

Resposta: Falso

O endereço IP de frontend de um Internal Load Balancer deve pertencer à subnet configurada no frontend do load balancer. Esse IP é alocado dentro da faixa de endereços daquela subnet específica. Não é possível atribuir ao frontend um IP de uma subnet diferente, mesmo que estejam na mesma VNet. A subnet do frontend do ILB define o escopo do endereço privado utilizado. Confundir "mesma VNet" com "qualquer subnet da VNet" é um equívoco comum que pode levar a erros de planejamento de endereçamento.

Gabarito — Questão 4​

Resposta: C

Cada camada possui um perfil de acesso distinto. O Public Load Balancer no frontend é o único ponto de entrada da internet. A camada de aplicação deve ser acessível apenas pelo frontend, o que justifica um Internal Load Balancer com IP privado. O banco de dados, embora não precise necessariamente de um load balancer se houver apenas uma instância, em cenários de alta disponibilidade com múltiplas réplicas também se beneficia de um ILB, mantendo todo o tráfego restrito à VNet.

A alternativa B é parcialmente correta, mas omite o ILB para o banco de dados, o que é inadequado em arquiteturas de produção com múltiplas instâncias. A A é um antipadrão por razões já discutidas na Questão 1. A D tornaria o frontend inacessível diretamente da internet sem uma camada adicional de tradução, o que introduz complexidade desnecessária.

Gabarito — Questão 5​

Resposta: C

O Standard SKU foi projetado para cargas produtivas: oferece suporte a zonas de disponibilidade (zone-redundant e zonal), SLA de 99,99%, e diagnósticos detalhados via Azure Monitor. O Basic SKU não oferece SLA formal, não suporta zone-redundancy e tem limitações de escala no backend pool.

A alternativa A inverte os fatos: é o Standard, não o Basic, que suporta zonas de disponibilidade. A B erra ao afirmar que o Basic não suporta VMs em availability sets. A D está errada: o Basic não suporta Outbound Rules; esse recurso é exclusivo do Standard. Conhecer essas diferenças é fundamental para justificar a escolha do SKU em projetos que envolvam tanto Public quanto Internal Load Balancers em ambientes críticos.