Troubleshooting Lab: Implement Azure Bastion
Diagnostic Scenarios
Scenario 1 — Root Cause
An administrator is trying to deploy Azure Bastion in a production VNet called vnet-prod in the East US region. The VNet has the following subnets already created:
| Subnet | CIDR Prefix |
|---|---|
| snet-frontend | 10.0.1.0/24 |
| snet-backend | 10.0.2.0/24 |
| snet-bastion | 10.0.3.0/27 |
| snet-management | 10.0.4.0/26 |
The administrator selects the snet-bastion subnet as the deployment target. The deployment fails with the following message:
Error: AzureBastionSubnet requires an address prefix of at least /26.
The current prefix /27 is too small.
He notices that the snet-management subnet has a /26 prefix and considers migrating Bastion to it. The security team informs that the NSG associated with snet-management blocks all inbound traffic that is not from the 10.0.0.0/8 range. The account used for deployment has the Contributor role on the subscription.
What is the root cause of the deployment failure?
A. The Contributor role doesn't have permission to create Azure Bastion resources; the Owner role or a custom role with specific network permissions is required.
B. The selected subnet has a /27 prefix, which is insufficient for Azure Bastion, and the subnet name is not AzureBastionSubnet, which is mandatory.
C. The NSG associated with the subnet blocks the necessary traffic for Azure Bastion's control plane, preventing deployment.
D. The /27 prefix is insufficient for Azure Bastion, which requires at least /26.
Scenario 2 — Action Decision
The operations team identified that Azure Bastion deployed in vnet-hub with Standard SKU cannot reach VMs in vnet-spoke-01. The peering between the two VNets exists and is in Connected state on both sides. The Allow forwarded traffic option is enabled. The team confirms that VMs in vnet-spoke-01 respond normally to internal connections originated from other VMs in the same VNet.
The cause has been identified: the Allow gateway transit option is not enabled on the peering from the vnet-hub side, and the Use remote gateways option is not enabled on the vnet-spoke-01 side.
The environment is in production. Changing peering configurations causes a brief connectivity interruption between VNets during reconfiguration. There is a maintenance window scheduled in 4 hours. The manager requests that Bastion access to vnet-spoke-01 VMs be restored urgently, without waiting for the window.
What is the correct action to take at this moment?
A. Deploy a second Azure Bastion directly in vnet-spoke-01, as this solves the problem without changing the existing peering and without production impact.
B. Immediately fix the peering options on both VNets outside the maintenance window, as the impact is minimal and urgency justifies the action.
C. Wait for the maintenance window to fix the peering options, as the change causes interruption and the environment is in production.
D. Disable and recreate the complete peering between VNets to ensure all options are applied correctly.
Scenario 3 — Root Cause
An analyst reports that when trying to connect to a Windows VM via Azure Bastion through the Azure portal, the session opens normally, but the Upload/Download file button doesn't appear in the RDP session toolbar. Other team members report the same behavior. Bastion is operational and all other connections work normally.
The administrator checks the environment and collects the following information:
Bastion Name: bastion-prod
SKU: Basic
Location: Brazil South
Provisioning State: Succeeded
Scale Units: 2
Public IP SKU: Standard
The network team informs that the AzureBastionSubnet NSG was recently reviewed and all mandatory rules are present and correct. The target VM runs Windows Server 2022 and has the Azure agent installed and updated.
What is the root cause of the observed behavior?
A. The AzureBastionSubnet NSG is blocking the data channel required for file transfer, even though mandatory rules are present.
B. The Azure agent on the target VM needs to be updated to a version that supports file transfer via Bastion.
C. The Basic SKU doesn't support file transfer in RDP sessions; this feature is only available in Standard SKU or higher.
D. The scale unit configured as 2 is insufficient to enable advanced features like file transfer.
Scenario 4 — Diagnostic Sequence
An administrator receives the following report: "I can't connect to any VM through Azure Bastion. The portal opens the connection screen, but after entering credentials, the session doesn't establish and a blank screen appears."
The administrator needs to diagnose the problem. The available investigation steps are:
- Check if the Bastion Provisioning State is Succeeded in the Azure portal
- Check if the target VM is in Running state and with responsive Azure agent
- Confirm if the AzureBastionSubnet NSG has all mandatory inbound and outbound rules
- Test connection with a second different VM to isolate if the problem is VM-specific or Bastion-specific
- Check Bastion diagnostic logs for recorded session errors
What is the correct investigation sequence?
A. 1 → 3 → 2 → 4 → 5
B. 2 → 4 → 1 → 3 → 5
C. 1 → 2 → 4 → 3 → 5
D. 3 → 1 → 2 → 5 → 4
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The error message explicitly states that the /27 prefix is insufficient, which confirms half of the problem. However, the more complete error and the real root cause involve two requirements violated simultaneously: the inadequate prefix (/27 instead of /26) and the incorrect subnet name (snet-bastion instead of AzureBastionSubnet). Azure Bastion requires both to accept deployment.
Alternative D only identifies the prefix problem and ignores the name requirement, which is equally mandatory. Trying to fix only the prefix would result in another immediate failure due to incorrect name.
Alternative C is the irrelevant information purposely inserted: the snet-management NSG is irrelevant because Bastion is not being deployed on that subnet, and NSGs don't prevent deployment, only subsequent operational traffic.
Alternative A is incorrect because the Contributor role has sufficient permissions to create network resources, including Azure Bastion. Acting based on distractor C would lead the administrator to spend time adjusting NSGs without ever resolving the actual deployment failure.
Answer Key — Scenario 2
Answer: A
The cause has already been identified in the scenario, so the reasoning here is about context constraint: the environment is in production, peering changes cause interruption, and urgency is declared. Deploying a second Azure Bastion directly in vnet-spoke-01 solves immediate access without touching existing peering and without generating interruption, respecting all constraints simultaneously.
Alternative B ignores the critical production constraint. Even if the impact is brief, acting outside the window in a production environment without explicit authorization represents an operational and governance risk.
Alternative C would be correct if there wasn't urgency declared by the manager, but the scenario explicitly states that access needs to be restored before the window.
Alternative D is the most dangerous: recreating peering completely interrupts connectivity between VNets until reestablished, worsening production impact instead of mitigating it.
Answer Key — Scenario 3
Answer: C
The output collected by the administrator clearly shows SKU: Basic. File transfer in RDP sessions is an exclusive feature of the Standard SKU. In Basic SKU, the session works normally for interactive access, but without the advanced feature set that includes upload/download.
Alternative A is the irrelevant information from the scenario: the NSG was reviewed and is correct, and the scenario confirms this. Focusing on the NSG would be a classic error of diverting to the last changed point in the environment, even though it's not the cause.
Alternative B is incorrect because the Azure agent has no relation to Bastion's file transfer functionality; this functionality is controlled by the service SKU, not the VM state.
Alternative D is incorrect because scale units control simultaneous session capacity, not feature availability. Acting based on alternative A would lead the administrator to review and modify NSGs with no effect on the observed behavior.
Answer Key — Scenario 4
Answer: A
The correct sequence is 1 → 3 → 2 → 4 → 5, following progressive diagnostic logic from service to specific resource:
- Step 1 confirms if Bastion itself is operational before investigating anything else. If provisioning failed, all other steps are irrelevant.
- Step 3 validates Bastion's network layer. A misconfigured NSG on AzureBastionSubnet prevents all sessions, which is consistent with the reported symptom (no VM accessible).
- Step 2 checks the target VM state after confirming Bastion is healthy.
- Step 4 isolates whether the problem is VM-specific or service-general, refining the diagnosis.
- Step 5 consults logs only after exhausting directly observable checks, using them as confirmation or to identify causes not visible in previous steps.
Alternative B starts with the VM, which reverses the logic: checking the VM before confirming the service is operational wastes time when the cause may be systemic. Alternative D starts with the NSG before confirming Bastion state, which is also premature.
Troubleshooting Tree: Implement Azure Bastion
Color Legend:
- Dark blue: initial symptom, diagnostic entry point
- Medium blue: diagnostic question, branching decision
- Red: identified cause
- Green: recommended action or resolution
- Orange: intermediate validation or verification
When facing a real problem with Azure Bastion, start at the root node and answer each question based on what is directly observable in the portal or via CLI. Follow the path that corresponds to the actual environment state, without skipping steps. Red nodes indicate where the problem is; green nodes indicate what should be done. The orange node confirms that the resolution path was correctly traversed before ending the diagnosis.