3.3.3. VPN Connections and Microsoft Entra Private Access

💡 First Principle: Connecting a remote user or an on-premises network to Azure resources can mean two very different trust models — extend the network itself (VPN) or grant identity-aware access to specific applications without extending the network at all (Private Access) — and picking the wrong one for a given requirement either under- or over-extends trust.

Site-to-site VPN connections use a VPN gateway to securely connect an entire on-premises network to a VNet over the internet, effectively extending network-layer reachability between the two — once connected, a device on either side can generally reach resources on the other, subject to routing and NSGs. Microsoft Entra Private Access (part of Global Secure Access) takes the opposite approach: it grants access to specific private applications based on identity and Conditional Access policy, without placing the connecting device on the corporate network at all — a genuinely Zero Trust alternative to "just VPN in."

⚠️ Exam Trap: "Modernizing remote access" scenarios that describe wanting to reduce lateral movement risk from compromised remote devices are pointing toward Microsoft Entra Private Access, not a "more secure VPN configuration" — the core problem (broad network extension) is architectural, not a configuration setting VPN alone can fix.

Reflection Question: Why does a compromised device connected via site-to-site VPN pose a fundamentally different lateral-movement risk than a compromised device using Microsoft Entra Private Access for the same application?