Laboratório Técnico: Integrate a Private Link service with on-premises clients
Questões
Questão 1 — Múltipla Escolha
Uma equipe de rede precisa expor um serviço interno hospedado em um Standard Load Balancer no Azure para clientes on-premises de parceiros, sem expor o serviço à internet pública e sem exigir emparelhamento de redes virtuais (VNet peering) entre as partes.
Qual combinação de recursos torna esse cenário possível?
A) Um Public Load Balancer associado a um endpoint público, com NSG restringindo o acesso ao IP do parceiro.
B) Um Private Link Service vinculado ao Standard Load Balancer, com um Private Endpoint criado na VNet do consumidor e conectado via ExpressRoute ou VPN ao ambiente on-premises.
C) Um Service Endpoint configurado na subnet do consumidor, apontando para o serviço interno, com rota definida via BGP sobre VPN.
D) Um Internal Load Balancer com IP estático acessível diretamente via túnel VPN site-to-site, sem necessidade de Private Link.
Questão 2 — Cenário Técnico
Um engenheiro configurou um Private Link Service para expor uma aplicação interna. O serviço foi aprovado e o Private Endpoint foi criado com sucesso no lado do consumidor. No entanto, os clientes on-premises não conseguem alcançar o endpoint pelo nome DNS configurado.
O ambiente está assim:
On-premises DNS → resolve "app.interno.empresa.com"
Private Endpoint IP: 10.1.4.20 (atribuído na VNet do consumidor)
DNS on-premises: aponta para 10.1.4.20
Rota para 10.1.4.0/24: ausente na tabela de rotas on-premises
Qual é a causa mais provável da falha de conectividade?
A) O Private Link Service não suporta acesso a partir de clientes on-premises; é necessário um Public Endpoint.
B) O DNS on-premises não pode resolver nomes de Private Endpoints porque o Azure DNS privado é obrigatório e não pode ser integrado com resolvedores externos.
C) A rota para o prefixo de rede do Private Endpoint não está sendo anunciada ou configurada para o ambiente on-premises, impedindo o roteamento do tráfego ao IP do endpoint.
D) O Private Endpoint não foi registrado na zona de DNS privado correta, e por isso o endereço IP retornado é o IP público do serviço.
Questão 3 — Verdadeiro ou Falso
Um Private Link Service pode ser associado a um Basic Load Balancer, desde que o serviço de backend esteja em uma subnet com políticas de rede de Private Link desabilitadas.
Questão 4 — Cenário Técnico
Uma empresa deseja que seus clientes on-premises acessem um Private Endpoint hospedado em uma VNet do Azure via ExpressRoute com peering privado. O engenheiro responsável configura o Private Endpoint, cria uma zona de DNS privado (privatelink.database.windows.net) e a vincula à VNet. Após a configuração, os clientes on-premises tentam resolver o nome e recebem o IP público do serviço, e não o IP privado do endpoint.
Qual é a causa desse comportamento?
A) O peering privado do ExpressRoute não suporta tráfego para Private Endpoints; é necessário usar Microsoft Peering.
B) A zona de DNS privado está vinculada à VNet do Azure, mas os resolvedores DNS on-premises não consultam o Azure DNS privado diretamente; é necessário um DNS Forwarder ou DNS Resolver configurado para encaminhar as consultas ao Azure.
C) O registro A da zona de DNS privado foi sobrescrito pelo registro CNAME público do serviço, e é necessário excluir o registro CNAME manualmente.
D) O Private Endpoint precisa ter uma política de rede de DNS habilitada na subnet para que a resolução funcione em cenários híbridos com ExpressRoute.
Questão 5 — Múltipla Escolha
Ao configurar o acesso de clientes on-premises a um serviço exposto via Private Link, qual é o papel das políticas de rede do Private Endpoint (PrivateEndpointNetworkPolicies) na subnet onde o endpoint está provisionado?
A) Elas controlam se o Private Endpoint pode ser acessado por clientes fora da VNet, bloqueando conexões oriundas de redes on-premises por padrão.
B) Quando habilitadas, permitem que NSGs e rotas definidas pelo usuário (UDRs) sejam aplicadas ao tráfego destinado ao IP do Private Endpoint, possibilitando controle granular de tráfego.
C) Elas determinam se o Private Link Service pode aceitar conexões de consumidores em subscriptions diferentes, funcionando como uma lista de controle de acesso entre tenants.
D) Quando habilitadas, desativam a resolução de DNS privado para o endpoint e exigem que o cliente use o IP diretamente.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O Private Link Service é o mecanismo que permite ao provedor expor um serviço por trás de um Standard Load Balancer de forma privada. O consumidor cria um Private Endpoint em sua VNet, que recebe um IP privado. Clientes on-premises acessam esse IP via ExpressRoute (peering privado) ou VPN site-to-site, sem qualquer exposição à internet.
O principal erro representado pelos distratores é confundir mecanismos de restrição de acesso (NSG, Service Endpoint) com isolamento de rede real. Service Endpoints não criam um IP privado na VNet do consumidor; eles apenas estendem a identidade da VNet ao plano de controle do serviço. Um Internal Load Balancer acessível via VPN sem Private Link expõe o IP interno diretamente e exige sobreposição de espaço de endereçamento ou peering, o que o Private Link resolve por design.
Gabarito — Questão 2
Resposta: C
O DNS resolveu corretamente o nome para o IP 10.1.4.20, mas o tráfego não chega ao destino porque não existe rota para o prefixo 10.1.4.0/24 na tabela de rotas on-premises. A resolução de DNS e o roteamento de pacotes são camadas independentes: o cliente sabe para onde enviar, mas a infraestrutura de rede não sabe como encaminhar o pacote.
A alternativa A é falsa: Private Link suporta acesso on-premises. A alternativa B é imprecisa: é possível integrar DNS on-premises com o Azure via forwarders. A alternativa D descreve um problema real, mas não é a causa neste cenário, pois o IP retornado já é o IP privado correto (10.1.4.20).
Gabarito — Questão 3
Resposta: Falso
O Private Link Service exige obrigatoriamente um Standard Load Balancer como frontend. O Basic Load Balancer não é compatível com Private Link. Essa é uma limitação de plataforma, não contornável por configuração de subnet ou políticas de rede. A confusão ocorre porque outras funcionalidades do Azure aceitam Basic Load Balancer, levando ao equívoco de que a restrição pode ser compensada por outros ajustes de configuração.
Gabarito — Questão 4
Resposta: B
O Azure DNS privado responde apenas a consultas que chegam de dentro da VNet vinculada. Os resolvedores DNS on-premises consultam seus próprios servidores, que por padrão não encaminham consultas ao Azure. Para resolver esse gap, é necessário um DNS Forwarder (uma VM ou serviço de resolução dentro da VNet) ou o Azure DNS Private Resolver, que aceita consultas de redes externas e as encaminha ao DNS privado do Azure.
A alternativa A está errada: o peering privado do ExpressRoute suporta tráfego a Private Endpoints. A alternativa C descreve um comportamento que não ocorre automaticamente; o registro A da zona privada não é sobrescrito por CNAME público de forma espontânea. A alternativa D confunde políticas de rede de endpoint (que afetam NSG/UDR) com resolução de DNS.
Gabarito — Questão 5
Resposta: B
Por padrão, as políticas de rede do Private Endpoint estão desabilitadas, o que significa que NSGs e UDRs associados à subnet não são aplicados ao tráfego destinado ao IP do Private Endpoint. Ao habilitar PrivateEndpointNetworkPolicies, passa a ser possível usar NSGs para controlar quais origens (incluindo prefixos on-premises) podem alcançar o endpoint, e UDRs para forçar o tráfego por um NVA ou firewall.
Os distratores representam confusões comuns: a alternativa A inverte a lógica (as políticas não bloqueiam por padrão e não são específicas para on-premises); a alternativa C descreve o comportamento do mecanismo de aprovação de conexão do Private Link Service, não das políticas de rede; a alternativa D mistura políticas de rede com comportamento de DNS, que são independentes.