Laboratório Técnico: Configure access to private endpoints
Questões
Questão 1 — Múltipla Escolha
Uma equipe de desenvolvimento precisa que uma aplicação hospedada em uma VNet acesse uma conta do Azure Storage via Private Endpoint. Após a criação do endpoint, a aplicação continua resolvendo o nome da conta de storage para o IP público. Qual é a causa mais provável desse comportamento?
A. O Private Endpoint foi criado em uma subnet diferente da aplicação, o que impede a resolução privada.
B. A integração com uma Private DNS Zone não foi configurada, então o DNS público ainda responde às consultas.
C. O Network Security Group da subnet bloqueia o tráfego na porta 443, impedindo a comunicação com o endpoint.
D. O registro A da Private DNS Zone foi criado manualmente com o IP público em vez do IP privado do endpoint.
Questão 2 — Cenário Técnico
Uma organização configurou um Private Endpoint para um Azure SQL Database em uma VNet de produção. Agora deseja permitir que VNets de outras regiões acessem o mesmo endpoint. A topologia atual usa VNet Peering entre as VNets. O time relata que as VNets pareadas não conseguem resolver nem alcançar o endpoint privado.
Qual é a ação correta para resolver o problema de resolução de nomes?
A. Criar um novo Private Endpoint em cada VNet de destino, apontando para o mesmo Azure SQL Database.
B. Vincular a Private DNS Zone do endpoint à VNet de cada região que precisa de acesso.
C. Habilitar a opção "Allow Gateway Transit" no peering para propagar automaticamente as zonas DNS privadas.
D. Recriar o Private Endpoint com escopo global habilitado, o que estende a resolução DNS para VNets pareadas automaticamente.
Questão 3 — Verdadeiro ou Falso
Após desabilitar o acesso à rede pública em um recurso do Azure (como uma conta de storage ou um Azure SQL Database), qualquer cliente fora da VNet onde o Private Endpoint está provisionado perde completamente a capacidade de alcançar o recurso, mesmo que o cliente possua as credenciais corretas e esteja em uma rede conectada via VPN Gateway à mesma VNet.
Questão 4 — Cenário Técnico
Um engenheiro de rede executa o seguinte comando em uma VM dentro da VNet onde o Private Endpoint foi criado:
nslookup minha-conta.blob.core.windows.net
A saída retornada é:
Server: 168.63.129.16
Address: 168.63.129.16
Non-authoritative answer:
Name: minha-conta.privatelink.blob.core.windows.net
Address: 52.168.112.45
O endereço 52.168.112.45 é um IP público. O Private Endpoint foi criado e está com status Succeeded. Qual é o diagnóstico correto?
A. O Private Endpoint está com o estado de aprovação pendente, por isso o tráfego ainda é roteado para o IP público.
B. A Private DNS Zone privatelink.blob.core.windows.net não está vinculada à VNet da VM, portanto o DNS público responde à consulta CNAME.
C. O Azure DNS (168.63.129.16) não é compatível com resoluções de Private Endpoint e deve ser substituído por um DNS customizado.
D. A conta de storage ainda tem o acesso público habilitado, o que faz o Azure DNS sempre preferir o IP público.
Questão 5 — Múltipla Escolha
Ao criar um Private Endpoint, o campo Target sub-resource varia conforme o serviço de destino. Para uma conta do Azure Storage, existem múltiplos sub-recursos disponíveis (blob, file, queue, table, dfs, web). Qual é a consequência direta de criar apenas um Private Endpoint apontando para o sub-recurso blob?
A. O acesso privado fica restrito apenas ao protocolo SMB; os demais protocolos continuam usando o endpoint público.
B. Apenas o endpoint do serviço Blob recebe um IP privado; os demais serviços da conta (file, queue etc.) continuam acessíveis somente pelo endpoint público.
C. O Azure bloqueia automaticamente todos os outros sub-recursos da conta de storage como medida de segurança complementar.
D. O Private Endpoint cobre todos os sub-recursos da conta de storage, pois o recurso-pai é a conta em si, e não o serviço individual.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
A integração com uma Private DNS Zone é o mecanismo que substitui a resolução DNS pública pelo IP privado do endpoint. Quando o recurso do Azure é acessado pelo nome de host padrão (ex.: minha-conta.blob.core.windows.net), o Azure responde com um CNAME intermediário no domínio privatelink. Se uma Private DNS Zone correspondente não estiver vinculada à VNet, esse CNAME continua sendo resolvido pelo DNS público, retornando o IP público do serviço.
A alternativa A está errada porque subnets diferentes dentro da mesma VNet não impedem a resolução DNS. A alternativa C descreveria uma falha de conectividade, não de resolução de nomes. A alternativa D é tecnicamente improvável como erro operacional, pois a integração automática cria o registro A com o IP correto do NIC do Private Endpoint.
Gabarito — Questão 2
Resposta: B
O VNet Peering permite conectividade de camada 3 entre VNets, mas não propaga configurações de DNS entre elas. Cada VNet resolve nomes usando seus próprios servidores DNS configurados. Para que as VNets pareadas resolvam o nome do Private Endpoint para o IP privado, a Private DNS Zone deve ser vinculada a cada VNet que precisa realizar a resolução.
A alternativa A criaria endpoints redundantes desnecessários e geraria IPs privados adicionais, o que não é a abordagem correta para o cenário descrito. A alternativa C confunde "Allow Gateway Transit" com propagação de DNS, esses mecanismos são independentes. A alternativa D não existe: Private Endpoints não possuem escopo global que propague DNS automaticamente.
Gabarito — Questão 3
Falso
A afirmação é falsa. Um cliente em uma rede conectada via VPN Gateway à VNet onde o Private Endpoint está provisionado pode alcançar o recurso, pois o tráfego atravessa o túnel VPN e chega à VNet como se o cliente estivesse localmente conectado a ela. O ponto crítico é que o cliente precisará também resolver o nome para o IP privado, o que exige que o servidor DNS utilizado pelo cliente on-premises encaminhe as consultas do domínio privatelink para o Azure DNS ou para um DNS resolver dentro da VNet. Desabilitar o acesso público protege contra acessos via internet, não contra acessos via conectividade privada devidamente configurada.
Gabarito — Questão 4
Resposta: B
A saída do nslookup mostra que o servidor DNS 168.63.129.16 (Azure DNS) resolveu o CNAME privatelink.blob.core.windows.net para um IP público. Isso indica que o Azure DNS não encontrou um registro A privado para esse domínio dentro do contexto da VNet, o que acontece quando a Private DNS Zone privatelink.blob.core.windows.net não está vinculada à VNet da VM. Sem essa vinculação, o Azure DNS encaminha a resolução para os servidores DNS públicos, que retornam o IP do endpoint público do storage.
A alternativa A é improvável, pois o enunciado indica status "Succeeded". A alternativa C está errada: 168.63.129.16 é o resolvedor padrão do Azure e é totalmente compatível com Private Endpoints quando a zona DNS estiver corretamente vinculada. A alternativa D é incorreta porque o comportamento descrito é de resolução DNS, não de preferência baseada em disponibilidade de acesso público.
Gabarito — Questão 5
Resposta: B
Cada sub-recurso de uma conta de storage representa um endpoint de serviço distinto com seu próprio FQDN e, portanto, exige um Private Endpoint separado e uma entrada na Private DNS Zone correspondente. Criar um Private Endpoint para blob expõe apenas *.blob.core.windows.net via IP privado. Os demais serviços (file, queue, table etc.) permanecem resolvendo para IPs públicos, a menos que tenha sido explicitamente desabilitado o acesso público ou que Private Endpoints adicionais tenham sido criados para eles.
A alternativa A confunde sub-recursos com protocolos de transporte. A alternativa C está incorreta: o Azure não bloqueia automaticamente outros sub-recursos ao criar um Private Endpoint. A alternativa D representa o equívoco mais comum: acreditar que o Private Endpoint cobre o recurso inteiro, quando na verdade ele é sempre criado no nível do sub-recurso.