Laboratório Técnico: Create a Private Link service
Questões
Questão 1 — Múltipla Escolha
Ao criar um Private Link service em frente a um Standard Load Balancer interno, um arquiteto percebe que a configuração exige um tipo específico de NAT para funcionar. Qual é o propósito do NAT de endereço IP de origem aplicado automaticamente pelo serviço nesse contexto?
A) Garantir que o tráfego do consumidor chegue ao backend com o IP original preservado, evitando conflitos de roteamento.
B) Traduzir o endereço IP do consumidor para um IP dentro do espaço de endereçamento da sub-rede do provedor, evitando conflitos entre VNets sobrepostas.
C) Mapear o IP privado do endpoint do consumidor para o IP público do Load Balancer do provedor.
D) Substituir o IP de destino do pacote pelo IP do backend real antes de encaminhar ao pool do Load Balancer.
Questão 2 — Cenário Técnico
Uma equipe configurou um Private Link service e forneceu o alias ao time de consumidores. O time consumidor criou um Private Endpoint na VNet deles apontando para esse alias. Após a criação, o status da conexão no lado do provedor aparece como Pending. O tráfego não flui.
O que o provedor precisa fazer para que a conectividade seja estabelecida?
A) Recriar o Private Link service com a opção de aprovação automática habilitada para o subscription do consumidor.
B) Aprovar manualmente a solicitação de conexão pendente no Private Link service, pois a aprovação automática não foi configurada para aquela subscription.
C) Solicitar ao consumidor que delete e recrie o Private Endpoint usando o Resource ID completo em vez do alias.
D) Adicionar o endereço IP do Private Endpoint do consumidor ao Network Security Group da sub-rede do provedor.
Questão 3 — Verdadeiro ou Falso
Um Private Link service pode ser associado a um Basic Load Balancer interno, desde que o SKU da sub-rede de NAT seja compatível com o serviço.
Questão 4 — Cenário Técnico
Um engenheiro está criando um Private Link service e precisa definir a sub-rede de NAT. Ele escolhe uma sub-rede que também hospeda as VMs do backend do Load Balancer, acreditando simplificar o design. Observe a configuração parcial:
Private Link Service:
Load Balancer Frontend IP: 10.0.1.10 (Internal Standard LB)
NAT Subnet: 10.0.1.0/24 <-- mesma sub-rede dos backends
Visibility: Restricted (subscription list)
Qual é o principal problema desta abordagem?
A) A sub-rede de NAT deve pertencer a uma VNet diferente da VNet do Load Balancer.
B) Usar a mesma sub-rede dos backends para NAT não é tecnicamente proibido, mas cria risco operacional de esgotamento de IPs de NAT e sobreposição de gerenciamento, sendo uma prática explicitamente não recomendada.
C) O Private Link service requer que a sub-rede de NAT tenha uma rota padrão apontando para um NVA antes de encaminhar ao Load Balancer.
D) A sub-rede de NAT precisa ter o Private Link Network Policy habilitado, o que é incompatível com sub-redes que hospedam VMs.
Questão 5 — Múltipla Escolha
Um provedor de serviços deseja expor sua solução via Private Link service para um conjunto restrito de clientes, sem que o alias seja descoberto publicamente. Além disso, ele quer que consumidores de subscriptions específicas consigam criar Private Endpoints sem aprovação manual.
Qual combinação de configurações atende a esses dois requisitos simultaneamente?
A) Visibilidade definida como None e aprovação automática configurada com a lista de subscriptions autorizadas.
B) Visibilidade definida como RBAC e aprovação automática desabilitada, delegando controle via Azure Policy.
C) Visibilidade definida como Restricted (subscriptions específicas) e aprovação automática configurada com as mesmas subscriptions.
D) Visibilidade definida como Public e aprovação automática configurada apenas para as subscriptions dos clientes, bloqueando as demais via NSG.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O SNAT (Source NAT) aplicado pelo Private Link service traduz o IP de origem do consumidor para um IP alocado da sub-rede de NAT do provedor. Isso é fundamental porque consumidores e provedores podem ter espaços de endereçamento sobrepostos, e o backend do provedor nunca vê o IP real do consumidor, vendo apenas um IP da sub-rede de NAT.
O principal equívoco representado pelos distratores é confundir a direção da tradução: o NAT atua sobre o IP de origem (consumidor), não sobre o IP de destino (backend). A alternativa A nega exatamente o que acontece. A alternativa C mistura conceitos de IPs públicos, que não fazem parte do fluxo do Private Link. A alternativa D descreve o comportamento do Load Balancer (DNAT), não do Private Link.
Gabarito — Questão 2
Resposta: B
Quando um Private Link service não tem a subscription do consumidor listada em aprovação automática, toda nova conexão de Private Endpoint chega com status Pending. O fluxo de dados permanece bloqueado até que o proprietário do serviço acesse o painel de conexões e aprove manualmente a requisição.
A alternativa A é incorreta porque recriar o serviço não é necessário; a aprovação automática pode ser editada sem recriação, mas a solução imediata é a aprovação manual da conexão existente. A alternativa C é um equívoco comum: alias e Resource ID são formas válidas e intercambiáveis de referenciar o serviço; o status Pending não está relacionado a qual forma foi usada. A alternativa D confunde o plano de controle (aprovação de conexão) com o plano de dados (regras de NSG), que são mecanismos independentes.
Gabarito — Questão 3
Resposta: Falso
O Private Link service exige obrigatoriamente um Standard Load Balancer interno como frontend. O Basic Load Balancer não é suportado para essa finalidade, independentemente de qualquer configuração de sub-rede ou SKU adicional. Essa distinção é importante porque o Basic LB carece dos recursos de alta disponibilidade e das APIs de integração necessárias ao Private Link service.
Gabarito — Questão 4
Resposta: B
Tecnicamente, o Azure não impede que a sub-rede de NAT seja a mesma dos backends, mas isso é uma prática explicitamente não recomendada pela Microsoft. O problema central é que os IPs de NAT são alocados dinamicamente dessa sub-rede para cada conexão de consumidor, o que pode esgotar o espaço disponível e criar conflitos operacionais em um ambiente onde as VMs também consomem IPs do mesmo range.
A alternativa A é falsa: a sub-rede de NAT deve estar na mesma VNet do Load Balancer. A alternativa C introduz um requisito inexistente; o Private Link service não exige NVA na rota da sub-rede de NAT. A alternativa D inverte a lógica correta: na sub-rede de NAT, o Private Link Network Policy deve estar desabilitado, não habilitado, e esse requisito não tem relação com a presença de VMs.
Gabarito — Questão 5
Resposta: C
Para restringir a descoberta do serviço a um grupo específico de subscriptions, a visibilidade deve ser configurada como Restricted, listando explicitamente as subscriptions autorizadas. Para eliminar a fricção de aprovação manual para esses mesmos clientes, a aprovação automática deve ser configurada com a mesma lista.
A alternativa A é incorreta porque visibilidade None impede que qualquer consumidor descubra ou crie conexões com o serviço, bloqueando inclusive os clientes autorizados. A alternativa B é incorreta porque o modo RBAC controla visibilidade por permissão de role, não por subscription, e desabilitar a aprovação automática contradiz o segundo requisito. A alternativa D contradiz o primeiro requisito: visibilidade Public significa que qualquer pessoa com o alias pode tentar criar um Private Endpoint, expondo o serviço além do grupo restrito pretendido.