Pular para o conteúdo principal

Laboratório Técnico: Create private endpoints

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe de desenvolvimento precisa que uma aplicação hospedada em uma rede virtual acesse uma conta do Azure Storage de forma privada, sem que o tráfego passe pela internet pública. Após criar o private endpoint para a conta de armazenamento, os testes mostram que a resolução de nomes do endpoint ainda retorna 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 que não possui Network Security Group (NSG) associado.

B) A integração com Private DNS Zone não foi configurada, e o DNS do cliente continua resolvendo o FQDN do serviço para o IP público.

C) O recurso de armazenamento não possui o firewall habilitado, portanto o roteamento privado não é ativado automaticamente.

D) O private endpoint precisa ser associado a um Public IP para funcionar como ponto de entrada da rede virtual.

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

Uma empresa possui a seguinte configuração:

Rede Virtual: vnet-prod (10.0.0.0/16)
  Subnet: snet-data (10.0.1.0/24)
    - Private Endpoint: pe-sqldb → aponta para Azure SQL Database
    - Network Security Group: nsg-data (associado à subnet)

NSG Rules (Inbound):
  Priority 100 | Source: 10.0.0.0/16 | Dest: * | Port: 443 | Allow
  Priority 200 | Source: *           | Dest: * | Port: *   | Deny

A aplicação na subnet snet-app (10.0.2.0/24) não consegue se conectar ao SQL Database via private endpoint na porta 1433. O DNS resolve corretamente para o IP privado 10.0.1.5.

Qual é a causa do problema?

A) O NSG está bloqueando a porta 1433, pois a regra de Allow cobre apenas a porta 443.

B) Private endpoints não funcionam em subnets que possuem NSG associado por padrão.

C) A subnet snet-data precisa ter Network Policies habilitadas para que o NSG seja respeitado pelo private endpoint.

D) O FQDN do SQL Database deve ser registrado manualmente no arquivo hosts da aplicação quando NSGs estão presentes.

Questão 3 — Verdadeiro ou Falso​

Ao criar um private endpoint para um serviço do Azure, é possível que o mesmo recurso (por exemplo, uma conta de armazenamento) tenha múltiplos private endpoints associados a diferentes redes virtuais, inclusive em regiões distintas da Azure.

Verdadeiro ou Falso?

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

Um arquiteto precisa expor um serviço interno desenvolvido pela própria empresa, hospedado atrás de um Azure Standard Load Balancer interno, para que parceiros de negócio em outras assinaturas possam consumi-lo de forma privada, sem emparelhamento de VNets (VNet Peering).

Após revisar as opções disponíveis, ele considera criar um private endpoint nos ambientes dos parceiros.

Qual recurso do Azure deve ser configurado no lado do provedor para tornar isso possível?

A) Um Virtual Network Gateway com modo de transit routing habilitado.

B) Um Azure Private Link Service, associado ao Standard Load Balancer interno, para expor o serviço como alvo de private endpoints.

C) Um Service Endpoint na subnet do provedor, com política de acesso restrita às assinaturas dos parceiros.

D) Um Azure Application Gateway com WAF, configurado como frontend do serviço interno.

Questão 5 — Múltipla Escolha​

Ao provisionar um private endpoint, o administrador precisa escolher o sub-recurso de destino (target sub-resource) durante a criação. No caso de uma conta do Azure Storage, diferentes sub-recursos representam endpoints distintos.

Qual afirmação descreve corretamente o comportamento desse modelo?

A) Cada sub-recurso corresponde a um serviço de armazenamento independente (blob, file, queue, table), e um único private endpoint cobre todos eles simultaneamente.

B) O sub-recurso define qual serviço de armazenamento será acessado via IP privado; para acessar blob e file de forma privada, são necessários dois private endpoints separados.

C) O sub-recurso é apenas um rótulo organizacional e não afeta o roteamento do tráfego nem a resolução DNS.

D) Um private endpoint criado para o sub-recurso blob também habilita automaticamente o acesso privado ao sub-recurso dfs, tornando desnecessária a criação de um segundo endpoint para Data Lake Storage Gen2.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

Explique:

  • O private endpoint recebe um IP privado dentro da subnet, mas para que os clientes resolvam o FQDN do serviço para esse IP privado, é necessário integrar a Private DNS Zone correta (por exemplo, privatelink.blob.core.windows.net para Storage Blob). Sem essa integração, o DNS público da Microsoft devolve o IP público do serviço, e o tráfego nunca chega pelo caminho privado.
  • A alternativa A é incorreta porque a ausência de NSG não impede a resolução de nomes; impacta apenas o fluxo de pacotes. A alternativa C confunde firewall do recurso (que controla acesso) com resolução DNS. A alternativa D é conceitualmente errada: private endpoints são, por definição, entidades sem IP público.
  • Escolher a alternativa errada nesse cenário resultaria em tráfego continuando pela internet pública, violando requisitos de segurança e possivelmente gerando custos de egresso inesperados.

Gabarito — Questão 2​

Resposta: A

Explique:

  • A regra de Allow do NSG cobre exclusivamente a porta 443. O Azure SQL Database usa a porta 1433 (TCP), que não está contemplada em nenhuma regra permissiva. A regra de Deny na prioridade 200 bloqueia todo o restante do tráfego, incluindo a porta 1433.
  • A alternativa B inverte a realidade: NSGs funcionam em subnets com private endpoints normalmente, desde que as Network Policies estejam habilitadas. Por padrão, elas estão desabilitadas, o que significa que o NSG seria ignorado. Porém, como o DNS já resolve corretamente e o problema é de conectividade na camada de transporte, o comportamento descrito aponta para bloqueio de porta, não para política desabilitada. A alternativa C trata exatamente desse detalhe: com políticas desabilitadas, o NSG não seria aplicado, o que produziria o efeito oposto (conexão funcionando mesmo sem regra explícita). A alternativa D não tem fundamento técnico.
  • Este cenário reforça que revisar regras de NSG por porta específica é essencial antes de investigar causas mais complexas.

Gabarito — Questão 3​

Resposta: Verdadeiro

Explique:

  • Um mesmo recurso do Azure pode ser alvo de múltiplos private endpoints sem restrição de quantidade por design. Cada private endpoint reside em uma subnet de uma rede virtual específica e recebe seu próprio IP privado naquele espaço de endereçamento. Não há impedimento para que redes virtuais em regiões diferentes criem seus próprios private endpoints apontando para o mesmo recurso.
  • Esse comportamento é justamente o que permite arquiteturas multi-região ou multi-assinatura onde o mesmo serviço centralizado é consumido de forma privada por múltiplos ambientes isolados.
  • O ponto não óbvio aqui é que a limitação de "um endpoint por rede" não existe; o que deve ser gerenciado é a zona DNS privada em cada ambiente para garantir resolução correta em cada rede consumidora.

Gabarito — Questão 4​

Resposta: B

Explique:

  • O Azure Private Link Service é o componente que permite ao provedor de um serviço expô-lo como destino de private endpoints em assinaturas de terceiros. Ele é associado ao Standard Load Balancer interno (não Basic), e gera um alias que os consumidores usam ao criar seus private endpoints, sem necessidade de peering ou conectividade direta entre as VNets.
  • A alternativa A trata de conectividade de rede entre sites, não de exposição de serviço via Private Link. A alternativa C usa Service Endpoints, que são um mecanismo diferente: estendem a identidade da rede virtual ao serviço, mas não criam um IP privado roteável para terceiros em outras assinaturas. A alternativa D introduz um componente de balanceamento e WAF que não resolve o requisito de isolamento entre assinaturas sem peering.
  • Compreender a distinção entre Private Link Service (lado do provedor) e private endpoint (lado do consumidor) é fundamental para projetar arquiteturas de serviços compartilhados no Azure.

Gabarito — Questão 5​

Resposta: B

Explique:

  • Cada sub-recurso de uma conta de armazenamento representa um endpoint de serviço independente: blob, file, queue, table, web, dfs. Ao criar um private endpoint, o administrador seleciona exatamente qual desses serviços será exposto via IP privado. Para acesso privado a dois serviços distintos, como blob e file, são necessários dois private endpoints separados, cada um com sua própria entrada DNS na zona correspondente.
  • A alternativa A está errada porque um único private endpoint não cobre múltiplos sub-recursos simultaneamente. A alternativa C está errada porque o sub-recurso determina diretamente qual entrada DNS é criada (por exemplo, privatelink.blob.core.windows.net versus privatelink.file.core.windows.net) e, portanto, afeta resolução e roteamento. A alternativa D é incorreta: blob e dfs são sub-recursos distintos; uma conta com hierarquia de namespace (Data Lake Gen2) requer um private endpoint específico para dfs se o acesso via ADLS precisa ser privado.
  • Este modelo granular dá ao administrador controle preciso sobre quais planos de dados são acessíveis pela rede privada, sem expor serviços desnecessários.