Pular para o conteúdo principal

Laboratório Técnico: Create a Backend Pool

Questões

Questão 1 — Múltipla Escolha

Você está configurando um Azure Application Gateway e precisa adicionar membros ao backend pool. Ao revisar as opções disponíveis, percebe que o portal oferece diferentes tipos de destino.

Qual das opções abaixo não é um tipo de destino válido ao criar um backend pool no Application Gateway?

A) Endereço IP ou FQDN
B) Máquina virtual (NIC associada)
C) Conjunto de disponibilidade (Availability Set) como entidade direta
D) App Service


Questão 2 — Cenário Técnico

Uma equipe configurou um Azure Load Balancer (SKU Standard, interno) com um backend pool associado a uma NIC de máquina virtual. Após a implantação, os testes de conectividade falham. Ao investigar, a equipe descobre que a VM está em uma VNet diferente da VNet do Load Balancer, mas ambas estão conectadas via VNet Peering.

Load Balancer (Standard, Interno)
Frontend IP: 10.1.0.10 (VNet-A, Subnet-LB)
Backend Pool: NIC da VM-01

VM-01
IP: 10.2.0.5 (VNet-B, Subnet-VMs)
VNet Peering: VNet-A <-> VNet-B (ativo)

Qual é a causa mais provável da falha?

A) O SKU Standard não suporta backend pools com VMs em VNets distintas, mesmo com peering
B) O backend pool baseado em NIC exige que a NIC esteja na mesma VNet que o Load Balancer
C) O VNet Peering não propaga rotas suficientes para que o Load Balancer alcance a VM
D) O Load Balancer interno não suporta backend pools com endereço IP privado de outra VNet


Questão 3 — Verdadeiro ou Falso

Um Azure Load Balancer de SKU Standard permite adicionar recursos ao backend pool usando o endereço IP como alvo, o que possibilita incluir máquinas em redes on-premises acessíveis via ExpressRoute ou VPN, sem exigir que possuam uma NIC registrada no Azure.

Verdadeiro ou Falso?


Questão 4 — Cenário Técnico

Uma equipe está migrando uma aplicação para o Azure Application Gateway e precisa que o backend pool aponte para um conjunto de instâncias de um Azure App Service. O engenheiro responsável configura o pool usando o endereço IP público das instâncias do App Service, mas depois de alguns dias os health probes começam a falhar de forma intermitente.

O que explica melhor esse comportamento e qual seria a abordagem correta?

A) App Services não são suportados como membros de backend pool no Application Gateway; deve-se usar uma VM intermediária
B) Endereços IP de App Services podem mudar, pois a plataforma é gerenciada; o correto é usar o FQDN do App Service como destino do backend pool
C) O Application Gateway requer que o App Service esteja na mesma região; o problema é geográfico
D) O health probe falha porque o App Service exige autenticação mútua TLS, que o Application Gateway não suporta


Questão 5 — Múltipla Escolha

Ao criar um backend pool no Azure Load Balancer SKU Standard usando o modo de configuração por endereço IP, qual afirmação descreve corretamente uma limitação ou comportamento esperado dessa abordagem?

A) Somente endereços IPv6 são aceitos no modo de configuração por endereço IP
B) Recursos adicionados por IP não precisam estar na mesma VNet, mas devem ter conectividade de rede com o frontend do Load Balancer
C) O modo por endereço IP é exclusivo do Load Balancer SKU Basic e não está disponível no Standard
D) Ao usar endereço IP, o Load Balancer automaticamente associa uma NIC virtual ao recurso de destino para monitoramento


Gabarito e Explicações

Gabarito — Questão 1

Resposta: C

O Application Gateway aceita como membros de backend pool: endereços IP ou FQDNs, NICs de VMs, conjuntos de escala de máquinas virtuais (VMSS) e App Services. Um Availability Set não é uma entidade diretamente endereçável como destino de backend, pois ele é um construto lógico de agrupamento de VMs, não um ponto de rede. As VMs dentro do Availability Set precisam ser adicionadas individualmente via NIC ou IP. O erro conceitual dos distratores é confundir entidades de agrupamento lógico com recursos de rede endereçáveis.


Gabarito — Questão 2

Resposta: B

Quando o backend pool do Azure Load Balancer Standard é configurado no modo NIC, os recursos associados precisam estar na mesma VNet que o Load Balancer. O VNet Peering não contorna essa exigência para o modelo de associação por NIC. A alternativa correta para incluir VMs em VNets diferentes seria usar o modo de configuração por endereço IP, que aceita destinos fora da VNet local, desde que haja conectividade de rede. O erro comum é assumir que o peering ativo é suficiente para qualquer modo de associação de backend.


Gabarito — Questão 3

Resposta: Verdadeiro

O Azure Load Balancer SKU Standard introduziu o backend pool baseado em endereço IP, que elimina a exigência de que o recurso de destino possua uma NIC registrada no Azure. Isso permite incluir servidores físicos ou VMs on-premises acessíveis via ExpressRoute ou VPN Gateway como membros do backend pool. Esse comportamento é uma diferença relevante em relação ao SKU Basic, que exige NICs do Azure, e é frequentemente subestimado por quem associa Load Balancer exclusivamente a recursos IaaS nativos do Azure.


Gabarito — Questão 4

Resposta: B

O Azure App Service opera em infraestrutura gerenciada pela plataforma, e os endereços IP subjacentes das instâncias podem mudar durante eventos de escalonamento, reimplantação ou manutenção. A abordagem correta é configurar o backend pool usando o FQDN do App Service (por exemplo, meuapp.azurewebsites.net), pois o Application Gateway resolve o nome em tempo de execução. O Application Gateway oferece suporte nativo ao App Service como destino de backend, inclusive com integração simplificada no portal. Usar IP fixo em um serviço gerenciado é um erro de arquitetura que viola o modelo de operação esperado da plataforma.


Gabarito — Questão 5

Resposta: B

No modo de configuração por endereço IP do Load Balancer Standard, os destinos não precisam ter NICs registradas no Azure nem estar na mesma VNet, mas precisam ser alcançáveis pela infraestrutura de rede, seja por peering, VPN ou ExpressRoute. As demais alternativas contêm erros factuais: o modo por IP aceita IPv4 e IPv6; ele está disponível no SKU Standard, não no Basic; e o Load Balancer não cria NICs virtuais automaticamente para destinos por IP. O ponto central é entender que a flexibilidade do modo IP tem como contrapartida a responsabilidade explícita de garantir conectividade de rede fim a fim.