Technical Lab: Identify appropriate use cases for Azure NAT Gateway
Questions
Question 1 — Multiple Choice
A development team maintains dozens of virtual machines in a subnet that need to access external APIs on the internet. The team reports that during peak times, some requests fail with port exhaustion errors. The current architecture uses a Standard Load Balancer with a configured outbound rule.
Which characteristic of Azure NAT Gateway justifies its adoption as a replacement for the Load Balancer's outbound rule in this scenario?
A) NAT Gateway eliminates the need for public IP addresses, routing traffic through private IPs managed by Microsoft.
B) NAT Gateway offers a significantly larger SNAT port pool per public IP address, reducing the risk of exhaustion even with high volumes of simultaneous connections.
C) NAT Gateway automatically distributes outbound traffic across multiple subnets, load balancing SNAT connections.
D) NAT Gateway completely replaces the Standard Load Balancer, also taking over inbound load balancing functions.
Question 2 — Technical Scenario
A company configured Azure NAT Gateway associated with a subnet that contains VMs without public IP addresses. The administrator reports that the VMs can access the internet normally, but connections initiated from the internet toward the VMs are being blocked, generating complaints from a partner who needs to access a service exposed on these VMs.
What is the correct cause of this behavior and what is the appropriate approach to resolve the problem?
A) NAT Gateway blocks inbound traffic by default; the administrator should enable the "inbound NAT" option in the resource settings.
B) This behavior is expected: NAT Gateway is an outbound-only service. To accept inbound connections, the VMs need their own public IP address or a Load Balancer with an inbound rule.
C) The subnet's Network Security Group is overriding NAT Gateway rules; removing the NSG will solve the problem.
D) NAT Gateway needs to be associated with each VM's network interface as well to allow bidirectional traffic.
Question 3 — Multiple Choice
An architect needs to ensure that all VMs in a subnet always use the same set of public IPs when communicating with an external service that applies IP allowlisting. The solution should be simple to manage and should not depend on individual VM configuration.
Which combination represents the most appropriate approach?
A) Assign a public IP to each VM individually and document all IPs for the partner.
B) Use a Standard Load Balancer with outbound rules and a single frontend public IP.
C) Associate a NAT Gateway to the subnet with one or more static public IP prefixes, ensuring all outbound traffic uses predictable and centrally managed IPs.
D) Use an Azure Firewall with SNAT policy to mask VM IPs with a fixed IP.
Question 4 — Technical Scenario
Consider the following subnet configuration:
Subnet: snet-workloads (10.1.1.0/24)
- NAT Gateway: natgw-prod (associated)
- NAT Gateway public IP: 20.x.x.10
- VM-A: no public IP, no Load Balancer
- VM-B: own public IP assigned directly to NIC (40.y.y.5)
An engineer claims that both VMs will use IP 20.x.x.10 when accessing the internet, since the NAT Gateway is associated with the subnet.
What is the correct evaluation of this claim?
A) The claim is correct; NAT Gateway has absolute precedence over any public IP assigned to network interfaces in the subnet.
B) The claim is incorrect; VM-B will use its own public IP 40.y.y.5 for outbound traffic, while VM-A will use the NAT Gateway IP 20.x.x.10.
C) The claim is incorrect; in subnets with NAT Gateway, no VM can have its own public IP, and the configuration would be rejected by Azure.
D) The claim is partially correct; NAT Gateway is used by VM-B only when its own public IP is unavailable.
Question 5 — True or False
Statement: Azure NAT Gateway can be simultaneously associated with a subnet that already has a default route (0.0.0.0/0) pointing to an Azure Firewall, and in this scenario the NAT Gateway will have precedence over the route defined in the route table for outbound internet traffic.
True or False?
Answer Key and Explanations
Answer Key — Question 1
Answer: B
SNAT port exhaustion is a classic problem in architectures with high volumes of simultaneous outbound connections. The Standard Load Balancer offers, by default, a limited number of SNAT ports per backend instance, which can be insufficient in peak scenarios.
NAT Gateway solves this by providing 64,512 SNAT ports per associated public IP address, and allows associating up to 16 public IPs, totaling over 1 million available ports. This pool is dynamically shared among the subnet's VMs, without prior static allocation per instance.
The distractors represent common errors: NAT Gateway doesn't operate with private IPs (A is false), doesn't load balance across subnets (C confuses NAT with Load Balancer), and doesn't replace Load Balancer inbound functions (D is false). Choice D is a frequent mistake by those who don't distinguish between inbound and outbound planes.
Answer Key — Question 2
Answer: B
Azure NAT Gateway is, by design, a unidirectional outbound service. It allows resources without public IPs to initiate connections to the internet, but does not accept externally initiated connections. This behavior is not a configuration failure nor can it be changed by any resource option.
For the partner to access services hosted on the VMs, a separate inbound mechanism is required: a public IP address assigned directly to the VM's NIC or a Standard Load Balancer with inbound NAT rule or load balancing.
Alternative A is a dangerous distractor because it sounds reasonable, but the "inbound NAT" option simply doesn't exist in NAT Gateway. Alternative C is incorrect because NSG doesn't interfere with NAT Gateway's control plane; it filters packets but doesn't reverse the unidirectional nature of the service. Alternative D confuses subnet association with NIC association, which is not supported by NAT Gateway.
Answer Key — Question 3
Answer: C
The IP allowlisting use case requires the outbound IP to be predictable and stable. NAT Gateway associated with a public IP prefix is the most direct solution: all IPs in the prefix are known in advance, NAT Gateway ensures all subnet traffic exits through these IPs, and management is centralized in a single resource.
Alternative A solves the problem functionally but is operationally unfeasible at scale, requiring individual configuration and communication per VM. Alternative B with Load Balancer also works for a fixed IP, but NAT Gateway is more suitable specifically for high-scale outbound scenarios without inbound balancing needs. Alternative D with Azure Firewall is also technically valid but introduces unnecessary cost and complexity when the only requirement is outbound IP predictability, making NAT Gateway the most precise and efficient choice for the described scenario.
Answer Key — Question 4
Answer: B
Azure NAT Gateway respects a precedence order to determine which public IP will be used in a VM's outbound traffic. When a VM has a public IP directly associated with its NIC, that IP takes precedence over the subnet's NAT Gateway.
Therefore, VM-B will use its own IP 40.y.y.5, while VM-A, without its own public IP, will use the NAT Gateway IP 20.x.x.10. This behavior is intentional and documented, allowing individual exceptions within a subnet managed by NAT Gateway.
Alternative A reverses the precedence logic, which is a serious conceptual error. Alternative C is false: Azure allows VMs with public IPs in subnets associated with a NAT Gateway. Alternative D is also incorrect: VM-B's public IP is always used for outbound, not just as a fallback.
Answer Key — Question 5
Answer: False
When a route table with default route (0.0.0.0/0) pointing to Azure Firewall (or other appliance) is associated with a subnet, that route takes precedence over NAT Gateway. Outbound traffic will follow the path defined in the UDR (User Defined Route), ignoring the NAT Gateway.
This is a critical architectural distinction: NAT Gateway operates at the address translation layer, but doesn't override routing decisions defined by UDR. If the goal is to force traffic through Azure Firewall with a predictable outbound IP, SNAT must be configured on the Firewall itself.
The conceptual error in this distractor is assuming that NAT Gateway, being an outbound service, would have authority over the routing plane. In practice, routing and address translation are distinct layers, and UDR is evaluated before NAT Gateway comes into play.