This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure compute (20–25%)
   --> Implement security for servers and virtual machines (VMs)
      --> Plan and implement Azure Bastion

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Azure Bastion is a fully managed Azure platform service that provides secure Remote Desktop Protocol (RDP) and Secure Shell (SSH) connectivity to Azure virtual machines.

Instead of exposing RDP or SSH directly to the public internet, administrators connect to Azure Bastion through the Azure portal or, when supported, through a native RDP or SSH client. Bastion then connects to the target virtual machine over its private IP address.

Azure Bastion is particularly useful for reducing the attack surface of administrative access to virtual machines. It helps eliminate the need to assign public IP addresses to VMs solely for remote management.

For the SC-500 exam, you should understand:

• Why Azure Bastion is used.
• How Bastion is deployed in a virtual network.
• The purpose of the AzureBastionSubnet.
• Bastion SKU differences.
• Browser-based and native-client connections.
• Private-only Bastion deployments.
• Bastion integration with network security controls.
• How to select the appropriate SKU.
• Common deployment and connectivity problems.

Why Azure Bastion Is Important

Traditional remote administration often requires exposing:

• RDP on TCP port 3389.
• SSH on TCP port 22.

Exposing these ports directly to the internet increases the attack surface and can make virtual machines targets for:

• Password attacks.
• Credential stuffing.
• Brute-force attacks.
• Exploitation of protocol vulnerabilities.
• Port scanning.
• Automated reconnaissance.

Azure Bastion provides an alternative administrative access pattern:

1. The administrator signs in to Azure.
2. The administrator selects a virtual machine.
3. The administrator chooses Connect > Bastion.
4. Azure Bastion establishes the RDP or SSH connection.
5. The session is presented through the browser or a supported native client.
6. The VM is accessed through its private IP address.

The target VM does not need:

• A public IP address.
• An RDP or SSH agent.
• Special client software for browser-based access.
• Direct internet exposure of management ports.

Bastion is therefore a network-security control for administrative access, not a replacement for identity security or VM hardening.

Azure Bastion Architecture

Dedicated Bastion Deployment

For the Basic, Standard, and Premium SKUs, Azure Bastion is deployed into a dedicated subnet named:

AzureBastionSubnet

The subnet must be reserved for Azure Bastion. Other Azure resources should not be deployed into it.

For dedicated Bastion deployments, Microsoft recommends a subnet of at least /26 to support scaling and future feature requirements. The subnet can be larger, such as /25 or /24.

A typical architecture is:

Administrator
     |
     | HTTPS/TLS
     v
Azure Bastion
     |
     | Private RDP or SSH
     v
Azure Virtual Machine

The VM can remain without a public IP address.

Bastion in a Hub-and-Spoke Network

Azure Bastion can support connections to VMs in:

• The same virtual network.
• Peered virtual networks, when supported by the selected SKU and architecture.

A common enterprise design is to deploy Bastion in a central hub virtual network and use virtual network peering to access VMs in spoke virtual networks.

This allows an organization to centralize administrative access instead of deploying a separate Bastion resource in every spoke.

The selected SKU must support virtual network peering. The Developer SKU does not support peered virtual network connections.

Azure Bastion SKUs

Azure Bastion provides four SKUs:

• Developer.
• Basic.
• Standard.
• Premium.

The SKU affects:

• Cost.
• Deployment architecture.
• Number of supported connections.
• Scaling.
• Native-client support.
• File transfer.
• Custom ports.
• Shareable links.
• Session recording.
• Private-only deployment.

Developer SKU

The Developer SKU is intended for development and testing.

Characteristics include:

• No additional Bastion hourly charge.
• Shared infrastructure.
• One VM connection at a time.
• Browser-based access.
• Support for RDP to Windows VMs.
• Support for SSH to Linux VMs.
• No virtual network peering.
• Limited feature set.
• Availability only in selected regions.

The Developer SKU is not intended for production workloads because it uses shared infrastructure and supports only one VM connection at a time.

Use Developer when:

• The environment is for development or testing.
• Cost is a major consideration.
• Only occasional browser-based access is required.
• Advanced features are unnecessary.
• The region supports the Developer SKU.

Basic SKU

The Basic SKU provides a dedicated Bastion deployment with fixed capacity.

It supports:

• Browser-based RDP.
• Browser-based SSH.
• Connections to VMs in the same or peered virtual networks.
• Dedicated Bastion infrastructure.

The Basic SKU does not provide several advanced capabilities, including:

• Native-client connections.
• Shareable links.
• IP-based connections.
• Custom inbound ports.
• File transfer through the native client.
• Configurable host scaling.

Basic is appropriate when an organization needs a dedicated production deployment but does not require advanced connection features.

Standard SKU

The Standard SKU includes the Basic features and adds advanced capabilities such as:

• Native RDP and SSH client connections.
• Configurable host scaling.
• Shareable links.
• IP-based connections.
• Custom inbound ports.
• File upload and download.
• Higher connection capacity.
• Ability to configure additional Bastion features.

The Standard SKU is appropriate when administrators need to connect using local RDP or SSH clients or when the organization needs greater scalability.

Premium SKU

The Premium SKU includes Standard features and adds:

• Session recording.
• Private-only deployment.
• No public IP address on the Bastion resource in a private-only architecture.

Premium is appropriate when an organization requires:

• High-security administrative access.
• Session audit trails.
• Compliance-oriented session recording.
• A fully private Bastion deployment.
• Stronger restrictions on internet exposure.

The Premium SKU is the most appropriate choice when the requirement explicitly states that Bastion itself must not have a public IP address.

SKU Comparison

The exact capacity depends on the SKU, number of Bastion instances, connection type, and current service limits. Standard and Premium support host scaling, while Basic provides fixed capacity.

Selecting the Correct SKU

Use the following decision process.

Choose Developer when:

• The workload is development or testing.
• One VM connection at a time is sufficient.
• No peered-network access is required.
• No advanced features are required.
• The region supports Developer.

Choose Basic when:

• A dedicated deployment is required.
• Browser-based RDP and SSH are sufficient.
• Fixed capacity is acceptable.
• Native-client access is not required.
• Session recording is not required.
• Private-only deployment is not required.

Choose Standard when:

• Native RDP or SSH clients are required.
• File transfer is required.
• Custom ports are required.
• Shareable links are required.
• IP-based connections are required.
• Host scaling is required.
• Higher connection concurrency is needed.

Choose Premium when:

• Session recording is required.
• Bastion must use a private-only deployment.
• The Bastion resource must not have a public IP address.
• Compliance requires administrative session audit trails.
• The workload has stringent security requirements.

A common exam clue is:

“The VM must not have a public IP address.”

This requirement alone does not necessarily require Premium. Basic, Standard, and Premium can provide access to VMs without public IP addresses.

A different requirement is:

“Bastion itself must not have a public IP address.”

That points to a Premium private-only deployment.

Deploying Azure Bastion

Deployment Prerequisites

Before deploying Bastion, verify:

• The target virtual network exists.
• The virtual network is in a supported region.
• The target VM is deployed in the same or a peered virtual network.
• The required subnet exists.
• The subnet is named AzureBastionSubnet.
• The subnet is at least /26 for dedicated deployments.
• The selected SKU supports the required features.
• The required public IP configuration is available.
• Network security rules do not block required Bastion traffic.
• The administrator has sufficient Azure permissions.

For Basic, Standard, and Premium deployments, the subnet is dedicated to Bastion.

Do not deploy virtual machines, Azure Firewall, NAT Gateway, or other unrelated resources into AzureBastionSubnet.

Deploying from the Azure Portal

A typical portal deployment process is:

1. Sign in to the Azure portal.
2. Open the target virtual network or virtual machine.
3. Select Connect > Bastion, or create a Bastion resource.
4. Select the appropriate subscription.
5. Select or create a resource group.
6. Select the target virtual network.
7. Select the Bastion SKU.
8. Configure the AzureBastionSubnet.
9. Configure the public IP address if required.
10. Configure optional advanced features.
11. Select Review + create.
12. Validate the configuration.
13. Select Create.

Dedicated Bastion deployments generally take longer to provision than the Developer SKU.

Public IP Requirements

For standard dedicated deployments:

• Basic requires a public IP address.
• Standard requires a public IP address.
• Premium can use a public IP address or a private-only deployment.

The public IP address is associated with Bastion, not with the target VM.

The target VM can remain accessible only through its private IP address.

For a private-only Premium deployment:

• Bastion has no public IP address.
• Administrative connectivity must use private network connectivity.
• The administrator must have an appropriate path into the virtual network, such as a corporate network connection, private connectivity, or another approved access mechanism.

Private-only Bastion is therefore useful for environments that require no internet-routable Bastion endpoint.

Connecting to Virtual Machines

Browser-Based Connections

Browser-based connections use the Azure portal and an HTML5 web client.

The administrator:

1. Opens the virtual machine in the Azure portal.
2. Selects Connect.
3. Selects Bastion.
4. Selects the connection protocol.
5. Provides the required credentials.
6. Selects Connect.

For Windows VMs, the default RDP port is usually:

3389

For Linux VMs, the default SSH port is usually:

22

Browser-based connections do not require a public IP address on the VM or special client software on the administrator’s computer.

RDP Connections

RDP is normally used to connect to Windows virtual machines.

The user must have the appropriate rights on the target VM. Depending on the authentication method, the user may need to be:

• A local administrator.
• A member of the Remote Desktop Users group.
• Assigned an appropriate Microsoft Entra VM login role.

SSH Connections

SSH is normally used to connect to Linux virtual machines.

The administrator may authenticate using:

• A username and password, where supported.
• An SSH private key.
• Microsoft Entra ID authentication, where supported and configured.

The VM must be configured to accept the selected authentication method.

Native-Client Connections

The native-client feature allows administrators to use the RDP or SSH client installed on their local computer instead of using only the browser-based client.

Native-client support requires:

• Standard or Premium SKU.
• Native-client support enabled.
• Appropriate VM and authentication configuration.
• Azure CLI for supported connection workflows.

Native-client connections can support additional capabilities, such as:

• Local RDP or SSH client use.
• Microsoft Entra authentication.
• File transfer for supported connection types.
• Custom ports.
• Multiple concurrent VM sessions.

Session recording is not available for native-client connections. Session recording is a Premium feature for supported browser-based sessions.

Native-Client Limitations

Important limitations include:

• Native-client support is not available with Developer or Basic.
• Native-client connections are not supported from Azure Cloud Shell.
• SSH private keys stored in Azure Key Vault cannot be used directly for native-client sign-in.
• The private key must be available as a file on the local computer when using that authentication method.
• Capabilities vary depending on the local client, target VM, protocol, and Bastion configuration.

Network Security Considerations

Azure Bastion reduces the need to expose RDP and SSH ports publicly, but network security rules still matter.

Network Security Groups

Network Security Groups can be used to control traffic to and from subnets and network interfaces.

When using Bastion, ensure that NSG rules do not unintentionally block:

• Required Bastion control-plane traffic.
• Bastion-to-VM RDP traffic.
• Bastion-to-VM SSH traffic.
• Required Azure platform communication.

For native-client configurations, administrators may use NSG rules to restrict access to required ports such as:

• TCP 22 for SSH.
• TCP 3389 for RDP.

Custom ports require Standard or Premium.

User-Defined Routes

User-defined routes are not supported on the Azure Bastion subnet.

This is important when designing a network that also contains:

• Azure Firewall.
• Network virtual appliances.
• Custom routing.
• Hub-and-spoke network topologies.

Bastion-to-VM communication is private, and traffic does not generally need to be forced through Azure Firewall by applying a user-defined route to AzureBastionSubnet.

Azure Firewall

Azure Firewall and Azure Bastion serve different purposes:

• Azure Bastion provides administrative RDP and SSH connectivity.
• Azure Firewall provides centralized traffic inspection and filtering.

They can be deployed in the same overall network architecture, but they should not be treated as interchangeable services.

Azure Bastion and Just-in-Time VM Access

Azure Bastion and Just-in-Time VM access solve related but different problems.

Azure Bastion

Azure Bastion:

• Provides a secure access path to VMs.
• Reduces the need for public IP addresses.
• Avoids exposing RDP and SSH directly to the internet.
• Provides browser-based or native-client connectivity.

Just-in-Time VM Access

Just-in-Time VM access:

• Opens management ports only when access is requested.
• Limits the duration of access.
• Creates temporary network security rules.
• Is useful for VMs that still require public management access.

Bastion is generally the better choice when the goal is to eliminate public management exposure altogether.

Just-in-Time access may be useful when a VM must retain a public IP address or when direct access is required for a specific operational scenario.

The two controls can be evaluated independently and may be used together where appropriate.

Azure Bastion and Point-to-Site VPN

Azure Bastion provides access to virtual machines through RDP and SSH.

A point-to-site VPN provides network-level access from an individual client into an Azure virtual network.

Use Azure Bastion when administrators need:

• RDP or SSH access to VMs.
• A browser-based administrative experience.
• No public IP address on the VM.
• A controlled access path to specific virtual machines.

Use point-to-site VPN when administrators need access to:

• Databases.
• Internal web applications.
• Storage services.
• Multiple private network resources.
• Other services that are not accessed through RDP or SSH.

A VPN provides broader network access, while Bastion focuses primarily on secure VM administration.

Managing Bastion Sessions

Depending on the SKU and connection method, Bastion may support:

• Copy and paste.
• Full-screen sessions.
• File upload.
• File download.
• Custom ports.
• Shareable links.
• Session recording.

Shareable Links

Shareable links allow users to connect to a specific VM without navigating through the Azure portal in the usual way.

They are available with Standard and Premium and should be governed carefully because they can simplify access distribution.

Use them only when:

• The recipient is authorized.
• The link is distributed securely.
• The organization understands the access implications.
• The link is revoked or allowed to expire when no longer needed.

Session Recording

Session recording is available with Premium for supported browser-based sessions.

It can help organizations:

• Review administrative activity.
• Support compliance requirements.
• Investigate suspicious behavior.
• Establish an audit trail for privileged access.

Session recording should not be assumed to apply to native-client sessions. Native-client sessions do not support session recording.

Monitoring and Troubleshooting

When Bastion connectivity fails, investigate the following areas.

Bastion Resource State

Check:

• Provisioning state.
• SKU.
• Region.
• Configuration settings.
• Health status.
• Availability.
• Recent deployment changes.

Virtual Network

Verify:

• The VM is in the expected virtual network.
• Peering is configured correctly.
• Peering is in a connected state.
• Address spaces do not overlap.
• Required routes are available.
• The VM has a private IP address.

Subnet

For dedicated deployments, verify:

• The subnet is named AzureBastionSubnet.
• The subnet is at least /26.
• No unrelated resources are deployed in the subnet.
• NSG configuration is compatible with Bastion.
• No unsupported user-defined routes are applied.

VM Configuration

Verify:

• The VM is running.
• The operating system supports the selected protocol.
• RDP or SSH is enabled.
• The required service is running.
• The VM’s guest firewall permits the connection.
• The user has the required permissions.
• The selected port is correct.

Authentication

Check:

• Username and password.
• SSH key.
• Microsoft Entra authentication configuration.
• VM login role assignments.
• Local group membership.
• Credential expiration.
• Conditional Access requirements.

SKU Features

A connection may fail or an option may be unavailable because the SKU does not support it.

Examples:

• Native-client option missing: use Standard or Premium.
• Custom port unavailable: use Standard or Premium.
• Session recording unavailable: use Premium for supported browser sessions.
• Private-only deployment unavailable: use Premium.
• Peered-VNet access unavailable: do not use Developer.

Common Mistakes to Avoid

Mistake 1: Deploying resources into AzureBastionSubnet

The Bastion subnet is reserved for Azure Bastion.

Mistake 2: Using a subnet that is too small

Dedicated Bastion deployments should use at least a /26 subnet to support current and future requirements.

Mistake 3: Assuming Basic supports native-client connections

Native-client connections require Standard or Premium.

Mistake 4: Assuming Premium is required just because the VM has no public IP

All dedicated Bastion SKUs can provide access to VMs without public IP addresses. Premium is required when Bastion itself must be private-only.

Mistake 5: Assuming Bastion replaces RBAC

Azure Bastion provides network access, but users still need appropriate permissions on the Bastion resource, virtual network, VM, and operating system.

Mistake 6: Applying unsupported user-defined routes to the Bastion subnet

User-defined routes are not supported on AzureBastionSubnet.

Mistake 7: Assuming session recording works with native clients

Session recording is not available for native-client connections.

Mistake 8: Using Developer in production

Developer is designed for development and testing and supports only one VM connection at a time.

Mistake 9: Ignoring VM-level firewalls

Bastion does not bypass the VM’s operating system firewall or authentication requirements.

Mistake 10: Confusing Bastion with a VPN

Bastion provides RDP and SSH access. A VPN provides broader network-level connectivity.

Key Takeaways

For the SC-500 exam, remember:

1. Azure Bastion provides secure RDP and SSH access to Azure VMs.
2. Bastion reduces the need to expose VM management ports to the internet.
3. Target VMs do not need public IP addresses.
4. Dedicated Bastion deployments use AzureBastionSubnet.
5. The dedicated subnet should be at least /26.
6. The Bastion subnet is reserved for Bastion.
7. Developer is intended for development and testing.
8. Basic provides dedicated browser-based access with fixed capacity.
9. Standard adds native clients, scaling, custom ports, file transfer, and other advanced features.
10. Premium adds session recording and private-only deployment.
11. Native-client support requires Standard or Premium.
12. Private-only Bastion requires Premium.
13. Session recording is not available for native-client sessions.
14. User-defined routes are not supported on the Bastion subnet.
15. Bastion and Just-in-Time VM access are different controls.
16. Bastion provides VM administration, while VPN provides broader network access.
17. VM-level permissions and firewalls still apply.
18. SKU selection should be based on required features, capacity, and security requirements.

Practice Exam Questions

Question 1

An organization wants administrators to connect to Azure VMs through the Azure portal without assigning public IP addresses to the VMs.

Which service should the organization use?

A. Azure Bastion
B. Azure DNS Private Resolver
C. Azure Application Gateway
D. Azure Load Balancer

Correct answer: A

Explanation: Azure Bastion provides browser-based RDP and SSH access to VMs through their private IP addresses. The VMs do not need public IP addresses for this access pattern.

Question 2

You are deploying a dedicated Azure Bastion resource. Which subnet configuration is required?

A. A subnet named GatewaySubnet with a /29 prefix
B. A subnet named AzureFirewallSubnet with a /27 prefix
C. A subnet named AzureBastionSubnet with at least a /26 prefix
D. A subnet named AppGatewaySubnet with a /28 prefix

Correct answer: C

Explanation: Dedicated Bastion deployments use a subnet named AzureBastionSubnet. A /26 or larger subnet is recommended and required for the supported dedicated deployment configuration.

Question 3

A development team needs free, browser-based access to one Azure VM at a time. The team does not need virtual network peering or advanced features.

Which Bastion SKU should you select?

A. Basic
B. Developer
C. Standard
D. Premium

Correct answer: B

Explanation: The Developer SKU is intended for development and testing, is available at no additional Bastion hourly charge, and supports one VM connection at a time.

Question 4

A production environment requires administrators to connect to VMs using the native RDP client installed on their local Windows computers.

Which minimum Bastion SKU is required?

A. Developer
B. Basic
C. Standard
D. None; native-client support is available with every SKU

Correct answer: C

Explanation: Native-client support requires the Standard or Premium SKU. Developer and Basic support browser-based connections but not native-client connections.

Question 5

A company requires Bastion itself to have no public IP address. Which configuration should be used?

A. Basic Bastion with a private VM IP address
B. Standard Bastion with a private VM IP address
C. Developer Bastion in a peered virtual network
D. Premium Bastion with private-only deployment

Correct answer: D

Explanation: Premium supports private-only deployment, in which Bastion does not use a public IP address. Other dedicated SKUs can access VMs privately but normally require a public IP address for Bastion.

Question 6

Which Bastion feature is available with Premium but not with Standard?

A. Browser-based SSH
B. Browser-based RDP
C. Session recording
D. Access to VMs in the same virtual network

Correct answer: C

Explanation: Premium adds session recording and private-only deployment. Browser-based RDP and SSH and same-VNet connectivity are available with lower dedicated SKUs.

Question 7

An administrator wants to apply a user-defined route to AzureBastionSubnet so that all Bastion traffic passes through an Azure Firewall.

What should the administrator know?

A. User-defined routes are not supported on the Bastion subnet
B. User-defined routes are required for every Bastion deployment
C. User-defined routes are supported only with Developer
D. User-defined routes are required to connect to VMs in the same virtual network

Correct answer: A

Explanation: User-defined routes are not supported on AzureBastionSubnet. Bastion-to-VM communication is private and does not generally require forcing traffic from the Bastion subnet through Azure Firewall.

Question 8

An organization needs to connect to VMs in multiple spoke virtual networks from a Bastion resource deployed in a hub virtual network.

Which requirement is important?

A. The Bastion resource must use Developer
B. Virtual network peering must be configured, and the selected SKU must support peered-VNet connectivity
C. Every VM must have a public IP address
D. All VMs must be in the same subnet as Bastion

Correct answer: B

Explanation: Bastion can support VMs in peered virtual networks when peering is correctly configured and the selected SKU supports that capability. Developer does not support peered-VNet connections.

Question 9

A security team wants to use Azure Bastion to provide RDP and SSH access, but it also needs network-level access to private databases and internal web applications.

Which additional service may be appropriate?

A. Azure VPN Gateway with point-to-site connectivity
B. Azure Storage firewall
C. Azure Key Vault
D. Azure DDoS Protection

Correct answer: A

Explanation: Bastion focuses on RDP and SSH access to VMs. A point-to-site VPN provides broader network-level access to resources such as databases, storage, and internal applications.

Question 10

A company requires file transfer, custom inbound ports, host scaling, and native-client connections through Azure Bastion. Session recording is not required.

Which is the most appropriate minimum SKU?

A. Developer
B. Basic
C. Standard
D. Premium

Correct answer: C

Explanation: Standard supports native-client connections, file transfer, custom inbound ports, and configurable host scaling. Premium is unnecessary unless features such as session recording or private-only deployment are required.

Go to the SC-500 Exam Prep Hub main page