Cascade Regional Airlines wants VMs in the booking-tier subnet to reach an Azure Storage account using a private IP address from the VNet's own address space, with the storage account fully removed from public exposure. What should they implement?
Select an answer to reveal the explanation.
Short Explanation
A private endpoint actually pulls the storage account into your VNet's own address space with a real private IP — it's not just a shortcut on the route, it's the resource itself showing up as a private neighbor. That's the difference between merely optimizing a path and truly removing public exposure.
Full Explanation
A private endpoint provisions a network interface, with a private IP address drawn from the VNet's own address space, that maps directly to a specific PaaS resource such as a storage account; traffic to that private IP goes straight to the storage account over the Microsoft backbone, and the storage account's public endpoint can then be disabled entirely, fully removing public exposure. A service endpoint, despite sounding similar, does not assign the storage account any private IP address at all — it optimizes the route from the subnet to the service's existing public endpoint and lets the service's firewall filter by subnet identity, but the storage account still has a public IP and is still, technically, a publicly addressable resource unless combined with other controls. A NAT gateway is an outbound-connectivity resource for VMs initiating traffic to the internet; it has no mechanism for translating or exposing a storage account's address, and is unrelated to this scenario. VNet peering connects two Azure virtual networks together; Azure Storage is a platform service, not a VNet, so peering cannot apply to it directly. After creating the private endpoint, Cascade's team must also update DNS (typically via a private DNS zone linked to the VNet) so that the storage account's standard hostname resolves to the new private IP instead of its public one.