Laboratório Técnico: Configure traffic acceleration
Questões
Questão 1 — Múltipla Escolha
Uma empresa global possui usuários distribuídos na Europa, Ásia e América do Norte que acessam uma aplicação hospedada em uma única região do Azure. O time de rede precisa reduzir a latência para todos os usuários sem migrar a aplicação para múltiplas regiões.
Qual serviço do Azure atende diretamente a esse requisito ao rotear o tráfego pelo backbone da Microsoft até o ponto de presença mais próximo do usuário?
A) Azure Load Balancer Standard com regras de balanceamento global
B) Azure Front Door
C) Azure Traffic Manager com método de roteamento por desempenho
D) Azure Application Gateway com WAF habilitado
Questão 2 — Cenário Técnico
Um arquiteto configurou o Azure Front Door para acelerar o acesso a uma API hospedada no Azure App Service. Após a implantação, usuários relatam que respostas de API que raramente mudam estão sendo entregues com latência elevada, sem aproveitamento de cache.
A configuração de origem está correta e a rota está ativa. O comportamento observado é:
Cache-Control: no-store
O cabeçalho acima está presente nas respostas da origem.
Qual é a causa raiz do problema?
A) O Front Door requer que o cache seja habilitado manualmente no perfil por meio de uma política de cache explícita
B) A diretiva no-store instrui o Front Door a não armazenar nem reutilizar a resposta em cache, respeitando a semântica HTTP
C) O SKU Standard do Front Door não suporta cache de respostas de API; é necessário o SKU Premium
D) O cache do Front Door só funciona para conteúdo estático servido por Storage Account, não por App Service
Questão 3 — Verdadeiro ou Falso
O Azure Traffic Manager opera na camada DNS e, por isso, não inspeciona nem manipula o tráfego HTTP/HTTPS dos usuários finais. Como consequência, ele não pode ser usado como mecanismo de aceleração de tráfego no sentido de reduzir latência de transferência de dados, mas apenas para direcionar o usuário ao endpoint mais adequado antes do estabelecimento da conexão.
A afirmação acima é verdadeira ou falsa?
Questão 4 — Cenário Técnico
Um engenheiro precisa configurar aceleração de tráfego para uma aplicação web com os seguintes requisitos:
- Proteção contra ataques DDoS e injeção de SQL na borda
- Cache de conteúdo estático nos pontos de presença globais
- Roteamento baseado em URL (path-based routing)
- Suporte a origens múltiplas com failover automático
O engenheiro está avaliando entre Azure Front Door e Azure Application Gateway. Ele decide usar o Application Gateway para atender a todos esses requisitos globalmente.
Qual é o erro fundamental nessa decisão?
A) O Application Gateway não suporta WAF; essa funcionalidade está disponível apenas no Front Door
B) O Application Gateway é um serviço regional e não oferece pontos de presença globais nem cache distribuído na borda
C) O Application Gateway não suporta roteamento baseado em URL, sendo necessário usar o Traffic Manager para isso
D) O Application Gateway requer que todas as origens estejam na mesma rede virtual, impedindo failover entre regiões
Questão 5 — Múltipla Escolha
Ao configurar o Azure Front Door com origens múltiplas em um grupo de origem, o administrador define os seguintes pesos:
| Origem | Peso |
|---|---|
| Origem A | 50 |
| Origem B | 25 |
| Origem C | 25 |
Qual é o comportamento esperado do Front Door com essa configuração, assumindo que todas as origens estão saudáveis?
A) O Front Door roteia 100% do tráfego para a Origem A até que ela falhe, usando B e C como failover
B) O Front Door distribui o tráfego proporcionalmente aos pesos, enviando aproximadamente 50% para A, 25% para B e 25% para C
C) O Front Door ignora pesos quando há mais de duas origens e distribui o tráfego de forma igualitária
D) O peso determina a prioridade de failover, não a distribuição de tráfego em condição normal
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O Azure Front Door roteia o tráfego de entrada pelo backbone privado global da Microsoft até o ponto de presença (PoP) mais próximo do usuário, reduzindo o número de saltos pela internet pública. Isso constitui aceleração de tráfego real, independentemente de a origem estar em uma única região.
O Traffic Manager (alternativa C) também usa o método de roteamento por desempenho para direcionar o usuário ao endpoint mais rápido, mas opera apenas na camada DNS: ele não mantém a conexão no backbone da Microsoft após a resolução. O usuário estabelece a conexão diretamente com a origem via internet pública, sem aceleração de transporte.
O Load Balancer Standard opera na camada 4 e é estritamente regional. O Application Gateway também é regional e não possui PoPs globais.
Gabarito — Questão 2
Resposta: B
O Azure Front Door respeita as diretivas de controle de cache HTTP da origem. A diretiva no-store instrui qualquer intermediário, incluindo o Front Door, a não armazenar a resposta em nenhum storage persistente ou temporário. Portanto, o comportamento observado é correto e esperado: o Front Door está funcionando conforme a especificação HTTP.
A correção deve ser feita na origem, alterando o cabeçalho para Cache-Control: max-age=N ou public, conforme a política de cache desejada.
A alternativa A está incorreta porque o cache no Front Door pode ser habilitado por regra de rota, mas essa configuração não sobrescreve uma diretiva no-store da origem. A alternativa C é falsa: ambos os SKUs suportam cache. A alternativa D é falsa: o Front Door faz cache de respostas de qualquer origem HTTP válida, não apenas Storage Account.
Gabarito — Questão 3
Verdadeiro
O Traffic Manager opera exclusivamente na camada DNS. Quando um cliente resolve o nome DNS da aplicação, o Traffic Manager retorna o endereço IP do endpoint mais adequado segundo o método de roteamento configurado (desempenho, geográfico, ponderado, etc.). A partir desse momento, o tráfego de dados flui diretamente entre o cliente e o endpoint, sem passar pelo Traffic Manager e sem qualquer benefício de backbone privado ou PoP intermediário.
Esse ponto é fundamental para distinguir Traffic Manager de Front Door: o Traffic Manager otimiza a escolha do endpoint antes da conexão, enquanto o Front Door otimiza o transporte da conexão após iniciada, mantendo-a no backbone da Microsoft até a origem.
Gabarito — Questão 4
Resposta: B
O erro fundamental é tratar o Application Gateway como solução global. Ele é um serviço regional: é implantado em uma única região do Azure e serve usuários por meio da internet pública sem PoPs distribuídos. Portanto, ele não oferece aceleração de tráfego global nem cache na borda próximo ao usuário.
Os demais requisitos (WAF, roteamento por URL, múltiplas origens com failover) são suportados pelo Application Gateway, mas apenas no escopo regional. Para os requisitos descritos em escala global, o Azure Front Door é o serviço correto, pois combina WAF de borda, cache global, roteamento por URL e failover entre origens em um único serviço distribuído.
As alternativas A e C descrevem limitações que não existem. A alternativa D descreve uma restrição inexistente sobre redes virtuais.
Gabarito — Questão 5
Resposta: B
No grupo de origem do Azure Front Door, o peso controla a distribuição proporcional do tráfego entre origens saudáveis, não a prioridade de failover. Com os pesos 50, 25 e 25, o Front Door distribuirá aproximadamente metade das requisições para a Origem A e um quarto para cada uma das demais.
O failover é controlado pelo campo prioridade, não pelo peso. Origens com prioridade mais alta recebem tráfego enquanto estiverem saudáveis; origens de prioridade inferior funcionam como fallback. Confundir peso com prioridade é um equívoco comum que leva a configurações de alta disponibilidade incorretas, onde o administrador acredita ter failover configurado, mas na prática está apenas distribuindo carga.