VMs in the crew-scheduling subnet at Cascade Regional Airlines need a stable, predictable outbound public IP address for connecting to a third-party scheduling API, but the subnet must not expose any inbound public endpoint. What should be attached to the subnet to meet this need?
Select an answer to reveal the explanation.
Short Explanation
A NAT gateway is a one-way door: it lets everything in the subnet reach out through a small, stable set of public IPs, but it never opens anything up for traffic coming in. That's exactly the shape Cascade needs here — outbound only, address never changes.
Full Explanation
A NAT gateway is a subnet-level resource purpose-built for outbound-only internet connectivity: every VM in the associated subnet shares one or more static public IP addresses for outbound traffic, and the NAT gateway does not expose any inbound public endpoint at all, which matches Cascade's requirement precisely. An inbound NAT rule on a load balancer does the opposite of what is needed here — it is designed to forward specific inbound connections to specific backend VMs, not to provide outbound connectivity, and configuring one would expose an inbound path the requirement explicitly forbids. Assigning a Basic public IP to each VM's NIC would technically allow outbound traffic, but each VM would get its own separate address rather than a shared, predictable one, and Basic public IPs also permit inbound traffic by default, again violating the outbound-only requirement. Azure Firewall's DNAT rules are also inbound-focused, translating a public destination address to a private one for incoming connections; using DNAT here would misapply a firewall feature meant for exposing services, not concealing them. Once the NAT gateway is attached, Cascade's team should confirm outbound traffic from a crew-scheduling VM actually egresses via the NAT gateway's IP and not through a competing default outbound access path.