Pular para o conteúdo principal

Laboratório Técnico: Configure an Azure Front Door, including routing, origins, and endpoints

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe de plataforma precisa configurar o Azure Front Door para distribuir tráfego entre dois grupos de origens: um hospedado no Brasil e outro nos Estados Unidos. O requisito é que, em condições normais, 80% do tráfego seja direcionado ao grupo americano e 20% ao grupo brasileiro, independentemente da localização geográfica do usuário.

Qual mecanismo de roteamento deve ser configurado para atender a esse requisito?

A) Roteamento baseado em latência, ajustando os pesos de prioridade de cada origem individualmente.

B) Roteamento weighted, definindo pesos proporcionais nos grupos de origens dentro de uma única rota.

C) Roteamento baseado em sessão (session affinity), com pesos atribuídos por endpoint.

D) Duas rotas separadas com condições de correspondência por localização geográfica do cliente.

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

Um engenheiro configurou o Azure Front Door com a seguinte estrutura:

Endpoint:  contoso.azurefd.net
Rota:      /* → Origin Group: BackendProd
Origem:    app-prod.azurewebsites.net (HTTPS, porta 443)

Após a implantação, requisições para https://contoso.azurefd.net/api/data retornam HTTP 502 de forma consistente. O backend responde corretamente quando acessado diretamente via URL. As sondas de integridade (health probes) do Front Door marcam a origem como degradada.

Qual é a causa mais provável do erro?

A) O domínio personalizado não foi validado no endpoint, impedindo o roteamento da rota raiz.

B) A origem não está configurada para aceitar o cabeçalho X-Forwarded-Host enviado pelo Front Door.

C) O certificado TLS da origem não é confiável para o Front Door ou o nome do host da sonda não corresponde ao certificado.

D) A rota /* tem precedência sobre rotas mais específicas, causando loop de redirecionamento interno.

Questão 3 — Verdadeiro ou Falso​

No Azure Front Door (SKU Standard ou Premium), é possível associar mais de um domínio personalizado a um único endpoint, e cada domínio pode ser roteado para um grupo de origens diferente por meio de rotas distintas configuradas no mesmo endpoint.

Verdadeiro ou Falso?

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

Uma empresa utiliza o Azure Front Door Premium para expor uma API global. O time de segurança exige que o tráfego entre o Front Door e as origens (Azure App Services) não passe pela internet pública. O acesso direto às origens por endereços IP externos também deve ser bloqueado.

O engenheiro responsável propõe a seguinte abordagem:

1. Habilitar Private Link na origem dentro do grupo de origens
2. Aprovar a conexão de Private Endpoint no recurso de destino
3. Restringir o acesso à origem somente ao serviço Front Door via
   configuração de Access Restriction no App Service

Qual é o problema dessa abordagem?

A) O Private Link no Azure Front Door não é compatível com Azure App Services; ele funciona apenas com Azure Storage e Azure SQL.

B) A etapa 3 é desnecessária porque, com Private Link ativo, o App Service automaticamente rejeita conexões de endereços IP públicos.

C) O passo 2 é obrigatório e correto, mas a etapa 3 introduz redundância sem problema funcional; a abordagem está tecnicamente válida.

D) O Private Link no Azure Front Door está disponível apenas no SKU Standard, não no Premium.

Questão 5 — Múltipla Escolha​

Ao configurar regras de roteamento no Azure Front Door, um engenheiro precisa garantir que todas as requisições HTTP sejam automaticamente redirecionadas para HTTPS antes de chegarem à origem.

Qual é a forma correta de implementar esse comportamento?

A) Configurar uma regra no Rule Set com condição RequestScheme == HTTP e ação de redirecionamento para HTTPS com código 301.

B) Ativar a opção de redirecionamento HTTPS diretamente na configuração da origem, dentro do grupo de origens.

C) Criar duas rotas separadas: uma aceitando HTTP e outra HTTPS, e definir prioridade maior para a rota HTTPS.

D) Habilitar o TLS mútuo (mTLS) no endpoint, o que força automaticamente o upgrade de todas as conexões HTTP.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

O Azure Front Door suporta o método de roteamento weighted (ponderado), no qual cada origem dentro de um grupo de origens recebe um peso numérico relativo. A distribuição de tráfego segue esses pesos proporcionalmente, sem considerar a localização do usuário. Para 80/20, basta atribuir pesos como 80 e 20 (ou equivalentes como 4 e 1) a cada origem no grupo.

O distrator A confunde "peso" com "prioridade": prioridade define ordem de failover, não distribuição percentual. O distrator C aplica session affinity, que fixa um usuário a uma origem específica após o primeiro acesso e não distribui carga proporcionalmente. O distrator D resolveria um problema diferente (geo-targeting), não distribuição ponderada global.

Gabarito — Questão 2​

Resposta: C

Quando o Azure Front Door realiza sondas de integridade via HTTPS, ele valida o certificado TLS da origem. Se o certificado for autoassinado, emitido por uma CA não confiável, ou se o Subject Name não corresponder ao hostname configurado na origem, a sonda falha e a origem é marcada como degradada. O resultado para o cliente é HTTP 502, pois o Front Door não consegue estabelecer conexão confiável com o backend.

O distrator A é irrelevante para o sintoma descrito: a validação de domínio personalizado afeta o lado do cliente, não o backend. O distrator B é plausível, mas o cabeçalho X-Forwarded-Host não impede a conexão TLS e raramente causa 502 com degradação de sonda. O distrator D descreve um comportamento que não ocorre nesse cenário de configuração simples.

Gabarito — Questão 3​

Resposta: Verdadeiro

No Azure Front Door Standard e Premium, um único endpoint pode ter múltiplos domínios personalizados associados. As rotas são configuradas por combinação de domínio e padrão de caminho, o que permite que api.contoso.com/* aponte para um grupo de origens e www.contoso.com/* aponte para outro, tudo dentro do mesmo endpoint. Essa flexibilidade é um diferencial relevante do modelo de configuração atual (perfil unificado) em relação ao modelo clássico.

O ponto não óbvio aqui é que o escopo do endpoint não limita o número de domínios nem impõe um mapeamento 1:1 entre domínio e grupo de origens.

Gabarito — Questão 4​

Resposta: C

A abordagem descrita está tecnicamente correta. O Private Link no Azure Front Door Premium permite que o tráfego entre o Front Door e origens compatíveis (incluindo Azure App Services) trafegue pela rede privada da Microsoft, sem exposição à internet pública. A aprovação manual da conexão de Private Endpoint (etapa 2) é obrigatória. A etapa 3 (Access Restriction) é redundante do ponto de vista de segurança de rede, mas não introduz erro funcional.

O distrator A está errado: Azure App Service é uma das origens com suporte a Private Link no Front Door Premium. O distrator B está errado: a ativação do Private Link no Front Door não bloqueia automaticamente o acesso público ao App Service; isso requer configuração explícita no próprio recurso. O distrator D inverte a realidade: Private Link está disponível somente no SKU Premium, não no Standard.

Gabarito — Questão 5​

Resposta: A

A forma correta de redirecionar HTTP para HTTPS no Azure Front Door é por meio de um Rule Set, utilizando a condição RequestScheme com valor HTTP e a ação UrlRedirect com protocolo de destino HTTPS e código de status 301 ou 302. Essa abordagem é explícita, controlada e desacoplada da configuração da origem.

O distrator B é incorreto porque a configuração de protocolo na origem define como o Front Door se conecta ao backend, não como ele trata requisições do cliente. O distrator C criaria ambiguidade de roteamento e não garante o redirecionamento; rotas no Front Door não funcionam como regras de prioridade de protocolo. O distrator D confunde mTLS (autenticação de cliente por certificado) com redirecionamento de protocolo: são mecanismos completamente distintos.