Laboratório Técnico: Plan private endpoints
Questões
Questão 1 — Múltipla Escolha
Uma equipe de arquitetura precisa expor um serviço Azure SQL Database exclusivamente para workloads que rodam em uma VNet específica, sem que o tráfego transite pela internet pública. O requisito adicional é que o endereço IP atribuído ao ponto de acesso seja previsível e pertença ao espaço de endereçamento da própria VNet.
Qual recurso atende a esse requisito de forma nativa?
A) Service endpoint configurado na subnet da VNet, com política de acesso restrita ao serviço
B) Private endpoint com uma NIC provisionada na subnet-alvo, vinculada ao recurso via Private Link
C) VNet peering com o managed network do Azure SQL, habilitando roteamento direto entre as redes
D) Application Gateway com backend pool apontando para o FQDN privado do Azure SQL
Questão 2 — Cenário Técnico
Uma equipe configurou um private endpoint para uma conta de armazenamento em uma VNet. Após a configuração, a VM dentro da mesma VNet consegue acessar o storage com sucesso. Porém, uma segunda VM localizada em uma VNet pareada (peered) tenta acessar o mesmo storage pelo FQDN privado e recebe timeout.
O administrador verifica que:
- O peering está ativo e o tráfego geral entre as VNets funciona normalmente
- O NSG da subnet do private endpoint não bloqueia o tráfego
- A VM remota usa o servidor DNS padrão do Azure
nslookup mystorageaccount.blob.core.windows.net
Server: 168.63.129.16
Address: 168.63.129.16
Non-authoritative answer:
Name: mystorageaccount.blob.core.windows.net
Address: 52.XXX.XXX.XXX <-- IP público
Qual é a causa raiz do problema?
A) O peering não propaga rotas de private endpoint entre VNets por padrão, sendo necessário habilitar "Use Remote Gateways"
B) A zona DNS privada vinculada ao private endpoint não está associada à VNet remota, causando resolução via DNS público
C) O NSG da VNet pareada está bloqueando a porta 443 em direção ao IP privado do endpoint
D) O private endpoint precisa ser recriado com a opção "Allow access from all networks" habilitada na conta de storage
Questão 3 — Verdadeiro ou Falso
Um private endpoint provisionado em uma subnet com Network Policies habilitadas (como NSG e UDR) terá essas políticas aplicadas ao tráfego que entra e sai da NIC do endpoint, permitindo que o administrador controle o fluxo por regras de NSG diretamente na subnet do private endpoint.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
Uma organização está desenhando a conectividade para um ambiente hub-and-spoke. Os spokes hospedam workloads que precisam consumir serviços PaaS via private endpoints. O arquiteto propõe centralizar todos os private endpoints no hub e usar o DNS privado resolvido a partir de um servidor DNS customizado também no hub.
Durante os testes, VMs nos spokes conseguem alcançar o IP privado do endpoint diretamente (via rota), mas a resolução de nomes falha para FQDNs dos serviços PaaS.
O servidor DNS customizado no hub encaminha consultas para 168.63.129.16 (Azure DNS).
; Spoke VM query
nslookup mykeyvault.vault.azure.net
Server: 10.0.0.10 <-- DNS customizado no hub
Address: 10.0.0.10
** server can't find mykeyvault.vault.azure.net: NXDOMAIN
Qual ajuste resolve o problema de resolução?
A) Criar um registro A manualmente na zona DNS pública do Azure Key Vault apontando para o IP do private endpoint
B) Vincular a zona DNS privada ao hub VNet onde o servidor DNS customizado está hospedado, para que o Azure DNS resolva corretamente ao receber o forward
C) Substituir o servidor DNS customizado por Azure DNS nativo em todos os spokes, eliminando a necessidade de forwarding
D) Habilitar "DNS Proxy" no Azure Firewall dos spokes para interceptar as consultas antes de chegarem ao hub
Questão 5 — Múltipla Escolha
Ao planejar private endpoints para um serviço que expõe múltiplos sub-recursos (como uma conta de armazenamento com blob, file, queue e table), qual afirmação descreve corretamente o comportamento esperado de provisionamento e DNS?
A) Um único private endpoint pode ser criado para todos os sub-recursos simultaneamente, e uma única zona DNS privada resolve todos os FQDNs
B) Cada sub-recurso exige um private endpoint separado e uma zona DNS privada distinta por sub-recurso
C) Um único private endpoint abrange todos os sub-recursos, mas cada sub-recurso requer sua própria zona DNS privada para resolução correta
D) Os sub-recursos compartilham o mesmo IP privado atribuído ao private endpoint, diferenciando-se apenas pela porta TCP utilizada
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
Um private endpoint provisiona uma NIC com IP privado pertencente ao espaço de endereçamento da VNet e vincula esse IP a um recurso PaaS específico via Azure Private Link. O tráfego nunca sai para a internet pública; ele permanece inteiramente dentro do backbone da Microsoft e da VNet do cliente. O IP é previsível porque é alocado da subnet como qualquer outra NIC.
O principal erro conceitual dos distratores está em confundir service endpoint com private endpoint. Service endpoints (A) não atribuem um IP da VNet ao serviço; eles apenas estendem a identidade da VNet para a rota de acesso ao serviço público, e o IP do serviço continua sendo público. VNet peering (C) conecta redes, mas não resolve o roteamento para serviços PaaS gerenciados pela Microsoft. O Application Gateway (D) é um balanceador de camada 7 e não cria acesso privado a serviços PaaS.
Gabarito — Questão 2
Resposta: B
O output do nslookup mostra que a VM remota está resolvendo o FQDN para o IP público da conta de storage. Isso indica falha na resolução DNS privada, não um problema de roteamento ou NSG, já que o tráfego geral entre VNets funciona.
O funcionamento correto depende de a zona DNS privada (privatelink.blob.core.windows.net) estar associada (linked) à VNet da VM que faz a consulta. Quando o DNS customizado ou o Azure DNS nativo recebe a consulta, ele só retorna o IP privado do endpoint se a VNet solicitante estiver vinculada à zona privada. A VNet remota não estava vinculada, então a consulta escapou para a resolução pública.
O erro conceitual dos distratores está em focar em roteamento (A) e NSG (C), quando o diagnóstico já mostra que o problema é de resolução de nomes. A opção D inverte a lógica: "allow access from all networks" diz respeito ao firewall da storage account no plano de dados, não ao DNS ou ao private endpoint.
Gabarito — Questão 3
Resposta: Falso
Por padrão, Network Policies estão desabilitadas para private endpoints. Isso significa que NSGs e UDRs aplicados à subnet não têm efeito sobre o tráfego que entra e sai da NIC do private endpoint, a menos que o administrador habilite explicitamente a propriedade PrivateEndpointNetworkPolicies na subnet.
Esse comportamento é contraintuitivo porque NSGs aplicados à subnet normalmente afetam todos os recursos. O design original dos private endpoints desabilitou esse comportamento para simplificar a implantação. A partir de versões mais recentes da API do Azure, é possível habilitar PrivateEndpointNetworkPolicies para retomar o controle via NSG e UDR. Portanto, assumir que as políticas são aplicadas automaticamente representa um erro de planejamento de segurança com consequências reais.
Gabarito — Questão 4
Resposta: B
O problema está na cadeia de resolução DNS. O servidor customizado no hub faz forward para 168.63.129.16 (Azure DNS), que só consegue resolver usando zonas DNS privadas se a VNet onde ele é consultado estiver vinculada à zona privada correspondente.
Como o Azure DNS é consultado a partir do contexto da hub VNet (onde o servidor DNS customizado reside), a zona privada precisa estar linked ao hub. Sem essa associação, o Azure DNS não encontra o registro privado e responde com NXDOMAIN ou com o IP público.
A opção A cria um workaround manual frágil e sem relação com o problema de forwarding. A opção C elimina a arquitetura centralizada, que é um requisito do design hub-and-spoke. A opção D (DNS Proxy no Firewall) pode ser uma solução arquitetural complementar válida, mas não resolve o problema raiz identificado: a zona privada simplesmente não está vinculada à VNet que serve de ponto de consulta do Azure DNS.
Gabarito — Questão 5
Resposta: B
Para serviços com múltiplos sub-recursos, como uma conta de armazenamento, cada sub-recurso (blob, file, queue, table) é tratado como um target sub-resource distinto no momento de criação do private endpoint. Isso significa que cada sub-recurso requer seu próprio private endpoint, com seu próprio IP privado, e sua própria zona DNS privada (privatelink.blob.core.windows.net, privatelink.file.core.windows.net, etc.).
O erro conceitual da opção A é imaginar que um único endpoint cobre todos os sub-recursos. O erro da opção C é correto na parte do DNS, mas errado ao afirmar que um único endpoint abrange todos os sub-recursos. O erro da opção D é confundir o modelo de private endpoint com o modelo de service endpoint ou de um proxy, onde a diferenciação por porta faria sentido. Em private endpoints, cada sub-recurso tem um IP privado dedicado e seu próprio FQDN mapeado via zona DNS privada.