SC-100 A company deploys Azure Bastion in a VNet Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  The Azure Bastion subnet size is /28.

  Why it's wrong here

  The Azure Bastion subnet must be a dedicated subnet named AzureBastionSubnet and requires a minimum size of /26 (with /25 recommended when using certain features like IP-based connections or larger scale). A /28 subnet provides only 11 usable IP addresses, which is insufficient for the Bastion service to deploy its internal load balancer and scale units, so the Bastion host would fail to provision entirely. Since the scenario describes an already-deployed Bastion, the subnet size cannot be the cause of a subsequent connectivity failure to a peered VNet.

• ✓

  The peered VNet does not have 'Allow Azure Bastion Communication' enabled on the peering connection.

  Why this is correct

  The 'Allow Azure Bastion Communication' setting on a VNet peering connection is specifically required for Bastion to communicate with resources in a peered VNet. This setting must be enabled on both sides of the peering relationship: the VNet that contains the Bastion host and the VNet that contains the target VM. If this setting is disabled on either side, the Bastion service cannot establish a session to the VM's private IP, even if other network paths are open. The peering setting is the explicit gate for cross-VNet Bastion access, making it the correct root cause.

• ✗

  The VM's subnet does not have an inbound NSG rule allowing RDP (3389) from the Azure Bastion subnet.

  Why it's wrong here

  While a VM's network security group (NSG) must allow inbound RDP (port 3389) from the Azure Bastion subnet to support Bastion connectivity, this is a separate prerequisite that does not override or replace the peering requirement. If the peering is misconfigured, the NSG rule would never be evaluated because traffic from the Bastion host cannot even reach the peered VNet. In this scenario, the missing NSG rule may be a future risk, but the immediate cause of the failure is the peering setting, not the NSG.

• ✗

  The VM does not have Azure AD authentication enabled.

  Why it's wrong here

  Azure Bastion supports multiple authentication methods including local username and password, SSH keys, and Azure AD authentication (via Azure AD for Windows VMs and Azure AD login for Linux). Azure AD authentication is an optional enhancement that requires the VM to be AAD-joined and may require additional role assignments; it is not a prerequisite for Bastion to connect. Even without Azure AD authentication, Bastion can successfully connect using standard credentials, so the absence of Azure AD authentication cannot explain the connectivity failure.

Go deeper

Related to this question