Laboratório Técnico: Integrate Private Link and Private Endpoint with DNS
Questões
Questão 1 — Múltipla Escolha
Uma equipe de plataforma configurou um Private Endpoint para uma conta de armazenamento (mystorageaccount.blob.core.windows.net) em uma VNet. Após a criação, máquinas virtuais dentro da VNet ainda resolvem o FQDN para o endereço IP público do serviço.
Qual é a causa mais provável desse comportamento?
A) O Private Endpoint foi criado em uma subnet sem delegação, o que impede a resolução privada.
B) A zona DNS privada privatelink.blob.core.windows.net não foi vinculada à VNet onde as VMs estão localizadas.
C) O registro A na zona DNS privada aponta para o endereço IP público em vez do IP privado do endpoint.
D) O Azure DNS público sobrescreve automaticamente qualquer resolução privada quando o serviço é acessível pela internet.
Questão 2 — Cenário Técnico
Uma organização possui a seguinte arquitetura:
Hub VNet <---> Spoke VNet A
Spoke VNet B
O Azure DNS Privado é gerenciado centralmente no Hub. Um Private Endpoint para o Azure Key Vault foi criado no Spoke A. A zona privatelink.vaultcore.azure.net está vinculada apenas ao Hub VNet.
VMs no Spoke A resolvem o FQDN corretamente. VMs no Spoke B falham na resolução e obtêm o IP público.
Qual é a correção adequada?
A) Criar um segundo Private Endpoint no Spoke B apontando para o mesmo Key Vault.
B) Vincular a zona DNS privada privatelink.vaultcore.azure.net também ao Spoke B VNet.
C) Criar uma zona DNS privada separada no Spoke B com o mesmo nome e um registro A idêntico.
D) Ativar o atributo "DNS propagation" no peering entre Hub e Spoke B.
Questão 3 — Verdadeiro ou Falso
Quando um Private Endpoint é criado com a integração automática de DNS habilitada, o Azure cria automaticamente um registro A na zona DNS privada correspondente usando o nome do recurso de destino como subdomínio, sem necessidade de intervenção manual posterior.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
Um engenheiro precisa garantir que clientes on-premises (conectados via ExpressRoute) resolvam um FQDN de Private Endpoint para o IP privado correto, em vez do IP público. O ambiente usa servidores DNS próprios on-premises que não delegam zonas para o Azure.
O engenheiro propõe a seguinte solução:
Servidor DNS on-premises
--> Conditional Forwarder: privatelink.blob.core.windows.net
--> IP: 168.63.129.16
Por que essa abordagem não funcionará como esperado para clientes on-premises?
A) O endereço 168.63.129.16 só é acessível de dentro de uma VNet do Azure, não de redes on-premises.
B) Conditional Forwarders não suportam zonas privatelink.* por restrição da plataforma Azure.
C) O servidor DNS on-premises precisaria usar TCP em vez de UDP para encaminhar consultas ao Azure DNS.
D) A zona privatelink.blob.core.windows.net não pode receber consultas encaminhadas de fora do Azure.
Questão 5 — Múltipla Escolha
Ao configurar DNS para Private Endpoints em um ambiente multi-região com VNets em East US e West Europe, cada região possui seu próprio Private Endpoint para o mesmo serviço, com IPs privados distintos. Ambas as VNets precisam resolver o mesmo FQDN para o IP local correto.
Qual abordagem DNS atende corretamente a esse requisito?
A) Usar uma única zona DNS privada global vinculada a todas as VNets, com dois registros A de mesmo nome apontando para IPs diferentes, confiando no round-robin DNS.
B) Criar uma zona DNS privada por região com o mesmo nome, cada uma vinculada apenas às VNets da respectiva região, contendo o registro A com o IP local correto.
C) Usar o DNS público do serviço com TTL zero para forçar resolução dinâmica baseada em geolocalização.
D) Criar uma única zona DNS privada com dois registros A de nomes distintos e configurar cada VNet para consultar o registro correto por nome completo diferente.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
A resolução privada de FQDNs de serviços Azure depende de dois componentes funcionando em conjunto: a existência da zona DNS privada com o registro A correto, e o vínculo dessa zona à VNet onde o cliente realiza a consulta. Sem o vínculo (Virtual Network Link), o Azure DNS público responde normalmente, retornando o IP público do serviço.
O principal erro que os distratores representam é confundir a existência da zona DNS privada com sua acessibilidade pela VNet. A zona pode existir e ter o registro correto, mas se não estiver vinculada à VNet da VM, ela é invisível para aquele cliente DNS. A alternativa D representa um mito comum: o Azure DNS público não sobrescreve resolução privada; ele simplesmente é o que responde quando a zona privada não está vinculada.
Gabarito — Questão 2
Resposta: B
Em arquiteturas hub-spoke, a zona DNS privada deve ser vinculada a todas as VNets que precisam resolver os FQDNs via DNS privado, incluindo os Spokes. O peering entre VNets não propaga automaticamente vínculos de zonas DNS privadas. O Spoke A resolve corretamente porque a zona está vinculada ao Hub e o Spoke A usa o DNS do Hub via peering; o Spoke B falha porque não possui o vínculo necessário.
A alternativa A é o erro mais comum: criar um segundo Private Endpoint não resolve o problema de DNS, pois o Spoke B ainda resolveria para o IP público sem o vínculo de zona. A alternativa C criaria conflito de zonas com o mesmo nome, o que não é suportado de forma previsível. A alternativa D descreve um atributo inexistente na plataforma.
Gabarito — Questão 3
Resposta: Falso
A afirmação contém um equívoco sutil mas importante. Quando a integração automática de DNS é habilitada durante a criação do Private Endpoint, o Azure cria o registro A usando o nome do recurso de destino como parte do registro, porém o que é registrado é o IP privado do Private Endpoint, não um subdomínio baseado no nome do recurso de forma autônoma e permanente. Mais relevante ainda: a integração automática só funciona corretamente se a zona DNS privada já existir ou for criada naquele momento, e o registro só persiste enquanto o Private Endpoint existir. Se o endpoint for recriado ou movido, o registro não é atualizado automaticamente em todos os cenários, especialmente em ambientes com zonas gerenciadas centralmente via políticas (Azure Policy). Portanto, "sem necessidade de intervenção manual posterior" é incorreto em ambientes com governança de DNS centralizada.
Gabarito — Questão 4
Resposta: A
O endereço 168.63.129.16 é o resolver DNS virtual do Azure, acessível exclusivamente de dentro de VNets Azure. Redes on-premises conectadas via ExpressRoute ou VPN não têm rota para esse IP, pois ele pertence ao espaço de endereçamento interno da plataforma Azure e não é anunciado via BGP.
A solução correta para esse cenário é implantar um DNS Resolver privado do Azure (Azure DNS Private Resolver) com um endpoint de entrada (inbound endpoint) que possua um IP privado acessível da rede on-premises. O forwarder on-premises deve apontar para esse IP, e não para 168.63.129.16. Os distratores B, C e D descrevem restrições inexistentes na plataforma e representam o erro de confundir limitações de roteamento com limitações de protocolo ou configuração de zona.
Gabarito — Questão 5
Resposta: B
Para garantir que cada região resolva o FQDN para o IP privado local, é necessário ter zonas DNS privadas independentes por região, com o mesmo nome, cada uma vinculada somente às VNets da respectiva região e contendo o registro A com o IP correto para aquele ambiente. Zonas DNS privadas do Azure com o mesmo nome em regiões diferentes são entidades separadas e não conflitam, desde que estejam vinculadas a VNets distintas.
A alternativa A falha porque uma única zona com dois registros A de mesmo nome resultaria em round-robin não determinístico: uma VM no East US poderia receber o IP do West Europe, causando latência ou falha de conectividade. A alternativa C não é uma solução de DNS privado e exporia o tráfego à internet. A alternativa D quebraria o requisito funcional de usar o mesmo FQDN, o que é especialmente problemático em cenários com certificados TLS e SDKs que montam o FQDN automaticamente.