Pular para o conteúdo principal

Laboratório Técnico: Secure an origin by using Azure Private Link in Azure Front Door

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe de arquitetura está planejando proteger um backend hospedado em um Azure App Service utilizando Azure Front Door Premium com Private Link. Após configurar a origem com Private Link habilitado, o tráfego ainda não está chegando ao backend.

Qual é a etapa obrigatória que a equipe provavelmente ignorou para que a conexão funcione?

A. Habilitar o endpoint público no App Service para que o Front Door consiga estabelecer o túnel privado.

B. Aprovar manualmente a conexão de ponto de extremidade privado pendente no recurso de origem.

C. Criar um registro DNS privado apontando o FQDN do Front Door para o IP do backend.

D. Configurar um Network Security Group permitindo a sub-rede do Front Door como origem do tráfego.

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

Um engenheiro configurou o Azure Front Door Premium para usar Private Link com uma origem no Azure Internal Load Balancer (ILB). A configuração foi concluída e aprovada, mas ao testar o acesso via Front Door, as requisições retornam erro 502 Bad Gateway.

Observe o trecho da configuração de origem:

{
  "originType": "PrivateLink",
  "privateLinkLocation": "eastus",
  "privateLinkResourceId": "/subscriptions/.../loadBalancers/ilb-prod",
  "requestMessage": "Front Door aprovado"
}

A origem do Load Balancer está em brazilsouth. Qual é a causa mais provável do erro?

A. O campo requestMessage não é suportado para origens do tipo ILB e está causando falha na negociação.

B. O Private Link para ILB exige que o Front Door e o Load Balancer estejam na mesma região lógica de pareamento.

C. A privateLinkLocation aponta para eastus, mas o recurso está em brazilsouth; as regiões devem coincidir.

D. O ILB não suporta integração com Private Link no Azure Front Door, independentemente da configuração.

Questão 3 — Verdadeiro ou Falso​

Afirmação: Ao utilizar o Azure Front Door Premium com Private Link para proteger uma origem, o Azure garante automaticamente que todo o tráfego de internet direcionado diretamente ao endpoint público da origem seja bloqueado, sem necessidade de configuração adicional no recurso de origem.

Verdadeiro ou Falso?

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

Uma empresa precisa expor um serviço hospedado em um Azure Kubernetes Service (AKS) interno via Azure Front Door Premium, garantindo que o tráfego entre o Front Door e o backend nunca trafegue pela internet pública.

A equipe propõe as seguintes abordagens:

A. Configurar uma origem no Front Door Premium apontando para o IP interno do pod AKS diretamente via Private Link.

B. Expor o serviço AKS por meio de um Internal Load Balancer e configurar o Private Link Service sobre esse ILB como origem no Front Door Premium.

C. Usar o Front Door Standard com WAF habilitado e restringir o acesso ao AKS via Network Policy no nível do pod.

D. Criar um Private Endpoint diretamente na VNet do AKS e registrar seu IP como origem customizada no Front Door Premium.

Qual abordagem atende ao requisito de forma arquiteturalmente correta?

Questão 5 — Múltipla Escolha​

Um arquiteto compara o Azure Front Door Standard e o Azure Front Door Premium para decidir qual tier utilizar em um projeto que exige integração com Private Link para proteger origens internas.

Qual afirmação descreve corretamente a diferença entre os dois tiers em relação ao suporte a Private Link?

A. Ambos os tiers suportam Private Link, mas o Standard exige aprovação manual enquanto o Premium aprova automaticamente.

B. Apenas o tier Premium suporta integração com Private Link para origens; o tier Standard não oferece esse recurso.

C. O tier Standard suporta Private Link somente para origens do tipo Azure Storage, enquanto o Premium suporta todos os tipos.

D. Ambos os tiers suportam Private Link, mas o Premium oferece criptografia adicional no túnel privado estabelecido.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

Quando o Private Link é habilitado como método de conexão de uma origem no Azure Front Door Premium, o serviço cria uma conexão de ponto de extremidade privado pendente no recurso de destino (App Service, Storage Account, ILB, etc.). Essa conexão precisa ser aprovada explicitamente pelo proprietário do recurso, seja manualmente pelo portal, via CLI ou por política de aprovação automática configurada no serviço de origem. Enquanto a aprovação não ocorre, o Front Door não consegue estabelecer o canal privado e o tráfego não flui.

A alternativa A representa um equívoco conceitual grave: o objetivo do Private Link é justamente eliminar a dependência do endpoint público. As alternativas C e D correspondem a abordagens de conectividade de rede tradicionais que não se aplicam ao modelo de Private Link do Front Door, onde o tráfego não passa por sub-redes do cliente.

Gabarito — Questão 2​

Resposta: C

No Azure Front Door Premium, ao configurar uma origem com Private Link para um Internal Load Balancer, o campo privateLinkLocation deve indicar a região onde o recurso de origem está provisionado. O Front Door utiliza esse valor para criar o Private Endpoint na região correta. Se a região informada (eastus) não coincide com a região real do recurso (brazilsouth), o serviço não consegue localizar e conectar ao recurso, resultando em falha de conectividade e erro 502.

A alternativa D é o distrator mais perigoso: o ILB é um tipo de origem suportado, desde que configurado via Private Link Service sobre o ILB. A alternativa B descreve um comportamento inexistente; não há requisito de pareamento regional entre Front Door e a origem. A alternativa A é incorreta porque requestMessage é um campo válido e opcional para fins de rastreamento da solicitação de aprovação.

Gabarito — Questão 3​

Resposta: Falso

O Azure Front Door com Private Link não bloqueia automaticamente o tráfego direto ao endpoint público da origem. A responsabilidade de restringir o acesso público é do proprietário do recurso de origem. Por exemplo, em um App Service, é necessário configurar as restrições de acesso para permitir apenas o tráfego proveniente do Front Door (via service tag AzureFrontDoor.Backend) ou, preferencialmente, remover o acesso público completamente após validar que o Private Link está operacional.

Essa é uma distinção crítica: o Private Link garante que o Front Door pode acessar a origem de forma privada, mas não impede que outros clientes acessem o endpoint público da origem diretamente. O endurecimento completo exige configuração ativa no lado da origem.

Gabarito — Questão 4​

Resposta: B

O Azure Front Door Premium não suporta Private Link direto para IPs de pods ou para recursos AKS de forma nativa. A arquitetura correta para expor serviços AKS internamente via Front Door é: criar um Internal Load Balancer na frente do serviço AKS e, sobre esse ILB, provisionar um Private Link Service. O Front Door então aponta para esse Private Link Service como origem, estabelecendo o canal privado end-to-end.

A alternativa A é inviável tecnicamente porque Private Link opera no nível de serviço, não de pod individual. A alternativa C usa o tier errado (Standard não suporta Private Link) e não resolve o requisito de tráfego privado. A alternativa D descreve um Private Endpoint criado pelo cliente, mas a relação no Front Door é inversa: é o Front Door quem cria o endpoint privado no lado do serviço de origem via Private Link Service ou nos tipos de origem suportados nativamente.

Gabarito — Questão 5​

Resposta: B

O suporte a Private Link para origens é uma funcionalidade exclusiva do Azure Front Door Premium. O tier Standard não oferece esse recurso. Essa é uma das diferenças fundamentais entre os dois tiers e um critério de decisão direto quando o requisito envolve conectividade privada com origens.

As alternativas A e D descrevem comportamentos fictícios: não há diferença no mecanismo de aprovação nem camada de criptografia adicional entre os tiers relacionada ao Private Link. A alternativa C inventa uma restrição por tipo de origem que não existe na documentação do produto. O Private Link no Front Door Premium suporta múltiplos tipos de origem, incluindo App Service, Storage, ILB com Private Link Service e outros serviços compatíveis, sem distinção por tier dentro do Premium.