AZ-500 Secure networking Practice Question

You need to provide secure remote access to Azure virtual machines for administrators without exposing them to the public internet. The solution must use a single entry point and support Microsoft Entra ID (now Microsoft Entra ID) authentication. Which Azure service should you use?

⚠ Common exam trap

A common mix-up: candidates confuse Just-in-time VM access (which reduces exposure but still requires public IPs) with a true zero-public-IP solution, or they assume a VPN gateway provides a single entry point when it actually creates multiple client-specific tunnels.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Azure Bastion.

Azure Bastion provides secure, seamless RDP/SSH connectivity to Azure VMs directly from the Azure portal over TLS, without exposing public IP addresses. It uses a single entry point (the Bastion host) and supports Microsoft Entra ID authentication for login, meeting both requirements.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Azure Bastion.
Why this is correct
Azure Bastion is a fully managed PaaS service deployed inside the VNet that brokers RDP and SSH sessions over TLS to the Azure portal, so VMs never need a public IP address or inbound internet-facing NSG rules. It authenticates with Entra ID (Azure AD) and can require MFA or Conditional Access before brokering the session, and it connects directly to the VM's private IP over the Bastion subnet. This is the only option here that gives administrators portal-based, client-less remote access while completely removing VMs from internet exposure.
✗
Just-in-time (JIT) VM access with Microsoft Defender for Cloud.
Why it's wrong here
Just-in-time (JIT) VM access in Microsoft Defender for Cloud reduces the attack surface by temporarily opening an NSG rule to a requesting user's public IP on demand, but each target VM must still have an assigned public IP address to receive the RDP/SSH connection. The session still goes directly from the user's client over the internet to the VM, and the temporary NSG rules are removed after the approval window expires. While this is a valuable security hardening control, it does not eliminate public IPs, does not broker the session through a portal service, and therefore does not fully meet the secure remote access requirement.
✗
Azure Front Door with private endpoints.
Why it's wrong here
Azure Front Door with private endpoints operates at the application layer and is designed to route HTTP/HTTPS traffic to web origins for global load balancing and acceleration, not to carry RDP or SSH protocol traffic. A private endpoint only changes the path used to reach the origin over the Microsoft backbone; it does not provide any interactive RDP/SSH brokering capability. Since Front Door has no native support for remote administration protocols, this combination cannot serve as a solution for securely accessing Azure VMs for management.
✗
Azure VPN Gateway with point-to-site VPN.
Why it's wrong here
Point-to-site VPN through Azure VPN Gateway can secure a user's connection to the VNet, but it requires installing and configuring a VPN client, selecting a tunnel type such as OpenVPN, SSTP, or IKEv2, and the VPN gateway itself remains publicly reachable over the internet. It also does not give single-URL, portal-based access to RDP/SSH sessions; instead, users must connect to the gateway and then use a separate RDP or SSH client to reach the VM. While this is a valid network-level access technique, it introduces client deployment, authentication, and compatibility overhead that Azure Bastion avoids, making it less appropriate for this scenario.

Go deeper

AZ-500 Secure networking Practice Question

Why each option matters

Option-by-option breakdown

Related to this question