Technical Lab: Implement Azure NAT Gateway
Questions
Question 1 — Multiple Choice
An architecture team needs to ensure that virtual machines in a specific subnet use a fixed and predictable set of public IP addresses when communicating with the internet, without directly exposing any inbound ports on those VMs.
Which combination of resources satisfies this requirement with the least operational overhead?
A) Associate a Public IP directly to each VM's NIC and configure NSG to block inbound traffic
B) Create an Azure NAT Gateway with one or more Public IP Prefixes and associate it to the subnet
C) Deploy an external Azure Load Balancer with outbound rules and associate the VMs to the backend pool
D) Configure a User-Defined Route (UDR) pointing outbound traffic to an Azure Firewall with SNAT enabled
Question 2 — Technical Scenario
A developer reports that long-running TCP connections initiated by VMs in a subnet with NAT Gateway configured are being unexpectedly terminated after a few minutes of inactivity, even though the application expects to keep the session open for up to 30 minutes.
Subnet: 10.1.0.0/24
NAT Gateway: nat-prod-eastus
Configured Idle Timeout: 4 minutes (default value)
Expected session inactivity time: 25 to 30 minutes
What is the root cause and the most appropriate solution?
A) NAT Gateway doesn't support long-running TCP connections; the solution is to migrate to Azure Load Balancer with outbound rules
B) The NAT Gateway idle timeout is at 4 minutes, below the expected inactivity time; it should be increased to up to 120 minutes in the resource settings
C) The NAT Gateway idle timeout is at 4 minutes, below the expected inactivity time; it should be increased to up to 120 minutes or configure TCP keepalives in the application
D) The problem is caused by missing NSG on the subnet; adding an explicit outbound rule for the application port resolves the premature termination
Question 3 — True or False
An Azure NAT Gateway associated to a subnet that also has VMs with individual Public IPs assigned to their NICs causes all outbound traffic from those VMs to pass through the NAT Gateway, ignoring the direct Public IPs of the NICs.
Question 4 — Technical Scenario
A company needs two distinct subnets within the same VNet to share exactly the same set of outbound public IPs to facilitate allowlisting in external partner systems.
VNet: vnet-corp (10.0.0.0/16)
Subnet A: snet-app (10.0.1.0/24)
Subnet B: snet-data (10.0.2.0/24)
Requirement: same public outbound IP for both
What is the correct approach to meet this requirement using NAT Gateway?
A) Create two distinct NAT Gateways and associate the same Public IP Prefix to each one
B) Create a single NAT Gateway with the desired public IPs and associate it to both subnets
C) Create a single NAT Gateway, but it can only be associated to one subnet at a time; the second subnet would need a Load Balancer with outbound rules using the same IPs
D) Associate the same Public IP directly to the NICs of VMs in both subnets, eliminating the NAT Gateway
Question 5 — Multiple Choice
An engineer is sizing the SNAT capacity of a NAT Gateway for a subnet with high volume of simultaneous connections to external destinations. He considers the following statements when choosing how many Public IPs to associate to the resource:
- Each public IP offers 64,512 available SNAT ports
- NAT Gateway supports up to 16 public IPs (or addresses within a Public IP Prefix)
- SNAT port exhaustion results in silent failure of new connections
Given that the application requires approximately 900,000 simultaneous outbound connections, what is the minimum number of public IPs needed?
A) 12
B) 13
C) 14
D) 16
Answer Key and Explanations
Answer Key — Question 1
Answer: B
The Azure NAT Gateway was designed exactly for this case: providing managed and deterministic SNAT for entire subnets, without exposing inbound ports. By associating a Public IP Prefix, the team gets a contiguous and predictable block of outbound public IPs with minimal configuration.
Alternative A exposes public addresses on NICs, creating inbound attack surface even with NSG, plus it scales poorly. Alternative C works technically but requires backend pool configuration, outbound rules and load balancing rules, increasing operational overhead. Alternative D is valid for advanced traffic control but introduces an Azure Firewall as additional hop, increasing cost and latency unnecessarily when the goal is just managed SNAT.
Answer Key — Question 2
Answer: C
The default idle timeout of NAT Gateway is 4 minutes and can be configured between 4 and 120 minutes. When the TCP session remains inactive for longer than the configured timeout, the NAT Gateway discards the SNAT port mapping, terminating the connection from a network perspective even though the application still considers it open.
The correct solution combines two complementary approaches: increase the idle timeout on the NAT Gateway (up to 120 minutes) or configure TCP keepalives in the application to generate periodic traffic and prevent the session from being classified as idle. Alternative B is partially correct but omits TCP keepalives, which are often the most robust solution in environments where infrastructure timeout control is limited. Alternative A is wrong because NAT Gateway supports long-running TCP connections normally. Alternative D confuses the role of NSG, which doesn't influence idle timeout behavior.
Answer Key — Question 3
Answer: False
When a VM has a Public IP assigned directly to its NIC, that IP takes precedence over the NAT Gateway for outbound traffic from that specific VM. The NAT Gateway acts as a fallback SNAT mechanism for VMs without individual public IP. Therefore, VMs with Public IP on the NIC continue using that IP directly for outbound, and not the NAT Gateway, even if it's associated to the subnet.
This behavior is relevant in allowlisting scenarios: assuming that all VMs in a subnet with NAT Gateway use the same outbound IP is a misconception that can cause connectivity failures and gaps in traffic control.
Answer Key — Question 4
Answer: B
A single NAT Gateway can be associated to multiple subnets within the same VNet. This allows distinct subnets to share the same set of outbound public IPs, directly meeting the unified allowlisting requirement with simple configuration.
Alternative A is wrong because two NAT Gateways are independent resources and don't share SNAT port state, even if using the same prefix. Alternative C inverts the real limitation: the restriction exists in the opposite direction, meaning a subnet can only be associated to one NAT Gateway at a time, but the NAT Gateway can serve multiple subnets. Alternative D abandons the centralized management requirement and recreates IP exposure on NICs.
Answer Key — Question 5
Answer: C
The calculation is straightforward: 900,000 simultaneous connections divided by 64,512 ports per IP results in approximately 13.95, therefore the minimum integer that meets the requirement is 14 public IPs.
Choosing 13 (alternative B) provides only 838,656 ports, insufficient for the declared peak. Choosing 12 (alternative A) is even more conservative and clearly below necessary. Choosing 16 (alternative D) would meet the requirement but is not the minimum. The learning point here is that SNAT port exhaustion in NAT Gateway results in new connection failures, and correct sizing requires rounding up, never truncation.