Laboratório de Troubleshooting: Map requirements to features and capabilities of Azure Front Door
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma aplicação web global está configurada no Azure Front Door Premium com dois origin groups: prod-eastus e prod-westeu. O time de operações reporta que usuários nos Estados Unidos estão recebendo respostas com latência consistentemente acima de 400ms, enquanto usuários na Europa relatam desempenho normal. O método de roteamento configurado é Latency.
Durante a investigação, o engenheiro coleta as seguintes informações:
Origin Group: prod-eastus
Origin: app-eastus.azurewebsites.net
Health Probe Protocol: HTTP
Health Probe Path: /healthz
Health Probe Interval: 30s
Status reportado pelo Front Door: Degraded
Origin Group: prod-westeu
Origin: app-westeu.azurewebsites.net
Health Probe Protocol: HTTP
Health Probe Path: /healthz
Health Probe Interval: 30s
Status reportado pelo Front Door: Healthy
O engenheiro também verifica que o endpoint /healthz no servidor app-eastus responde com HTTP 200 quando acessado diretamente via curl a partir de uma VM na mesma região. O certificado TLS do domínio customizado foi renovado há dois dias e está válido. O WAF está habilitado no perfil com uma política no modo Detection.
Qual é a causa raiz da latência elevada para usuários nos EUA?
A) O certificado TLS foi renovado recentemente e o Front Door ainda está propagando a nova cadeia de certificados para todos os PoPs, causando lentidão temporária nas conexões de usuários americanos.
B) A política de WAF em modo Detection está inspecionando e logando todas as requisições sem bloqueá-las, o que adiciona overhead de processamento suficiente para elevar a latência percebida.
C) O origin app-eastus está com status Degraded no Front Door, fazendo com que o tráfego dos usuários americanos seja redirecionado para prod-westeu na Europa, o que aumenta a latência para esse grupo de usuários.
D) O health probe está configurado com intervalo de 30 segundos, o que é muito longo. O Front Door não tem informação atualizada do estado do backend e está tomando decisões de roteamento incorretas.
Cenário 2 — Decisão de Ação
A equipe de segurança identificou que a política de WAF associada ao perfil de Azure Front Door Premium está em modo Detection em produção. A causa foi confirmada: um engenheiro alterou o modo da política de Prevention para Detection durante uma janela de manutenção há três semanas para investigar falsos positivos, e esqueceu de reverter. Desde então, requisições maliciosas estão sendo logadas mas não bloqueadas.
O contexto atual é:
- A aplicação está em produção com tráfego ativo de aproximadamente 8.000 requisições por minuto
- A janela de manutenção mais próxima está agendada para daqui a 72 horas
- A alteração do modo da política de WAF não requer reinicialização do Front Door nem causa interrupção de tráfego
- O time de segurança possui permissão de Contributor no recurso da política de WAF
- Os logs mostram que nos últimos 3 dias houve 47 tentativas de SQL Injection que foram apenas logadas
Qual é a ação correta a tomar neste momento?
A) Aguardar a janela de manutenção em 72 horas para reverter o modo da política para Prevention, garantindo que a mudança seja feita de forma controlada e documentada.
B) Reverter imediatamente o modo da política de WAF de Detection para Prevention, pois a alteração não causa interrupção de tráfego e a exposição ativa a ataques não justifica aguardar a janela de manutenção.
C) Criar uma nova política de WAF em modo Prevention e associá-la ao perfil de Front Door em substituição à atual, preservando a política antiga em Detection para auditoria.
D) Adicionar regras personalizadas de bloqueio para os padrões de SQL Injection identificados nos logs e manter o modo Detection até a janela de manutenção, reduzindo o risco sem alterar o modo global.
Cenário 3 — Causa Raiz
Um time de desenvolvimento publicou uma nova versão de uma API gerenciada pelo Azure Front Door Standard. Após a publicação, os clientes que consomem o endpoint /api/v2/orders passam a receber respostas desatualizadas, com dados que refletem o estado da aplicação de horas atrás. O endpoint /api/v2/products funciona corretamente e retorna dados em tempo real.
O engenheiro verifica a configuração do perfil:
Route: api-v2-route
Patterns to match: /api/v2/*
Origin Group: orders-backend
Caching: Enabled
Query string caching behavior: Ignore query strings
Cache duration: 4 hours
Compression: Enabled
Backend response headers observados em /api/v2/orders:
Cache-Control: no-store
Content-Type: application/json
X-Request-ID: 7f3a2b1c
Vary: Accept-Encoding
O endpoint /api/v2/products está em uma rota separada com caching desabilitado. O origin group orders-backend está saudável. A aplicação foi deployada com sucesso e responde corretamente quando acessada diretamente pela URL do backend.
Qual é a causa raiz do comportamento observado?
A) O header Vary: Accept-Encoding na resposta do backend está causando conflito com o mecanismo de cache do Front Door, fazendo com que versões antigas da resposta sejam entregues para clientes com diferentes encodings aceitos.
B) O caching está habilitado na rota /api/v2/* com duração de 4 horas. Mesmo que o backend retorne Cache-Control: no-store, o Front Door armazenou a resposta da versão anterior antes do deploy e está servindo esse conteúdo em cache até o TTL expirar.
C) O comportamento de query string configurado como Ignore query strings está fazendo com que requisições com parâmetros diferentes sejam tratadas como o mesmo objeto de cache, retornando sempre a primeira resposta armazenada.
D) O novo deploy alterou o X-Request-ID das respostas. O Front Door usa esse header como chave de cache, e a divergência entre o valor antigo e o novo está causando inconsistência nas respostas entregues.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte alerta às 14h32:
"Usuários reportam erro HTTP 503 ao acessar a aplicação via Azure Front Door. O problema afeta todas as regiões."
O engenheiro tem acesso ao portal do Azure, aos logs do Front Door via Azure Monitor, ao backend da aplicação e às configurações do perfil. Os seguintes passos de investigação estão disponíveis, mas fora de ordem:
- Verificar o status de saúde dos origins no origin group dentro do perfil do Front Door
- Acessar os logs de requisições no Azure Monitor para identificar o código de erro retornado pelo origin
- Confirmar se o Front Door está retornando o 503 diretamente (sem chegar ao backend) ou se o erro vem do próprio origin
- Verificar se há alguma regra de roteamento mal configurada ou rota ausente que poderia estar causando o erro antes de chegar ao origin group
- Acessar diretamente a URL do backend (fora do Front Door) para verificar se o serviço responde corretamente
Qual é a sequência correta de investigação para esse sintoma?
A) 1 → 5 → 2 → 4 → 3
B) 3 → 1 → 5 → 4 → 2
C) 4 → 1 → 3 → 2 → 5
D) 3 → 4 → 1 → 5 → 2
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
A pista determinante no enunciado é o status Degraded reportado pelo Front Door para o origin app-eastus. Quando um origin está degradado, o Front Door o considera menos preferível ou indisponível para roteamento, mesmo que o método configurado seja Latency. O tráfego dos usuários americanos, que normalmente seria roteado para o backend mais próximo (app-eastus), passa a ser enviado para prod-westeu na Europa, o que explica a latência elevada.
O detalhe de que o endpoint /healthz responde HTTP 200 quando acessado diretamente via curl é a informação irrelevante incluída propositalmente. Esse acesso direto contorna o mecanismo de health probe do Front Door, que pode estar enfrentando um problema diferente, como um firewall bloqueando requisições originadas dos IPs dos PoPs do Front Door, ou um redirect HTTP que o probe não segue corretamente.
Os distratores A e B são tecnicamente plausíveis em outros contextos, mas não explicam por que o problema é geograficamente restrito aos usuários americanos. O distrator D confunde o intervalo do probe (que influencia a frequência de atualização do status) com a causa do roteamento incorreto; o Front Door já tem uma leitura de status que mostra Degraded, independentemente do intervalo.
O erro mais perigoso seria agir com base no distrator D e aumentar a frequência do probe sem investigar por que o origin está sendo marcado como Degraded, o que não resolveria o problema real.
Gabarito — Cenário 2
Resposta: B
A causa já está declarada no enunciado: a política está em modo Detection quando deveria estar em Prevention. O raciocínio correto aqui depende da análise das restrições, não da identificação da causa.
As restrições críticas são: a alteração do modo não causa interrupção de tráfego, o time tem permissão adequada (Contributor no recurso), e há evidência ativa de ataques sendo apenas logados. Nenhuma dessas condições justifica aguardar 72 horas. A janela de manutenção existe para mudanças que causam risco de interrupção ou que exigem coordenação ampla; reverter um modo de política de WAF não se enquadra nesse critério.
A alternativa A é o distrator mais perigoso: ela soa como boa prática de governança, mas ignora que a exposição ativa a SQL Injection durante 72 horas adicionais representa um risco de segurança concreto e desnecessário quando a correção é de baixo risco e pode ser feita imediatamente.
A alternativa C cria trabalho desnecessário e risco de inconsistência de configuração. A alternativa D é uma solução parcial que não endereça o problema estrutural, que é o modo incorreto da política.
Gabarito — Cenário 3
Resposta: B
O comportamento descrito, respostas desatualizadas após um deploy, com o backend respondendo corretamente quando acessado diretamente, é o sintoma clássico de cache não invalidado na borda. A configuração da rota confirma: caching habilitado com duração de 4 horas na rota /api/v2/*.
O ponto técnico relevante aqui é que o Azure Front Door pode respeitar ou sobrescrever o header Cache-Control: no-store dependendo da configuração da rota. Quando o caching está habilitado explicitamente na rota com um TTL definido, o Front Door pode armazenar a resposta mesmo que o backend envie Cache-Control: no-store, pois a configuração da rota tem precedência sobre os headers de resposta do origin em determinados cenários. O cache armazenado antes do deploy continuará sendo servido até que o TTL de 4 horas expire ou que o cache seja purgado manualmente.
A alternativa A é o distrator projetado para atrair quem foca em detalhes técnicos plausíveis mas irrelevantes para o sintoma. O header Vary: Accept-Encoding é padrão para compressão e não causa o comportamento descrito. A alternativa C descreve um problema real de configuração de cache, mas que causaria respostas idênticas para queries diferentes, não respostas desatualizadas de forma generalizada. A alternativa D é incorreta: o Front Door não usa X-Request-ID como chave de cache.
Gabarito — Cenário 4
Resposta: D
A sequência correta é: 3 → 4 → 1 → 5 → 2
O raciocínio diagnóstico progressivo parte do sintoma mais externo para as causas mais internas:
O passo 3 deve ser o primeiro porque determina onde o erro está sendo gerado: no próprio Front Door (problema de configuração, rota, ou saúde dos origins) ou no backend. Essa distinção orienta toda a investigação subsequente.
O passo 4 vem em seguida porque erros de configuração de rota são verificáveis rapidamente no plano de controle e podem explicar um 503 sem que o tráfego chegue ao origin group.
O passo 1 verifica o estado dos origins, que é a causa mais comum de 503 quando as rotas estão corretas.
O passo 5 isola se o problema está no Front Door ou no backend, acessando o backend diretamente.
O passo 2, análise detalhada de logs, é o último passo porque é o mais demorado e deve ser usado para confirmar ou detalhar uma hipótese já formada, não como ponto de partida.
A alternativa B parece lógica, mas começa com o passo 3 e salta para verificar o backend (passo 5) antes de verificar configurações de rota (passo 4) e saúde de origins (passo 1), pulando etapas mais rápidas que poderiam encerrar a investigação antes.
Árvore de Troubleshooting: Map requirements to features and capabilities of Azure Front Door
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou por estado) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, identifique o sintoma observado (erro 503, latência elevada, conteúdo desatualizado ou ausência de bloqueio de ameaças) e localize o nó de entrada correspondente na raiz. A partir daí, responda cada pergunta diagnóstica com base no que é observável no portal do Azure ou nos logs do Azure Monitor, sem presumir a causa. Cada ramificação leva progressivamente a uma causa identificada (vermelho) que orienta diretamente a ação corretiva (verde). Os nós de validação (laranja) indicam pontos onde é necessário coletar evidência antes de confirmar a hipótese.