Laboratório de Troubleshooting: Configure caching
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma aplicação web global é distribuída via Azure Front Door com caching habilitado. O time de operações abre um chamado relatando que usuários na Europa estão recebendo respostas com latência equivalente à da origem, como se o cache não estivesse sendo utilizado. Usuários na América do Norte não relatam o mesmo problema.
O engenheiro responsável coleta as seguintes informações:
GET /products/list HTTP/1.1
Host: app.contoso.com
Accept-Encoding: gzip
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
Resposta observada nos logs do Front Door para requisições europeias:
X-Cache: MISS
X-Azure-Ref: 0ABC123...
Cache-Control: no-cache
O perfil do Front Door foi criado há dois dias. O time confirma que não houve alteração de configuração nas últimas 24 horas. O certificado TLS do endpoint está válido e a origem responde com HTTP 200 em todos os casos.
Qual é a causa raiz do comportamento observado?
A) O certificado TLS recém-configurado ainda não foi propagado para as POPs europeias, causando fallback para a origem
B) A resposta da origem inclui o cabeçalho Cache-Control: no-cache, impedindo o armazenamento nas POPs do Front Door
C) O Front Door ainda está em período de aquecimento de cache para as POPs europeias, e o comportamento normalizará automaticamente
D) O cabeçalho Authorization na requisição faz com que o Front Door classifique a requisição como não cacheável por padrão
Cenário 2 — Decisão de Ação
A causa de um incidente foi identificada: o Azure CDN está entregando uma versão desatualizada de um arquivo JavaScript crítico (/static/app.v2.js) após uma atualização de emergência no sistema de pagamentos. O arquivo correto já está disponível na origem. O ambiente é de produção com alto volume de transações em andamento.
A equipe possui as seguintes permissões e restrições:
| Restrição | Detalhe |
|---|---|
| Janela de manutenção | Não disponível nas próximas 4 horas |
| Permissão de purge no CDN | Disponível para o engenheiro responsável |
| Acesso à origem | Disponível |
| Alteração de configuração do perfil CDN | Requer aprovação de change management |
Qual é a ação correta a tomar neste momento?
A) Alterar o Cache-Control: max-age na origem para zero e aguardar a expiração natural do cache existente nas POPs
B) Executar um purge direcionado ao path /static/app.v2.js no perfil CDN para forçar a revalidação imediata
C) Desabilitar o caching no perfil CDN para o endpoint afetado até que a janela de manutenção esteja disponível
D) Redirecionar o tráfego diretamente para a origem alterando as regras de roteamento do CDN
Cenário 3 — Causa Raiz
Um time de plataforma configura o Azure Front Door para servir uma API de relatórios financeiros. O caching está habilitado com cacheDuration de 6 horas. Após uma semana em produção, o time de segurança identifica que relatórios de clientes diferentes estão sendo entregues de forma cruzada em aproximadamente 3% das requisições.
Trecho da configuração aplicada:
{
"cacheConfiguration": {
"queryStringCachingBehavior": "IgnoreQueryString",
"dynamicCompression": "Disabled",
"cacheDuration": "0.06:00:00"
}
}
Exemplo de requisições que geram o problema:
GET /api/reports?year=2024 HTTP/1.1
X-Customer-ID: 1001
Authorization: Bearer token_cliente_1001
GET /api/reports?year=2024 HTTP/1.1
X-Customer-ID: 1002
Authorization: Bearer token_cliente_1002
O time informa que a API foi migrada de um ambiente on-premises onde não havia camada de cache. O TLS está configurado corretamente e a origem retorna HTTP 200 com Content-Type: application/json para todas as requisições.
Qual é a causa raiz do vazamento de dados entre clientes?
A) O cacheDuration de 6 horas é excessivo para dados financeiros, fazendo com que tokens expirados continuem sendo aceitos pelo cache
B) A desativação de dynamicCompression força o Front Door a tratar todas as respostas como estáticas, ignorando os cabeçalhos de autenticação
C) O comportamento IgnoreQueryString combinado com a ausência dos cabeçalhos X-Customer-ID e Authorization na chave de cache faz com que requisições de clientes diferentes compartilhem a mesma entrada em cache
D) A API retorna Content-Type: application/json, e o Front Door interpreta esse tipo de conteúdo como dinâmico, causando instabilidade na chave de cache
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: usuários de uma aplicação distribuída via Azure CDN Standard da Microsoft estão recebendo conteúdo HTML desatualizado após um redeploy. O CDN está configurado com TTL de 1 hora. O redeploy ocorreu há 40 minutos.
Os passos de investigação disponíveis são:
P1 — Verificar se a origem já está servindo o conteúdo atualizado acessando-a diretamente pelo IP
P2 — Executar um purge do conteúdo afetado no perfil CDN
P3 — Verificar os cabeçalhos Cache-Control e Expires retornados pela origem na resposta atual
P4 — Confirmar se o TTL configurado no perfil CDN está em modo Override ou Honor origin
P5 — Analisar os logs do CDN para verificar se as requisições estão resultando em HIT ou MISS
Qual é a sequência correta de investigação?
A) P5, P1, P3, P4, P2
B) P1, P5, P4, P3, P2
C) P3, P4, P1, P5, P2
D) P2, P1, P3, P4, P5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista definitiva está nos próprios logs coletados pelo engenheiro: a resposta inclui Cache-Control: no-cache e o status de cache é MISS. O Azure Front Door respeita a diretiva no-cache enviada pela origem quando o perfil está configurado no modo Honor origin. Isso impede o armazenamento da resposta nas POPs, fazendo com que cada requisição seja encaminhada à origem independentemente da região.
A informação irrelevante no cenário é o certificado TLS, confirmado como válido, e o tempo de criação do perfil. Ambos não têm relação com o comportamento de cache descrito.
A alternativa A é tecnicamente implausível como causa: a propagação de certificados TLS é independente do comportamento de cache e não causaria MISS sistemático. A alternativa C é o distrator mais perigoso: o conceito de "aquecimento de cache" existe, mas não explica por que o cabeçalho Cache-Control: no-cache está presente na resposta. A alternativa D é parcialmente plausível, pois o Front Door pode não cachear requisições com Authorization, mas o cabeçalho presente na resposta da origem é a causa direta confirmada pelos logs.
Agir com base na alternativa C seria o erro mais custoso: o engenheiro aguardaria uma normalização que nunca ocorreria, pois a causa está na origem, não no tempo de aquecimento das POPs.
Gabarito — Cenário 2
Resposta: B
O purge direcionado ao path específico é a única ação que atende simultaneamente a todas as restrições do cenário: não requer janela de manutenção, não exige aprovação de change management, não afeta o restante do tráfego em produção e produz efeito imediato.
A alternativa A falha porque alterar o max-age na origem não remove o conteúdo já armazenado nas POPs. O arquivo desatualizado continuaria sendo entregue até a expiração natural, o que poderia levar até o TTL completo. A alternativa C exige alteração de configuração do perfil, o que está explicitamente bloqueado por change management. A alternativa D também exige alteração de configuração de roteamento, sujeita à mesma restrição. Ambas são ações válidas em outros contextos, mas inaplicáveis dado o conjunto de restrições apresentadas.
Gabarito — Cenário 3
Resposta: C
A causa raiz é a combinação de dois fatores: o comportamento IgnoreQueryString elimina a query string da chave de cache, e os cabeçalhos X-Customer-ID e Authorization não são incluídos na chave de cache por padrão. Como resultado, duas requisições de clientes diferentes para o mesmo path com a mesma query string produzem a mesma chave de cache, e o Front Door entrega a resposta do primeiro cliente ao segundo.
A informação irrelevante no cenário é a migração do ambiente on-premises. Esse detalhe contextualiza a ausência de experiência prévia com cache, mas não é uma causa técnica do problema.
A alternativa A confunde TTL com segurança de tokens: o cacheDuration controla por quanto tempo uma entrada permanece em cache, não se tokens são revalidados. A alternativa B é tecnicamente incorreta: dynamicCompression afeta apenas a compressão do payload, sem qualquer efeito sobre a lógica de chave de cache. A alternativa D é um distrator sofisticado: o Front Door não determina a estratégia de cache pelo Content-Type da resposta, mas sim pelos cabeçalhos de controle de cache e pela configuração do perfil.
O impacto real de não corrigir isso em um ambiente financeiro vai além do SLA técnico: representa uma violação de privacidade de dados que pode ter implicações regulatórias.
Gabarito — Cenário 4
Resposta: B
A sequência correta segue a lógica de diagnóstico progressivo: confirmar primeiro que o problema existe na camada de cache (não na origem), entender o comportamento atual do cache, entender por que o cache está se comportando assim, e só então agir.
P1 confirma que a origem já tem o conteúdo correto, isolando o problema na camada CDN. P5 confirma que as requisições estão resultando em HIT, ou seja, o conteúdo cacheado está sendo entregue em vez do conteúdo da origem. P4 identifica se o TTL do perfil está sobrepondo ou respeitando os cabeçalhos da origem, o que determina se o comportamento é esperado ou uma misconfiguracao. P3 verifica o que a origem está enviando agora como instrução de cache, informação necessária para decidir a ação corretiva. P2 é a ação corretiva final, executada apenas após o diagnóstico completo.
A alternativa D é o erro mais comum sob pressão: executar o purge imediatamente sem confirmar que a origem já está atualizada resultaria em revalidação que ainda retornaria conteúdo desatualizado se P1 não tivesse sido verificado antes. A alternativa A altera a ordem dos passos de validação de uma forma que pode levar a conclusões incorretas sobre onde está a causa.
Árvore de Troubleshooting: Configure caching
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação intermediária ou redirecionamento |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado. A cada nó de pergunta, responda com base no que você pode verificar diretamente: logs do CDN, cabeçalhos HTTP da origem, configuração do perfil. Siga o caminho correspondente à sua resposta até alcançar um nó de causa identificada, depois avance para a ação recomendada associada. Se o problema persistir após a ação, retorne ao nó de validação mais próximo e reavalie a hipótese.