Pular para o conteúdo principal

Laboratório Técnico: Implement Azure NAT Gateway

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe de arquitetura precisa garantir que máquinas virtuais em uma sub-rede específica usem um conjunto fixo e previsível de endereços IP públicos ao se comunicar com a internet, sem expor nenhuma porta de entrada diretamente nessas VMs.

Qual combinação de recursos satisfaz esse requisito com o menor overhead operacional?

A) Associar um Public IP diretamente a cada NIC das VMs e configurar NSG para bloquear tráfego de entrada

B) Criar um Azure NAT Gateway com um ou mais Public IP Prefixes e associá-lo à sub-rede

C) Implantar um Azure Load Balancer externo com regras de outbound e associar as VMs ao backend pool

D) Configurar um User-Defined Route (UDR) apontando o tráfego de saída para um Azure Firewall com SNAT habilitado

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

Um desenvolvedor relata que as conexões TCP de longa duração iniciadas pelas VMs de uma sub-rede com NAT Gateway configurado estão sendo encerradas inesperadamente após alguns minutos de inatividade, mesmo que a aplicação espere manter a sessão aberta por até 30 minutos.

Sub-rede: 10.1.0.0/24
NAT Gateway: nat-prod-eastus
Idle Timeout configurado: 4 minutos (valor padrão)
Tempo esperado de inatividade da sessão: 25 a 30 minutos

Qual é a causa raiz e a solução mais adequada?

A) O NAT Gateway não suporta conexões TCP de longa duração; a solução é migrar para Azure Load Balancer com outbound rules

B) O idle timeout do NAT Gateway está em 4 minutos, abaixo do tempo de inatividade esperado; deve-se aumentá-lo para até 120 minutos nas configurações do recurso

C) O idle timeout do NAT Gateway está em 4 minutos, abaixo do tempo de inatividade esperado; deve-se aumentá-lo para até 120 minutos ou configurar TCP keepalives na aplicação

D) O problema é causado por ausência de NSG na sub-rede; adicionar uma regra de saída explícita para a porta da aplicação resolve o encerramento prematuro

Questão 3 — Verdadeiro ou Falso​

Um Azure NAT Gateway associado a uma sub-rede que também possui VMs com Public IPs individuais atribuídos às suas NICs faz com que todo o tráfego de saída dessas VMs passe pelo NAT Gateway, ignorando os Public IPs diretos das NICs.

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

Uma empresa precisa que duas sub-redes distintas dentro da mesma VNet compartilhem exatamente o mesmo conjunto de IPs públicos de saída para facilitar o allowlisting em sistemas de parceiros externos.

VNet: vnet-corp (10.0.0.0/16)
Sub-rede A: snet-app (10.0.1.0/24)
Sub-rede B: snet-data (10.0.2.0/24)
Requisito: mesmo IP público de saída para ambas

Qual é a abordagem correta para atender a esse requisito usando NAT Gateway?

A) Criar dois NAT Gateways distintos e associar o mesmo Public IP Prefix a cada um deles

B) Criar um único NAT Gateway com os IPs públicos desejados e associá-lo a ambas as sub-redes

C) Criar um único NAT Gateway, mas ele só pode ser associado a uma sub-rede por vez; a segunda sub-rede precisaria de um Load Balancer com outbound rules usando os mesmos IPs

D) Associar o mesmo Public IP diretamente às NICs das VMs de ambas as sub-redes, dispensando o NAT Gateway

Questão 5 — Múltipla Escolha​

Um engenheiro está dimensionando a capacidade de SNAT de um NAT Gateway para uma sub-rede com alto volume de conexões simultâneas para destinos externos. Ele considera as seguintes afirmações ao escolher quantos Public IPs associar ao recurso:

  • Cada IP público oferece 64.512 portas SNAT disponíveis
  • O NAT Gateway suporta até 16 IPs públicos (ou endereços dentro de um Public IP Prefix)
  • A exaustão de portas SNAT resulta em falha silenciosa de novas conexões

Dado que a aplicação exige aproximadamente 900.000 conexões simultâneas de saída, qual é o número mínimo de IPs públicos necessários?

A) 12

B) 13

C) 14

D) 16

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

O Azure NAT Gateway foi projetado exatamente para esse caso: fornecer SNAT gerenciado e determinístico para sub-redes inteiras, sem expor portas de entrada. Ao associar um Public IP Prefix, a equipe obtém um bloco contíguo e previsível de IPs públicos de saída com configuração mínima.

A alternativa A expõe endereços públicos nas NICs, criando superfície de ataque de entrada mesmo com NSG, além de escalar mal. A alternativa C funciona tecnicamente, mas exige configuração de backend pool, outbound rules e regras de balanceamento, elevando o overhead operacional. A alternativa D é válida para controle avançado de tráfego, mas introduz um Azure Firewall como hop adicional, aumentando custo e latência sem necessidade quando o objetivo é apenas SNAT gerenciado.

Gabarito — Questão 2​

Resposta: C

O idle timeout padrão do NAT Gateway é de 4 minutos e pode ser configurado entre 4 e 120 minutos. Quando a sessão TCP fica inativa por mais tempo do que o timeout configurado, o NAT Gateway descarta o mapeamento de porta SNAT, encerrando a conexão do ponto de vista da rede mesmo que a aplicação ainda a considere aberta.

A solução correta combina duas abordagens complementares: aumentar o idle timeout no NAT Gateway (até 120 minutos) ou configurar TCP keepalives na aplicação para gerar tráfego periódico e evitar que a sessão seja classificada como ociosa. A alternativa B está parcialmente correta, mas omite os TCP keepalives, que são frequentemente a solução mais robusta em ambientes onde o controle do timeout da infraestrutura é limitado. A alternativa A está errada porque o NAT Gateway suporta conexões TCP de longa duração normalmente. A alternativa D confunde o papel do NSG, que não influencia o comportamento de idle timeout.

Gabarito — Questão 3​

Resposta: Falso

Quando uma VM possui um Public IP atribuído diretamente à sua NIC, esse IP tem precedência sobre o NAT Gateway para o tráfego de saída daquela VM específica. O NAT Gateway atua como mecanismo de SNAT de fallback para VMs sem IP público individual. Portanto, VMs com Public IP na NIC continuam usando esse IP diretamente para saída, e não o NAT Gateway, mesmo que este esteja associado à sub-rede.

Esse comportamento é relevante em cenários de allowlisting: assumir que todas as VMs de uma sub-rede com NAT Gateway usam o mesmo IP de saída é um equívoco que pode causar falhas de conectividade e brechas no controle de tráfego.

Gabarito — Questão 4​

Resposta: B

Um único NAT Gateway pode ser associado a múltiplas sub-redes dentro da mesma VNet. Isso permite que sub-redes distintas compartilhem o mesmo conjunto de IPs públicos de saída, atendendo diretamente ao requisito de allowlisting unificado com configuração simples.

A alternativa A está errada porque dois NAT Gateways são recursos independentes e não compartilham estado de portas SNAT, mesmo que usem o mesmo prefixo. A alternativa C inverte a limitação real: a restrição existe na direção oposta, ou seja, uma sub-rede só pode ser associada a um NAT Gateway por vez, mas o NAT Gateway pode atender várias sub-redes. A alternativa D abandona o requisito de gerenciamento centralizado e recria a exposição de IPs nas NICs.

Gabarito — Questão 5​

Resposta: C

O cálculo é direto: 900.000 conexões simultâneas dividido por 64.512 portas por IP resulta em aproximadamente 13,95, portanto o número mínimo inteiro que atende ao requisito é 14 IPs públicos.

Escolher 13 (alternativa B) fornece apenas 838.656 portas, insuficiente para o pico declarado. Escolher 12 (alternativa A) é ainda mais conservador e claramente abaixo do necessário. Escolher 16 (alternativa D) atenderia ao requisito, mas não é o mínimo. O ponto de aprendizado aqui é que a exaustão de portas SNAT no NAT Gateway resulta em falha de novas conexões, e o dimensionamento correto exige arredondamento para cima, nunca truncamento.