Pular para o conteúdo principal

Laboratório Técnico: Design an Azure Firewall deployment

Questões​

Questão 1 — Múltipla Escolha​

Uma organização precisa implantar o Azure Firewall em uma arquitetura hub-and-spoke com 12 VNets spoke distribuídas em duas regiões. O requisito central é que as políticas de firewall sejam gerenciadas de forma centralizada, com variações regionais para regras específicas de cada ambiente. Qual combinação de recursos do Azure Firewall atende a esse requisito?

A) Implantar um Azure Firewall por spoke e usar Firewall Policy local em cada instância, sem herança entre políticas.

B) Criar uma Firewall Policy base com as regras globais e derivar políticas filhas regionais que herdam e estendem as regras da política pai.

C) Usar uma única Firewall Policy global associada a todos os firewalls, adicionando tags de região para filtrar regras durante a avaliação.

D) Implantar o Azure Firewall Manager como instância separada em cada região e sincronizar as políticas manualmente entre as instâncias.

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

Uma equipe projeta a implantação do Azure Firewall em uma VNet hub. A subnet destinada ao firewall foi criada com o nome AzureFirewallSubnet e um prefixo /26. Após a implantação, a equipe percebe que não consegue associar um NSG a essa subnet para adicionar uma camada extra de controle de entrada.

Subnet name  : AzureFirewallSubnet
Address space: 10.0.0.0/26
NSG          : nsg-firewall (tentativa de associação falhou)

Qual é a causa dessa limitação?

A) O prefixo /26 é insuficiente para o Azure Firewall; o mínimo exigido é /24, e o Azure bloqueia a associação de NSG em subnets subdimensionadas.

B) A AzureFirewallSubnet não suporta a associação de NSGs por design, pois o próprio Azure Firewall gerencia o controle de tráfego nessa subnet.

C) O NSG precisa ser criado na mesma zona de disponibilidade que o Azure Firewall antes de ser associado à subnet.

D) NSGs só podem ser associados à AzureFirewallSubnet quando o Azure Firewall está no SKU Premium; o SKU Standard não suporta esse recurso.

Questão 3 — Múltipla Escolha​

Ao projetar um Azure Firewall com suporte a zonas de disponibilidade, um arquiteto precisa entender as implicações sobre o endereço IP público associado. Qual afirmação descreve corretamente o requisito para o IP público nesse cenário?

A) O IP público pode ser do SKU Basic, pois o Azure Firewall gerencia internamente a redundância entre zonas sem dependência do SKU do IP.

B) O IP público deve ser do SKU Standard e ter redundância de zona habilitada para suportar a implantação do firewall em múltiplas zonas de disponibilidade.

C) Cada zona de disponibilidade exige um IP público dedicado; portanto, uma implantação em três zonas requer obrigatoriamente três IPs públicos distintos.

D) O IP público deve ser do SKU Standard, mas a redundância de zona é configurada exclusivamente no Azure Firewall e não no recurso de IP público.

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

Uma empresa precisa que o Azure Firewall inspecione o tráfego TLS de saída das VMs para a internet, identificando ameaças em conexões HTTPS. O firewall foi implantado com SKU Standard e uma Firewall Policy associada. O engenheiro responsável tenta habilitar a inspeção TLS, mas a opção não está disponível na política.

Qual é a causa correta da limitação encontrada?

A) A inspeção TLS exige que o Azure Firewall esteja implantado em uma Virtual WAN hub (Secured Virtual Hub), não em uma VNet convencional.

B) A inspeção TLS não está disponível no SKU Standard; esse recurso é exclusivo do SKU Premium, que oferece o mecanismo de inspeção IDPS e TLS.

C) A inspeção TLS requer a configuração prévia de um certificado CA intermediário no Key Vault, e a opção fica bloqueada até que essa dependência seja satisfeita.

D) A Firewall Policy precisa estar no nível Premium para habilitar a inspeção TLS, independentemente do SKU do Azure Firewall implantado.

Questão 5 — Verdadeiro ou Falso​

No Azure Firewall, as regras de aplicação (application rules) são avaliadas antes das regras de rede (network rules) quando ambas correspondem ao mesmo tráfego de saída, pois regras de aplicação operam em camada mais alta e têm precedência por design.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

Explique:

  • O Azure Firewall Manager suporta herança de políticas: uma Firewall Policy pai contém as regras globais (comuns a todos os ambientes), e políticas filhas herdam essas regras, podendo adicionar regras específicas regionais ou de ambiente sem modificar a política base. Esse modelo é exatamente o que o requisito descreve: governança centralizada com flexibilidade local.
  • A alternativa A elimina a gestão centralizada ao isolar as políticas por instância, contradizendo diretamente o requisito.
  • A alternativa C é incorreta porque o Azure Firewall Policy não possui mecanismo de filtragem por tags durante a avaliação de regras; tags são usadas para organização de recursos, não para segmentação de regras.
  • A alternativa D confunde o Azure Firewall Manager com uma instância separável e replicável; o Firewall Manager é um plano de gerenciamento, não uma instância de firewall por região.

Gabarito — Questão 2​

Resposta: B

Explique:

  • A AzureFirewallSubnet é uma subnet com restrições de plataforma: NSGs não podem ser associados a ela. Essa limitação existe porque o Azure Firewall possui seu próprio mecanismo de controle de tráfego e a associação de um NSG poderia interferir no processamento do tráfego pelo firewall, gerando comportamentos imprevisíveis ou bloqueios indevidos.
  • A alternativa A é parcialmente incorreta: o prefixo mínimo para a AzureFirewallSubnet é /26 (não /24), portanto a subnet do cenário está dimensionada corretamente. O tamanho da subnet não é a causa do problema.
  • A alternativa C é incorreta porque zonas de disponibilidade são configuradas na implantação do firewall e não afetam a capacidade de associar NSGs à subnet.
  • A alternativa D é uma distratora plausível, mas incorreta: a restrição de NSG na AzureFirewallSubnet se aplica a todos os SKUs do Azure Firewall, não apenas ao Standard.

Gabarito — Questão 3​

Resposta: B

Explique:

  • Quando o Azure Firewall é implantado com suporte a zonas de disponibilidade, o IP público associado deve ser do SKU Standard e deve ter a propriedade de redundância de zona habilitada. IPs públicos com redundância de zona são replicados entre zonas fisicamente separadas, garantindo que o endereço permaneça acessível mesmo em caso de falha de uma zona.
  • A alternativa A é incorreta porque IPs públicos do SKU Basic não suportam zonas de disponibilidade; o SKU Standard é obrigatório.
  • A alternativa C representa um equívoco comum: não é necessário um IP público por zona; um único IP Standard com redundância de zona cobre as três zonas simultaneamente.
  • A alternativa D é sutilmente incorreta: a redundância de zona deve ser configurada no recurso de IP público, não apenas no Azure Firewall. Se o IP público não tiver redundância de zona habilitada, a implantação multi-zona do firewall não terá a resiliência esperada no plano de endereçamento.

Gabarito — Questão 4​

Resposta: B

Explique:

  • A inspeção TLS (TLS inspection) é um recurso exclusivo do Azure Firewall SKU Premium. O SKU Standard não possui o motor de inspeção IDPS nem a capacidade de fazer man-in-the-middle TLS para inspeção de conteúdo cifrado. Para habilitar esse recurso, tanto o Azure Firewall quanto a Firewall Policy associada precisam ser do tipo Premium.
  • A alternativa A é incorreta: a inspeção TLS está disponível tanto em implantações em VNet convencional quanto em Secured Virtual Hub, desde que o SKU Premium seja usado.
  • A alternativa C descreve uma dependência real (o certificado CA no Key Vault é necessário para configurar a inspeção TLS), mas não é a causa do bloqueio descrito: a opção sequer aparece porque o SKU não suporta o recurso, não porque uma dependência está pendente.
  • A alternativa D representa um equívoco parcial: a Firewall Policy Premium é necessária, mas a causa raiz é o SKU do firewall, não apenas o da política. Ambos precisam ser Premium; a política isoladamente não resolve o problema se o firewall for Standard.

Gabarito — Questão 5​

Resposta: Falso

Explique:

  • No Azure Firewall, a ordem de avaliação das regras é: regras DNAT primeiro, depois regras de rede, e por último regras de aplicação. As regras de rede são avaliadas antes das regras de aplicação, não o contrário.
  • Essa ordem é contraintuitiva porque, em firewalls tradicionais de camada 7, regras de aplicação costumam ter precedência. No Azure Firewall, a lógica é diferente: se uma regra de rede permitir o tráfego, ele não alcança a avaliação das regras de aplicação.
  • A consequência prática desse equívoco é relevante: um administrador que crie uma regra de rede permissiva acreditando que as regras de aplicação irão refiná-la estará exposto a tráfego não inspecionado, pois a regra de rede será avaliada e satisfeita antes que as regras de aplicação sejam consideradas.