Laboratório Técnico: Map requirements to features and capabilities of Azure Front Door
Questões
Questão 1 — Múltipla Escolha
Uma equipe de arquitetura precisa entregar uma aplicação web global com os seguintes requisitos: roteamento baseado em URL, terminação TLS na borda, aceleração de conteúdo dinâmico e proteção contra ameaças na camada de aplicação. O cliente exige um único serviço gerenciado que atenda a todos esses requisitos simultaneamente.
Qual combinação de capacidades do Azure Front Door atende integralmente a esse cenário?
A) CDN para conteúdo estático + Application Gateway para roteamento de URL + Azure Firewall para proteção de camada 7
B) Balanceamento de carga global com roteamento baseado em URL, terminação TLS na borda, cache integrado e WAF nativo
C) Traffic Manager para roteamento DNS + Azure CDN para aceleração + Application Gateway com WAF
D) Front Door apenas para terminação TLS e CDN para os demais requisitos, já que Front Door não suporta WAF nativo
Questão 2 — Cenário Técnico
Um engenheiro configurou o Azure Front Door para uma aplicação com dois backends: um na região East US e outro na West Europe. O roteamento está configurado como Priority. Após um teste, ele observa que 100% do tráfego está indo para East US, mesmo com a origem em West Europe apresentando latência menor para usuários europeus.
Backend Pool:
- eastus-app | Priority: 1 | Weight: 50
- westeurope-app | Priority: 2 | Weight: 50
Por que o comportamento observado está ocorrendo e o que o engenheiro deveria alterar para rotear os usuários europeus preferencialmente para West Europe?
A) O Front Door está com cache ativado, fazendo com que todas as requisições sejam servidas pela origem mais próxima do PoP de entrada. Desativar o cache resolve o problema.
B) O roteamento por Priority sempre envia tráfego para o backend de prioridade mais alta enquanto ele estiver saudável, independentemente da latência. Para rotear por proximidade geográfica, o método correto é Latency.
C) O peso (weight) está igual para ambos os backends. Aumentar o peso de westeurope-app para 100 fará com que o tráfego europeu seja direcionado corretamente.
D) O problema é que o Front Door não suporta múltiplas regiões no mesmo pool. Os backends devem ser separados em pools distintos com regras de roteamento por geolocalização.
Questão 3 — Verdadeiro ou Falso
O Azure Front Door (SKU Standard e Premium) permite associar uma única política de WAF a múltiplos perfis de Front Door simultaneamente, desde que os perfis estejam na mesma assinatura do Azure.
Questão 4 — Cenário Técnico
Uma empresa está migrando uma aplicação legada que expõe três caminhos distintos: /api/, /auth/ e /static/. O requisito é que cada caminho seja roteado para um backend diferente, com /static/ sendo servido diretamente do cache sempre que possível, e /auth/ nunca armazenado em cache. O time decidiu usar Azure Front Door Standard.
Qual abordagem de configuração atende corretamente a esses três requisitos?
A) Criar três perfis de Front Door distintos, um para cada caminho, pois Front Door não suporta múltiplas regras de roteamento em um único perfil.
B) Usar um único perfil com três route rules baseadas em padrões de caminho, associando cada rota ao seu respectivo origin group, e configurar caching como habilitado na rota /static/ e desabilitado na rota /auth/.
C) Usar um único perfil com uma regra de roteamento genérica e redirecionar o controle de cache para os próprios backends via cabeçalhos Cache-Control, já que o Front Door não permite configuração de cache por rota.
D) Criar um único origin group com os três backends e usar weighted routing para distribuir o tráfego, adicionando regras de cache global no perfil.
Questão 5 — Múltipla Escolha
Ao comparar o SKU Standard e o SKU Premium do Azure Front Door, qual é a diferença funcional mais relevante para uma organização que precisa de proteção contra ameaças gerenciadas pela Microsoft e inspeção de tráfego privado via Private Link para as origens?
A) Ambos os SKUs oferecem WAF gerenciado com regras da Microsoft e suporte a Private Link. A diferença está apenas no número máximo de domínios customizados permitidos.
B) O SKU Standard oferece WAF com regras gerenciadas pela Microsoft e Private Link. O SKU Premium é necessário apenas para ambientes com mais de 25 origens.
C) Apenas o SKU Premium oferece o conjunto de regras gerenciadas pela Microsoft (Microsoft-managed ruleset) no WAF e suporte a Private Link para conexão segura com as origens. O SKU Standard oferece WAF apenas com regras personalizadas.
D) O SKU Standard não inclui WAF em nenhuma forma. WAF é exclusivo do SKU Premium e requer uma política separada criada no Azure Firewall Manager.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O Azure Front Door é um serviço unificado que combina balanceamento de carga global na camada 7, roteamento baseado em URL, terminação TLS na borda da rede Microsoft, cache integrado para aceleração de conteúdo dinâmico e estático, e WAF nativo disponível nos SKUs Standard e Premium. A alternativa B descreve exatamente esse conjunto de capacidades em um único serviço gerenciado.
As alternativas A e C representam arquiteturas compostas por múltiplos serviços independentes, o que aumenta a complexidade operacional e não atende ao requisito de "único serviço gerenciado". A alternativa D está tecnicamente incorreta: o WAF é uma funcionalidade nativa do Front Door, não um componente externo.
Gabarito — Questão 2
Resposta: B
O método de roteamento Priority do Azure Front Door é projetado para cenários de failover, não para distribuição geográfica por latência. Enquanto o backend de maior prioridade (valor numérico menor) estiver saudável, todo o tráfego é direcionado a ele, independentemente da localização do usuário ou da latência medida.
Para rotear usuários para o backend com menor latência de rede, o método correto é Latency, que usa as medições de latência do Front Door entre seus PoPs e os backends para tomar a decisão de roteamento.
A alternativa A confunde o comportamento do cache com roteamento de origem. A alternativa C está incorreta porque o weight só é relevante no método Weighted, não no Priority. A alternativa D é falsa: Front Door suporta múltiplos backends no mesmo origin group.
Gabarito — Questão 3
Resposta: Falso
Uma política de WAF no Azure Front Door é associada a um perfil específico, e não pode ser compartilhada entre múltiplos perfis simultaneamente. Cada perfil de Front Door requer sua própria associação de política de WAF. Isso é diferente do comportamento do Azure Application Gateway, onde a política pode ser associada em diferentes escopos dentro do mesmo recurso.
Esse ponto é relevante em cenários de governança: organizações que gerenciam múltiplos perfis de Front Door precisam replicar ou referenciar políticas de WAF separadamente para cada perfil, o que impacta o planejamento de automação e conformidade.
Gabarito — Questão 4
Resposta: B
O Azure Front Door Standard suporta múltiplas route rules dentro de um único perfil, cada uma associada a um padrão de caminho e a um origin group distinto. O comportamento de cache é configurável por rota: é possível habilitar caching com TTL definido para /static/ e desabilitar explicitamente para /auth/, garantindo que credenciais e tokens nunca sejam armazenados na borda.
A alternativa A está incorreta porque múltiplas rotas em um único perfil são um recurso central do Front Door. A alternativa C está incorreta: Front Door permite controle de cache por rota nativamente, sem depender exclusivamente de cabeçalhos do backend. A alternativa D descreve um uso incorreto de weighted routing, que serve para distribuição de carga, não para segmentação por caminho.
Gabarito — Questão 5
Resposta: C
A distinção entre os SKUs Standard e Premium do Azure Front Door é direta para esse cenário. O SKU Premium é o único que inclui o Microsoft-managed ruleset no WAF, que oferece proteção atualizada e gerenciada contra as ameaças mais comuns (equivalente ao CRS gerenciado pela Microsoft). Além disso, o suporte a Private Link para conectar o Front Door a origens privadas (como App Service, Storage ou endpoints internos) é exclusivo do SKU Premium.
O SKU Standard suporta WAF, mas apenas com regras personalizadas (custom rules) definidas pelo próprio cliente. Isso significa que a organização seria responsável por criar e manter todas as regras de proteção, sem o conjunto gerenciado.
A alternativa A está incorreta porque Private Link não está disponível no Standard. A alternativa B inverte parcialmente as capacidades e usa um critério falso (número de origens) como diferenciador. A alternativa D está completamente incorreta: WAF está disponível em ambos os SKUs, com diferença no tipo de regras suportadas.