Pular para o conteúdo principal

Laboratório Técnico: Create and implement an Azure Firewall deployment

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe planeja implantar o Azure Firewall em uma arquitetura hub-and-spoke. O hub contém uma VNet com o prefixo 10.0.0.0/16. O arquiteto precisa criar a sub-rede dedicada ao Azure Firewall dentro dessa VNet.

Qual afirmação descreve corretamente os requisitos obrigatórios para essa sub-rede?

  • A) A sub-rede deve ser nomeada AzureFirewallSubnet e ter tamanho mínimo de /26; NSGs podem ser associados a ela para restringir tráfego de gerenciamento.
  • B) A sub-rede deve ser nomeada AzureFirewallSubnet e ter tamanho mínimo de /26; NSGs não são suportados nessa sub-rede.
  • C) A sub-rede pode ter qualquer nome, desde que seja identificada como sub-rede de firewall durante a implantação, e deve ter tamanho mínimo de /24.
  • D) A sub-rede deve ser nomeada AzureFirewallSubnet e ter tamanho mínimo de /24; UDRs não podem ser associadas a ela.

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

Uma organização implanta o Azure Firewall em modo hub centralizado para inspecionar todo o tráfego de saída dos spokes para a internet. Após a implantação, as VMs nos spokes continuam acessando a internet diretamente, sem passar pelo firewall. O administrador verifica que o Azure Firewall está provisionado e com status Running.

Spoke VNet: 10.1.0.0/16
Hub VNet:   10.0.0.0/16
Peering:    Spoke <-> Hub (configurado e ativo)
Firewall IP privado: 10.0.1.4

Qual é a causa mais provável do comportamento observado?

  • A) O peering entre o spoke e o hub não propaga rotas automaticamente; é necessário habilitar a opção Use Remote Gateways no peering do spoke para que o tráfego seja redirecionado ao firewall.
  • B) Não foram criadas User Defined Routes (UDRs) nas sub-redes dos spokes com uma rota padrão (0.0.0.0/0) apontando para o IP privado do Azure Firewall como next hop.
  • C) O Azure Firewall só inspeciona tráfego de saída quando uma regra de aplicação com destino Internet está configurada; sem ela, o tráfego de saída é liberado diretamente pela rota do sistema.
  • D) O peering hub-and-spoke não permite tráfego transitivo por padrão; para rotear tráfego dos spokes pelo firewall no hub, é necessário configurar um VPN Gateway no hub.

Questão 3 — Verdadeiro ou Falso​

O Azure Firewall, quando implantado sem o uso do Azure Firewall Manager, pode ser associado a múltiplas VNets simultaneamente, permitindo que um único recurso de firewall proteja várias VNets de forma nativa.

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

Uma empresa decide migrar de uma implantação tradicional do Azure Firewall gerenciada por regras clássicas para uma arquitetura gerenciada pelo Azure Firewall Manager com Firewall Policy. Durante o planejamento, o arquiteto identifica que existem regras locais configuradas diretamente no firewall atual que entram em conflito com as regras da política pai que será herdada.

Qual é o comportamento esperado do Azure Firewall Manager nesse cenário de herança de políticas?

  • A) As regras da política pai sempre têm precedência sobre as regras locais do firewall filho; regras locais conflitantes são ignoradas silenciosamente.
  • B) As regras da política pai são processadas antes das regras da política filha; dentro de cada política, as coleções de regras seguem a ordem de prioridade configurada.
  • C) As regras locais do firewall têm precedência sobre a política pai porque estão mais próximas do recurso; a política pai funciona apenas como fallback.
  • D) O Azure Firewall Manager não permite a coexistência de regras locais e políticas pai no mesmo firewall; a migração exige a remoção completa das regras locais antes de associar uma política.

Questão 5 — Múltipla Escolha​

Uma empresa precisa que o Azure Firewall distribua o tráfego de entrada entre múltiplos servidores backend sem expor os IPs privados desses servidores diretamente. O arquiteto considera usar regras DNAT no Azure Firewall para atender esse requisito.

Qual é a limitação correta das regras DNAT do Azure Firewall que o arquiteto deve considerar no desenho da solução?

  • A) Regras DNAT traduzem o IP público de destino para um único IP privado por regra; para balanceamento entre múltiplos backends, é necessário combinar o Azure Firewall com um Azure Load Balancer interno como destino do DNAT.
  • B) Regras DNAT suportam nativamente a distribuição de tráfego entre múltiplos IPs de destino usando round-robin; o limite é de até 5 IPs por regra no SKU Standard.
  • C) Regras DNAT no Azure Firewall são limitadas a protocolos TCP e UDP, mas suportam múltiplos IPs de destino quando combinadas com grupos de IPs.
  • D) Regras DNAT exigem que os IPs de destino estejam na mesma sub-rede do Azure Firewall; backends em sub-redes diferentes do hub não são suportados.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

A sub-rede dedicada ao Azure Firewall tem dois requisitos obrigatórios e imutáveis: o nome deve ser exatamente AzureFirewallSubnet (sensível a maiúsculas) e o tamanho mínimo deve ser /26. Esse tamanho é necessário porque o Azure Firewall aloca múltiplos IPs privados internamente para suportar escalabilidade e alta disponibilidade.

NSGs não são suportados na AzureFirewallSubnet. Associar um NSG a essa sub-rede pode impedir o funcionamento correto do firewall, pois o plano de controle do serviço requer acesso irrestrito a determinados fluxos de gerenciamento. A alternativa A é o distrator mais perigoso porque está quase correta, mas erra ao afirmar que NSGs são permitidos. A alternativa C está errada no nome e no tamanho. A alternativa D erra no tamanho mínimo e incorretamente proíbe UDRs, que são suportadas na sub-rede do firewall.

Gabarito — Questão 2​

Resposta: B

O Azure Firewall, por si só, não altera o comportamento de roteamento das VNets conectadas por peering. Para forçar o tráfego dos spokes a passar pelo firewall, é necessário criar UDRs nas sub-redes dos spokes com uma rota padrão 0.0.0.0/0 tendo o IP privado do Azure Firewall como next hop do tipo Virtual Appliance. Sem essa configuração, as VMs continuam usando as rotas do sistema, que enviam tráfego de internet diretamente pelo gateway padrão da VNet.

A alternativa A confunde Use Remote Gateways com redirecionamento de tráfego; essa opção é relevante para roteamento via VPN/ExpressRoute, não para firewall. A alternativa C está errada: a ausência de regras de aplicação não libera tráfego, ela o bloqueia pela negação implícita. A alternativa D está errada: peering hub-and-spoke com UDRs é exatamente o padrão suportado para tráfego transitivo via firewall, sem necessidade de VPN Gateway.

Gabarito — Questão 3​

Resposta: Falso

O Azure Firewall é um recurso implantado dentro de uma única VNet, especificamente na AzureFirewallSubnet dessa VNet. Ele não pode ser associado a múltiplas VNets simultaneamente de forma nativa. Para proteger múltiplas VNets, a arquitetura recomendada é o modelo hub-and-spoke, onde o firewall reside no hub e o tráfego dos spokes é roteado via UDRs e peering.

O Azure Firewall Manager com Virtual WAN ou hubs virtuais protegidos é o mecanismo para gerenciar múltiplos firewalls em múltiplas regiões a partir de uma interface centralizada, mas cada firewall ainda reside em sua própria VNet ou hub. A afirmação é falsa porque sugere que um único recurso pode ser associado nativamente a múltiplas VNets, o que não é suportado.

Gabarito — Questão 4​

Resposta: B

No Azure Firewall Manager, a herança de políticas segue uma hierarquia clara: as regras da política pai são processadas antes das regras da política filha (local). Dentro de cada política, as coleções de regras são avaliadas em ordem crescente de prioridade numérica. Isso significa que regras centralizadas da organização (política pai) são aplicadas primeiro, e as regras específicas do ambiente local (política filha) são avaliadas na sequência.

A alternativa A está errada ao afirmar que conflitos são ignorados silenciosamente; as regras são processadas em sequência e a primeira correspondência determina o veredicto. A alternativa C inverte a hierarquia correta. A alternativa D está errada: o Firewall Manager suporta a coexistência de regras locais e políticas pai, sendo esse exatamente o modelo de herança que permite governança centralizada com flexibilidade local.

Gabarito — Questão 5​

Resposta: A

As regras DNAT do Azure Firewall traduzem um endereço IP público de entrada para um único IP privado de destino por regra. O recurso não suporta nativamente a distribuição de tráfego entre múltiplos backends. Para implementar balanceamento de carga, o padrão correto é configurar o DNAT apontando para o IP de um Azure Load Balancer interno, que então distribui o tráfego entre os servidores backend.

A alternativa B descreve um comportamento que não existe: regras DNAT não suportam múltiplos IPs de destino com round-robin. A alternativa C está parcialmente correta ao mencionar a limitação de protocolos TCP e UDP, mas erra ao afirmar suporte a múltiplos IPs via grupos de IPs em contexto DNAT. A alternativa D descreve uma restrição inexistente: o destino do DNAT pode ser qualquer IP privado alcançável pelo firewall, independentemente da sub-rede.