Laboratório de Troubleshooting: Identify appropriate use cases for Azure Front Door
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações reporta que usuários na região da Ásia-Pacífico estão experimentando latência elevada ao acessar uma aplicação web global. O ambiente utiliza Azure Front Door com dois backends configurados: um em East US e outro em West Europe.
As health probes estão retornando status 200 para ambos os backends. Os logs do Front Door confirmam que o tráfego originado de Tóquio está sendo roteado consistentemente para West Europe. O time informa que realizou uma atualização no certificado TLS do backend de East US há três dias, e que o SKU utilizado é o Standard.
A configuração de roteamento relevante é a seguinte:
{
"routingRules": [
{
"name": "global-route",
"routeConfiguration": {
"routeType": "Forward",
"backendPool": "primary-pool"
}
}
],
"loadBalancingSettings": {
"sampleSize": 4,
"successfulSamplesRequired": 2,
"additionalLatencyMilliseconds": 0
},
"backends": [
{ "address": "app-eastus.azurewebsites.net", "weight": 50, "priority": 1 },
{ "address": "app-westeurope.azurewebsites.net", "weight": 50, "priority": 1 }
]
}
Qual é a causa raiz do roteamento ineficiente para usuários na Ásia-Pacífico?
A) A atualização do certificado TLS em East US corrompeu a health probe desse backend, fazendo com que o Front Door o trate como degradado
B) O campo additionalLatencyMilliseconds está configurado como zero, eliminando a tolerância de latência que permitiria ao Front Door considerar o backend mais próximo geograficamente
C) Ambos os backends possuem o mesmo weight e priority, fazendo com que o Front Door distribua o tráfego por round-robin sem considerar latência
D) O SKU Standard não suporta roteamento baseado em latência; esse recurso está disponível apenas no SKU Premium
Cenário 2 — Decisão de Ação
A equipe de segurança identificou que a política WAF associada ao perfil do Azure Front Door está operando no modo Detection. Foi constatado que requisições com padrões de SQL injection estão chegando ao backend de produção sem serem bloqueadas.
A causa está confirmada: o modo Detection apenas registra as requisições suspeitas nos logs, sem bloquear o tráfego. A solução técnica é alterar o modo para Prevention.
O contexto operacional é o seguinte:
- A aplicação processa transações financeiras em tempo real
- Há uma janela de manutenção programada para daquela semana, em 48 horas
- O time de desenvolvimento reportou que algumas regras gerenciadas do conjunto Microsoft_DefaultRuleSet_2.1 estão gerando falsos positivos em funcionalidades críticas da aplicação, bloqueando operações legítimas em testes anteriores no ambiente de staging
- O time de segurança possui permissão para alterar a política WAF imediatamente
Qual é a ação correta a tomar neste momento?
A) Alterar imediatamente o modo da política WAF para Prevention, pois a segurança da aplicação supera qualquer risco de falsos positivos em produção
B) Aguardar a janela de manutenção, revisar e ajustar as regras que geram falsos positivos antes de ativar o modo Prevention
C) Criar exclusões de regras específicas para as funcionalidades que geram falsos positivos e, em seguida, ativar o modo Prevention ainda fora da janela de manutenção
D) Substituir o conjunto de regras Microsoft_DefaultRuleSet_2.1 por regras customizadas antes de alterar o modo para Prevention
Cenário 3 — Causa Raiz
Um arquiteto recebe um chamado informando que o Azure Front Door está retornando erro 503 Service Unavailable para todos os usuários de uma aplicação de e-commerce. O ambiente possui três backends configurados em regiões diferentes.
Os logs do Front Door apresentam a seguinte saída:
2026-03-15T10:42:11Z | OriginHealthStatus: Unhealthy | Backend: app-eastus | ProbeStatus: 404
2026-03-15T10:42:11Z | OriginHealthStatus: Unhealthy | Backend: app-westeurope | ProbeStatus: 404
2026-03-15T10:42:11Z | OriginHealthStatus: Unhealthy | Backend: app-brazilsouth | ProbeStatus: 404
O arquiteto verifica que os três backends respondem normalmente quando acessados diretamente pelo navegador usando seus endereços FQDN. O time de DevOps menciona que realizou um deploy na tarde anterior que incluiu uma refatoração das rotas da aplicação. A assinatura do Azure está dentro dos limites de cota e não há alertas de disponibilidade regional no painel do Azure Service Health.
Qual é a causa raiz do erro 503 retornado pelo Front Door?
A) O deploy da tarde anterior introduziu uma falha nos backends que os impede de responder ao tráfego roteado pelo Front Door, enquanto respostas diretas ainda funcionam por cache do navegador
B) O caminho configurado para as health probes do Front Door não existe mais após a refatoração das rotas da aplicação, fazendo com que todos os backends sejam marcados como não saudáveis
C) Os três backends estão sobrecarregados simultaneamente, e o Front Door interpreta timeouts de resposta como status 404 nas health probes
D) A assinatura atingiu o limite de conexões simultâneas do Front Door, e o erro 503 é gerado pelo próprio serviço antes de atingir os backends
Cenário 4 — Sequência de Diagnóstico
Um engenheiro é alertado que usuários estão recebendo conteúdo desatualizado de uma aplicação web servida pelo Azure Front Door com caching habilitado. A aplicação foi atualizada com novos preços de produtos, mas parte dos usuários ainda visualiza os valores antigos. O Front Door está configurado com SKU Premium e regras de cache ativas nas rotas de produto.
Os passos de investigação disponíveis são:
- Verificar se a operação de purge de cache foi executada após o deploy da atualização de preços
- Confirmar se os backends estão retornando os valores atualizados quando acessados diretamente
- Verificar o valor de Cache-Control e max-age configurados nas regras de roteamento do Front Door
- Confirmar se o SKU Premium está ativo e se o perfil do Front Door está associado ao endpoint correto
- Analisar os cabeçalhos de resposta recebidos pelo usuário para identificar se a resposta vem do cache (header X-Cache: HIT)
Qual é a sequência correta de investigação para esse sintoma?
A) 4 → 1 → 2 → 5 → 3
B) 2 → 5 → 3 → 1 → 4
C) 5 → 2 → 3 → 1 → 4
D) 4 → 5 → 2 → 3 → 1
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista central está no valor "additionalLatencyMilliseconds": 0. O Azure Front Door usa esse parâmetro para definir uma janela de tolerância de latência dentro da qual múltiplos backends são considerados igualmente próximos. Com o valor em zero, qualquer diferença de latência, mesmo mínima, entre os backends resulta na escolha estrita do de menor latência medido a partir do PoP que atendeu a requisição. O problema é que esse PoP pode não ser o mais próximo do usuário final, e sem tolerância configurada, backends geograficamente mais adequados podem ser preteridos por margens insignificantes.
A informação sobre a atualização do certificado TLS é irrelevante: as health probes retornam 200 para ambos os backends, descartando qualquer hipótese de degradação. Ela foi incluída propositalmente para desviar o diagnóstico para A.
O distrator C representa um equívoco comum: o mesmo weight e priority habilitam balanceamento entre backends elegíveis, mas o critério de elegibilidade já foi determinado pelo roteamento por latência antes da etapa de balanceamento.
O distrator D é factualmente incorreto: o roteamento por latência está disponível no SKU Standard.
Agir com base em A levaria o engenheiro a revogar e reemitir o certificado TLS sem necessidade, desperdiçando tempo sem resolver o problema real.
Gabarito — Cenário 2
Resposta: B
A restrição crítica do cenário é a existência comprovada de falsos positivos em funcionalidades críticas, documentados em testes de staging anteriores. Ativar o modo Prevention imediatamente, como propõe A, bloquearia operações financeiras legítimas em produção, causando impacto direto ao negócio.
A ação correta é utilizar as 48 horas disponíveis até a janela de manutenção para revisar e ajustar as regras que geram falsos positivos antes de ativar o bloqueio efetivo.
O distrator C é tecnicamente válido como abordagem, mas cria um risco operacional: criar exclusões de regras em produção fora de uma janela de manutenção, sem validação completa, pode tanto deixar lacunas de segurança quanto introduzir novos falsos positivos não previstos.
O distrator D representa uma ação desproporcional ao problema: substituir o conjunto de regras gerenciado por regras completamente customizadas exige esforço significativo, elimina a cobertura automática de vulnerabilidades emergentes fornecida pela Microsoft, e não é justificado apenas pela existência de alguns falsos positivos pontuais.
O raciocínio correto aqui é: a causa está identificada e a solução é conhecida, mas a restrição de falsos positivos documentados impõe que a ativação seja feita de forma controlada e dentro da janela planejada.
Gabarito — Cenário 3
Resposta: B
A evidência definitiva está nos logs: todos os backends retornam 404 para as health probes, mas respondem normalmente quando acessados diretamente pelo navegador. Esse padrão específico indica que o problema não está nos backends em si, mas no caminho que o Front Door está consultando para verificar a saúde dos backends.
Após a refatoração das rotas no deploy da tarde anterior, o endpoint configurado nas health probes (por exemplo, /health ou /status) provavelmente foi movido ou removido. O Front Door interpreta o 404 como backend não saudável e, com todos os backends marcados como Unhealthy, retorna 503 para os usuários.
A informação sobre a assinatura dentro dos limites de cota e o Service Health sem alertas é irrelevante e foi incluída para desviar o diagnóstico para D.
O distrator A é o mais perigoso: a hipótese de cache do navegador explicando respostas diretas parece plausível superficialmente, mas é refutada pelo fato de o arquiteto ter acessado os backends diretamente pelo FQDN, o que normalmente não usa o mesmo cache de uma requisição via Front Door.
Agir com base em A levaria o time a investigar os backends exaustivamente sem encontrar falha, perdendo tempo enquanto o problema real, o caminho das health probes, permanece ativo.
Gabarito — Cenário 4
Resposta: B
A sequência correta é: 2 → 5 → 3 → 1 → 4.
O raciocínio diagnóstico progressivo exige partir do ponto mais próximo do sintoma e eliminar hipóteses antes de escalar a investigação:
| Passo | Ação | Justificativa |
|---|---|---|
| 2 | Confirmar se o backend retorna valores atualizados | Verificar se o problema existe na origem antes de investigar o cache |
| 5 | Analisar o header X-Cache na resposta do usuário | Confirmar se o conteúdo vem do cache do Front Door ou da origem |
| 3 | Verificar regras de cache e max-age | Identificar se o TTL configurado está mantendo o conteúdo antigo |
| 1 | Verificar se o purge foi executado | Confirmar se a invalidação de cache foi ou não realizada após o deploy |
| 4 | Confirmar SKU e associação do perfil | Verificar infraestrutura somente se os passos anteriores não identificarem a causa |
O distrator A começa verificando o SKU e o perfil, que são elementos de infraestrutura estáveis e improváveis como causa de um problema que surgiu após um deploy específico.
O distrator D também começa pelo SKU, e apesar de verificar o header X-Cache em segundo lugar, adia a verificação do backend para o terceiro passo, investigando configuração antes de confirmar se a origem está correta.
Começar pelo backend (passo 2) é o princípio correto: se a origem ainda retorna o valor antigo, o problema não está no cache e toda a investigação de TTL e purge seria tempo perdido.
Árvore de Troubleshooting: Identify appropriate use cases for Azure Front Door
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada da investigação) |
| Azul médio | Pergunta de diagnóstico (decisão binária ou observável) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para utilizar esta árvore diante de um problema real, comece pelo nó raiz identificando o tipo de sintoma observado: backends não saudáveis, roteamento ineficiente, conteúdo desatualizado ou tráfego malicioso atingindo os backends. Siga as perguntas de diagnóstico respondendo sim ou não com base no que você pode verificar diretamente no portal do Azure, nos logs do Front Door ou nos cabeçalhos de resposta HTTP. Cada caminho leva a uma causa nomeada e a uma ação específica, evitando que hipóteses plausíveis mas incorretas consumam tempo de investigação.