Pular para o conteúdo principal

Laboratório Técnico: Identify appropriate use cases for Azure Front Door

Questões

Questão 1 — Múltipla Escolha

Uma empresa global de e-commerce hospeda sua aplicação web em três regiões do Azure: East US, West Europe e Southeast Asia. O time de infraestrutura precisa garantir que usuários sejam roteados automaticamente para a região com menor latência, e que, em caso de falha de uma região, o tráfego seja redirecionado sem intervenção manual.

Qual característica do Azure Front Door atende diretamente a esse requisito?

A) Priority routing com health probes configurados por região
B) Latency-based routing combinado com failover automático via health probes
C) Traffic Manager com perfil de desempenho e monitoramento de endpoints
D) Application Gateway com múltiplos backends em zonas de disponibilidade distintas


Questão 2 — Cenário Técnico

Um arquiteto está avaliando onde aplicar proteção contra ataques de injeção SQL e XSS para uma aplicação web exposta publicamente. A aplicação possui backends em duas regiões distintas e recebe tráfego de usuários globais.

Considere a configuração abaixo:

{
"frontDoorProfile": {
"sku": "Premium_AzureFrontDoor",
"securityPolicy": {
"wafPolicy": {
"mode": "Prevention",
"managedRuleSets": ["Microsoft_DefaultRuleSet_2.1"]
}
}
}
}

Qual afirmação descreve corretamente o comportamento dessa configuração?

A) O WAF inspeciona e bloqueia requisições maliciosas antes que elas alcancem qualquer backend, atuando na borda da rede global
B) O WAF é aplicado apenas ao backend primário; o backend secundário requer uma política WAF separada
C) A proteção contra SQL injection e XSS só está disponível no SKU Standard, pois o Premium é voltado para DDoS Layer 7
D) O WAF do Front Door opera no modelo de assinatura regional, sendo necessário replicar a política em cada região de backend


Questão 3 — Verdadeiro ou Falso

O Azure Front Door pode ser utilizado como solução de balanceamento de carga e aceleração de conteúdo para aplicações baseadas exclusivamente em protocolos não-HTTP, como MQTT ou FTP, desde que os backends estejam expostos publicamente.

Verdadeiro ou Falso?


Questão 4 — Cenário Técnico

Uma empresa de mídia está migrando sua plataforma de streaming para o Azure. Os arquivos de vídeo são grandes e acessados repetidamente por usuários em diferentes países. O time deseja reduzir a carga nos servidores de origem e melhorar o tempo de carregamento para usuários geograficamente dispersos, sem abrir mão de controle sobre cabeçalhos de cache.

O arquiteto propõe usar o Azure Front Door com caching habilitado nas regras de roteamento.

Qual comportamento o arquiteto deve considerar ao avaliar essa abordagem?

A) O Front Door armazena em cache conteúdo estático nos pontos de presença (PoPs) globais, servindo requisições subsequentes sem atingir a origem, desde que as regras de cache permitam
B) O caching do Front Door é aplicado apenas a respostas com status 200, e arquivos acima de 1 GB são automaticamente excluídos do cache independente da configuração
C) O Front Door delega o controle de cache integralmente ao CDN da origem; não é possível definir regras de cache independentes no próprio Front Door
D) O caching só está disponível para rotas configuradas com o protocolo HTTPS; rotas HTTP são sempre encaminhadas diretamente para a origem


Questão 5 — Múltipla Escolha

Um time de engenharia precisa decidir entre Azure Front Door e Azure Application Gateway para um novo projeto. A aplicação é um portal interno, acessado apenas por funcionários dentro de uma rede virtual corporativa, sem exposição à internet.

Qual é a conclusão técnica mais adequada para esse cenário?

A) Azure Front Door é a escolha correta, pois suporta integração com redes virtuais via Private Link em todos os SKUs
B) Azure Application Gateway é mais adequado, pois opera dentro de uma rede virtual e serve cenários de balanceamento regional interno
C) Ambas as soluções são equivalentes para esse caso, sendo a escolha baseada apenas em custo
D) Azure Front Door deve ser preferido por oferecer WAF gerenciado, independentemente do escopo de acesso da aplicação


Gabarito e Explicações

Gabarito — Questão 1

Resposta: B

O Azure Front Door oferece nativamente o método de roteamento baseado em latência, que direciona cada usuário ao backend com menor tempo de resposta medido a partir do PoP mais próximo. Os health probes monitoram continuamente a disponibilidade de cada backend e, quando uma região falha, o Front Door remove o endpoint da rotação automaticamente, sem intervenção manual.

O principal equívoco dos distratores está em confundir ferramentas:

  • A descreve priority routing, que é adequado para failover por prioridade fixa, não para otimização contínua de latência.
  • C descreve o Azure Traffic Manager, que opera na camada de DNS e não oferece aceleração de conteúdo nem proxy de camada 7.
  • D descreve o Application Gateway, que é regional por natureza e não resolve o problema de distribuição global.

Escolher Traffic Manager em vez do Front Door para esse cenário resultaria em failover mais lento (dependente de TTL de DNS) e ausência de aceleração de conteúdo na borda.


Gabarito — Questão 2

Resposta: A

O WAF do Azure Front Door opera nos pontos de presença globais, inspecionando e filtrando o tráfego antes que ele seja encaminhado para qualquer backend. Isso significa que requisições com padrões de SQL injection ou XSS são bloqueadas na borda da rede, independentemente do número de backends configurados. A política WAF é definida uma vez no perfil do Front Door e se aplica a todas as rotas associadas.

Os distratores representam equívocos recorrentes:

  • B sugere que a política WAF precisa ser replicada por backend, o que contradiz o modelo centralizado do Front Door.
  • C inverte os SKUs: proteção WAF com regras gerenciadas avançadas está disponível no Premium, não no Standard.
  • D confunde o Front Door com soluções regionais como o Application Gateway, que de fato opera por região.

Entender que o WAF do Front Door é um controle global e centralizado é fundamental para justificar seu uso em arquiteturas multiregião.


Gabarito — Questão 3

Resposta: Falso

O Azure Front Door foi projetado exclusivamente para tráfego HTTP e HTTPS. Ele opera na camada 7 do modelo OSI e não oferece suporte a protocolos como MQTT, FTP, SMTP ou qualquer outro protocolo não baseado em HTTP.

Esse é um limite arquitetural importante: o Front Door realiza inspeção, roteamento, cache e WAF apenas sobre requisições HTTP/HTTPS. Para protocolos TCP/UDP arbitrários, a solução adequada seria o Azure Load Balancer (camada 4) ou o Azure Gateway Load Balancer, dependendo do cenário.

Ignorar essa restrição levaria a uma escolha de arquitetura incorreta para workloads IoT, transferência de arquivos ou outros protocolos de camada de aplicação não baseados em HTTP.


Gabarito — Questão 4

Resposta: A

O Azure Front Door armazena em cache respostas nos seus PoPs globais, reduzindo a quantidade de requisições que chegam à origem. O comportamento do cache é controlável via regras de roteamento, onde é possível definir duração de cache, ignorar strings de query, ou forçar revalidação, oferecendo controle granular sobre o que é armazenado e por quanto tempo.

Os distratores introduzem limitações que não existem ou distorcem o funcionamento real:

  • B impõe um limite de 1 GB como barreira automática, o que não é um comportamento padrão documentado dessa forma como limitação absoluta de cache.
  • C afirma incorretamente que o Front Door delega todo controle de cache à origem; na prática, as regras do Front Door podem sobrescrever diretivas de cache da origem.
  • D restringe o caching apenas a HTTPS, o que não corresponde ao comportamento real do serviço.

Compreender que o Front Door pode sobrescrever ou complementar diretivas de cache da origem é essencial para dimensionar corretamente a estratégia de CDN.


Gabarito — Questão 5

Resposta: B

O Azure Front Door é um serviço global e externo à rede virtual. Ele não opera dentro de um VNet e foi projetado para tráfego originado da internet. Embora o SKU Premium suporte Private Link para conexão com backends privados, o próprio Front Door permanece um ponto de entrada público.

Para uma aplicação exclusivamente interna, acessada dentro de uma rede virtual corporativa, o Azure Application Gateway é a escolha correta: ele é implantado dentro de um VNet, suporta balanceamento regional, WAF e integração com recursos internos sem expor o serviço à internet.

Os distratores representam erros de escopo:

  • A é parcialmente verdadeiro em relação ao Private Link, mas confunde a capacidade de conectar backends privados com a capacidade de tornar o Front Door um serviço interno, o que não é possível.
  • C trata as soluções como equivalentes, ignorando a diferença fundamental entre escopo global/público e escopo regional/privado.
  • D justifica a escolha pelo WAF sem considerar o requisito de acesso exclusivamente interno, onde expor um endpoint público seria uma falha de design.