Pular para o conteúdo principal

Laboratório Técnico: Map requirements to features and capabilities of Azure Application Gateway

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe de arquitetura precisa expor três aplicações web distintas usando um único recurso do Azure Application Gateway. Cada aplicação possui seu próprio hostname (app1.contoso.com, app2.contoso.com, app3.contoso.com) e deve ser roteada para um backend pool diferente.

Qual combinação de recursos do Application Gateway viabiliza esse roteamento por hostname?

A) Um listener multi-site para cada hostname, combinado com regras de roteamento por caminho (path-based rules) apontando para os três backend pools.

B) Um listener básico compartilhado entre os três hostnames, com regras de roteamento baseadas em prioridade.

C) Um listener multi-site para cada hostname, cada um associado a uma regra de roteamento independente apontando para seu respectivo backend pool.

D) Três frontend IP configurations distintas, uma por hostname, com listeners básicos associados a cada uma.

Questão 2 — Cenário Técnico​

Um desenvolvedor relata que requisições para https://loja.contoso.com/api/pagamentos estão sendo roteadas para o backend pool incorreto. O Application Gateway está configurado conforme abaixo:

Listener: loja-https (porta 443, hostname: loja.contoso.com)

Regra: loja-rule (tipo: path-based)
  Path: /api/pedidos  → pool-pedidos
  Path: /api/clientes → pool-clientes
  Default backend: pool-estatico

Para qual backend pool as requisições para /api/pagamentos estão sendo enviadas e por quê?

A) A requisição é rejeitada com HTTP 404, pois não há path correspondente configurado.

B) A requisição é encaminhada para pool-estatico, pois nenhum path configurado corresponde a /api/pagamentos e o default backend é acionado.

C) A requisição é encaminhada para pool-pedidos, pois o Application Gateway aplica correspondência parcial de prefixo entre /api/pagamentos e /api/pedidos.

D) A requisição é bloqueada pelo WAF do Application Gateway por ausência de regra explícita.

Questão 3 — Verdadeiro ou Falso​

O Azure Application Gateway com WAF habilitado no modo Detection bloqueia automaticamente requisições identificadas como maliciosas, registrando o evento nos logs de diagnóstico.

Questão 4 — Cenário Técnico​

Uma empresa precisa garantir que usuários de uma mesma sessão sejam sempre encaminhados para a mesma instância de backend, pois a aplicação armazena estado localmente em memória. O Application Gateway já está implantado com as configurações padrão.

Qual ajuste resolve esse requisito sem alterar a arquitetura da aplicação?

A) Habilitar o Connection Draining no backend pool, configurando um timeout suficiente para preservar sessões ativas.

B) Habilitar a afinidade de sessão baseada em cookie nas configurações HTTP do backend pool.

C) Configurar um probe de saúde personalizado com intervalo reduzido para detectar falhas antes que a sessão seja interrompida.

D) Alterar o algoritmo de balanceamento para Least Connections nas configurações HTTP do backend pool.

Questão 5 — Múltipla Escolha​

Ao comparar os SKUs Standard_v2 e WAF_v2 do Azure Application Gateway, qual afirmação descreve com precisão uma diferença funcional relevante para o processo de design de solução?

A) Apenas o SKU WAF_v2 suporta autoscaling e zonas de disponibilidade; o Standard_v2 opera com capacidade fixa.

B) O SKU Standard_v2 não suporta roteamento baseado em URL path; essa funcionalidade está restrita ao WAF_v2.

C) O SKU WAF_v2 inclui todas as capacidades do Standard_v2 e adiciona inspeção de tráfego HTTP/HTTPS contra ameaças conhecidas por meio de regras OWASP.

D) O SKU WAF_v2 substitui completamente o uso de Network Security Groups na subnet do Application Gateway, tornando-os desnecessários.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: C

O roteamento por hostname no Application Gateway é viabilizado pelos listeners multi-site, que permitem distinguir requisições com base no campo Host do cabeçalho HTTP. Cada hostname exige seu próprio listener multi-site. A associação de cada listener a uma regra de roteamento independente direciona o tráfego para o backend pool correto.

A alternativa A representa um equívoco comum: path-based rules resolvem roteamento por caminho de URL, não por hostname. Combiná-las com listeners multi-site não é incorreto em si, mas não é o mecanismo que diferencia os hostnames entre si nesse cenário. A alternativa D confunde frontend IP configuration (que define o IP público ou privado do gateway) com a capacidade de distinguir hostnames, o que não é sua função. A alternativa B é tecnicamente inviável: um listener básico não inspeciona o campo Host e não consegue diferenciar múltiplos hostnames.

Gabarito — Questão 2​

Resposta: B

O Application Gateway aplica correspondência exata de prefixo nos paths configurados. Como /api/pagamentos não corresponde a nenhum path registrado na regra (/api/pedidos ou /api/clientes), o gateway aciona o default backend, que nesse caso é pool-estatico.

A alternativa C representa um equívoco crítico: o Application Gateway não realiza correspondência parcial ou fonética entre paths. /api/pagamentos e /api/pedidos compartilham o prefixo /api/, mas isso não constitui uma correspondência válida de regra. A alternativa A está errada porque a ausência de path correspondente não resulta em HTTP 404 por parte do gateway; o default backend existe exatamente para absorver esse tráfego. A alternativa D confunde o comportamento padrão de roteamento com atuação do WAF, que opera sobre o conteúdo da requisição, não sobre a ausência de regra de path.

Gabarito — Questão 3​

Resposta: Falso

No modo Detection, o WAF do Application Gateway registra as requisições suspeitas nos logs de diagnóstico, mas não as bloqueia. O bloqueio efetivo só ocorre no modo Prevention. Essa distinção é fundamental em cenários de onboarding do WAF, onde o modo Detection é usado para calibrar regras sem impactar o tráfego legítimo. Assumir que o modo Detection oferece proteção ativa é um erro operacional com consequências diretas de segurança.

Gabarito — Questão 4​

Resposta: B

A afinidade de sessão baseada em cookie (também chamada de cookie-based affinity) instrui o Application Gateway a inserir um cookie na primeira resposta ao cliente. Nas requisições subsequentes, o gateway lê esse cookie e encaminha a requisição para a mesma instância de backend que atendeu originalmente, preservando o estado em memória da aplicação.

A alternativa A descreve o Connection Draining, cujo propósito é permitir que conexões ativas sejam concluídas antes de remover uma instância do pool, não manter afinidade de sessão. A alternativa C descreve um health probe, que monitora disponibilidade, mas não influencia para qual instância uma requisição é enviada. A alternativa D é incorreta porque o Azure Application Gateway não expõe o algoritmo Least Connections como opção configurável diretamente nas configurações HTTP; o mecanismo de balanceamento padrão é round-robin, e a afinidade de sessão é o mecanismo correto para o requisito descrito.

Gabarito — Questão 5​

Resposta: C

O SKU WAF_v2 é um superconjunto funcional do Standard_v2: todas as capacidades de roteamento, autoscaling, zonas de disponibilidade e terminação TLS estão presentes em ambos. A diferença central é que o WAF_v2 adiciona o Web Application Firewall, que inspeciona o tráfego HTTP/HTTPS com base em conjuntos de regras gerenciadas (como OWASP CRS) para detectar e bloquear ameaças conhecidas como injeção SQL e XSS.

A alternativa A é factualmente incorreta: autoscaling e suporte a zonas de disponibilidade estão disponíveis em ambos os SKUs v2. A alternativa B é falsa: path-based routing está disponível no Standard_v2 sem qualquer restrição. A alternativa D representa um equívoco perigoso em design de rede: Network Security Groups na subnet do Application Gateway continuam sendo recomendados e necessários para controle de tráfego de plano de gerenciamento e entre recursos; o WAF não substitui essa camada.