Pular para o conteúdo principal

Laboratório Técnico: Configure private endpoints for Azure PaaS

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe de segurança exige que um Azure Storage Account deixe de ser acessível pela internet pública, mas continue disponível para máquinas virtuais em uma VNet específica. O administrador cria um private endpoint para o Storage Account e associa uma Private DNS Zone (privatelink.blob.core.windows.net) à VNet.

Após a configuração, as VMs da VNet conseguem resolver o FQDN do storage, mas VMs em uma VNet pareada (peered) falham na resolução DNS e não conseguem acessar o recurso.

Qual é a causa mais provável do problema?

A. O peering de VNet não suporta tráfego para private endpoints por limitação de plataforma.

B. A Private DNS Zone não está vinculada (linked) à VNet pareada, então a resolução do nome privado não ocorre nela.

C. O Network Security Group (NSG) da subnet do private endpoint está bloqueando o tráfego vindo da VNet pareada.

D. O private endpoint precisa ser recriado dentro da VNet pareada para que as VMs dessa rede o alcancem.

Questão 2 — Cenário Técnico​

Um administrador executa o seguinte comando para criar um private endpoint para um Azure SQL Database:

az network private-endpoint create \
  --name pe-sqldb \
  --resource-group rg-prod \
  --vnet-name vnet-prod \
  --subnet snet-pe \
  --private-connection-resource-id "/subscriptions/.../servers/sql-prod" \
  --group-id sqlServer \
  --connection-name conn-sqldb

Após a criação, o administrador tenta conectar ao SQL Server usando o FQDN sql-prod.database.windows.net a partir de uma VM na mesma subnet, mas a conexão cai no endpoint público, não no privado.

Qual etapa está faltando para que a resolução DNS direcione o tráfego ao private endpoint?

A. Criar um registro A manualmente no DNS corporativo apontando para o IP público do SQL Server.

B. Configurar uma Private DNS Zone privatelink.database.windows.net, vinculá-la à VNet e associá-la ao private endpoint.

C. Desabilitar o firewall público do SQL Server nas configurações de "Networking" do recurso.

D. Adicionar uma rota UDR (User Defined Route) na subnet para encaminhar o tráfego ao IP privado do endpoint.

Questão 3 — Verdadeiro ou Falso​

Um private endpoint atribui ao recurso PaaS um endereço IP privado dentro da subnet indicada, e esse IP é alocado dinamicamente pelo Azure a cada vez que o private endpoint é recriado, não podendo ser fixado estaticamente pelo administrador.

Verdadeiro ou Falso?

Questão 4 — Cenário Técnico​

Uma empresa possui um Azure Key Vault configurado com um private endpoint em snet-shared dentro de vnet-hub. A equipe de aplicações reporta que, mesmo após a criação do private endpoint, requisições feitas por um App Service (hospedado em um plano que suporta VNet Integration) ainda chegam ao endpoint público do Key Vault.

O administrador verifica que:

  • A VNet Integration do App Service está corretamente configurada para vnet-hub.
  • A Private DNS Zone privatelink.vaultcore.azure.net existe e está vinculada a vnet-hub.
  • O App Service consegue pingar outros recursos privados na mesma VNet.

O que mais provavelmente impede o tráfego do App Service de usar o private endpoint do Key Vault?

A. App Services com VNet Integration não suportam acesso a private endpoints; é necessário usar um Azure Application Gateway como intermediário.

B. A configuração WEBSITE_DNS_SERVER ou o DNS do App Service não está apontando para o Azure DNS (168.63.129.16), impedindo a resolução da Private DNS Zone.

C. O Key Vault precisa ter o acesso público desabilitado explicitamente para forçar o uso do private endpoint.

D. O private endpoint está em snet-shared, mas deveria estar em uma subnet dedicada exclusivamente ao Key Vault para funcionar com App Services.

Questão 5 — Múltipla Escolha​

Ao criar um private endpoint, o administrador precisa escolher um subresource (group ID) durante a configuração. Considerando um Azure Storage Account, qual afirmação descreve corretamente o propósito e o comportamento dessa escolha?

A. O group ID define qual camada de redundância (LRS, GRS, ZRS) será usada pelo private endpoint para replicar o tráfego.

B. Cada group ID corresponde a um serviço específico do Storage Account (como blob, file, queue, table), e um único private endpoint cobre apenas o subresource selecionado.

C. O group ID é opcional; se omitido, o Azure cria automaticamente private endpoints para todos os subresources do Storage Account.

D. Selecionar o group ID blob também habilita automaticamente acesso privado aos subresources file e queue do mesmo Storage Account.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

A Private DNS Zone no Azure precisa ser explicitamente vinculada a cada VNet que precisar resolver os nomes privados registrados nela. O peering de VNet, por si só, não propaga a resolução de Private DNS Zones: uma VM em uma VNet pareada consulta o DNS da sua própria VNet, e se não houver um link entre a Private DNS Zone e essa VNet, a query retornará o IP público do recurso, não o IP do private endpoint.

O principal equívoco representado pelos distratores é confundir conectividade de rede (que o peering de fato propaga) com resolução de DNS (que exige vínculo explícito da Private DNS Zone). As alternativas A e D são incorretas porque o peering suporta tráfego para private endpoints normalmente, e não é necessário criar um endpoint adicional na VNet pareada. A alternativa C pode ser um problema independente, mas não explica a falha específica de resolução DNS descrita.

Gabarito — Questão 2​

Resposta: B

A criação do private endpoint aloca um IP privado na subnet, mas não configura DNS automaticamente por padrão quando o comando é executado via CLI sem o parâmetro --private-dns-zone. Sem uma Private DNS Zone privatelink.database.windows.net vinculada à VNet, o FQDN sql-prod.database.windows.net continua resolvendo para o IP público do servidor, e o tráfego ignora o private endpoint.

A alternativa C representa um equívoco comum: desabilitar o acesso público é uma boa prática de segurança complementar, mas não resolve o problema de resolução DNS. A alternativa D também é incorreta porque UDRs operam na camada de roteamento IP, não resolvem o problema de DNS. A alternativa A aponta para a solução errada (IP público) e contraria o objetivo de uso do private endpoint.

Gabarito — Questão 3​

Resposta: Falso

O IP privado de um private endpoint pode ser especificado estaticamente pelo administrador no momento da criação, usando o parâmetro --ip-config (via CLI) ou o campo equivalente no portal. Quando não especificado, o Azure aloca um IP disponível na subnet de forma dinâmica. Contudo, após a alocação, esse IP permanece fixo ao private endpoint enquanto ele existir: não há reatribuição dinâmica em recriações a menos que o administrador explicitamente permita.

O comportamento não óbvio aqui é que "dinâmico" no contexto de private endpoints não implica volatilidade do IP: ele se comporta de forma estável após a criação, similar ao que acontece com NICs de VMs com alocação dinâmica mas IP que não muda na prática.

Gabarito — Questão 4​

Resposta: B

App Services com VNet Integration usam o servidor DNS configurado no ambiente para resolver nomes. Se o App Service estiver resolvendo nomes via um DNS externo ou customizado que não encaminha queries para o Azure DNS (168.63.129.16), as Private DNS Zones vinculadas à VNet nunca são consultadas. O resultado é que o FQDN do Key Vault resolve para o IP público, ignorando o private endpoint.

A solução é garantir que o App Service use o Azure DNS como resolver, o que pode ser feito via a configuração de app setting WEBSITE_DNS_SERVER=168.63.129.16. A alternativa A é incorreta: App Services com VNet Integration suportam private endpoints sem necessidade de Application Gateway. A alternativa C é uma medida de segurança válida, mas não é o que impede a resolução do nome privado. A alternativa D é incorreta porque não há restrição de subnet exclusiva para que private endpoints funcionem com App Services.

Gabarito — Questão 5​

Resposta: B

Um Azure Storage Account expõe múltiplos serviços independentes (blob, file, queue, table, web, dfs), e cada um possui seu próprio subresource (group ID). Um private endpoint criado para blob aloca um IP privado e configura resolução DNS apenas para o endpoint de blob (*.blob.core.windows.net), sem afetar os demais serviços. Para ter acesso privado a file e queue, por exemplo, é necessário criar private endpoints adicionais com os group IDs correspondentes.

A alternativa A confunde o conceito de group ID com redundância de dados, que são camadas completamente distintas. A alternativa C é incorreta: o group ID é obrigatório para recursos com múltiplos subresources. A alternativa D representa o equívoco mais perigoso: assumir que um único private endpoint cobre todos os serviços de um Storage Account pode resultar em tráfego de file ou queue continuando a fluir pelo endpoint público sem que o administrador perceba.