Troubleshooting Lab: Create a Virtual Machine
Diagnostic Scenarios
Scenario 1 — Root Cause
An administrator attempts to create a VM via Azure portal in the East US region, within the rg-financeiro resource group. The subscription is active and the administrator has the Contributor role on the resource group. The VNet vnet-financeiro already exists and has configured subnets. The OS disk will be managed by Azure (managed disk).
During creation, when clicking "Review + Create", the following error message is displayed:
The subscription does not have enough vCPU quota to create the resource.
Details: Subscription quota for Standard BSv2 Family vCPUs: 0 available, 4 required.
Location: East US
The administrator observes that other VMs of size Standard_B2ms were successfully created in the same region the day before. The network team confirmed that there are no NSG blocks on the destination subnet. The security team informed that a Microsoft Entra Conditional Access policy was updated the previous week.
What is the root cause of the error?
A) The Contributor role does not have permission to provision VMs; the Virtual Machine Contributor role is required.
B) The vCPU quota for the Standard BSv2 family is exhausted in the East US region for the subscription.
C) The Microsoft Entra Conditional Access policy blocked the administrator's access to Azure Resource Manager.
D) The managed disk is not available for the selected VM size in the East US region.
Scenario 2 — Action Decision
The operations team identified that a critical production VM, vm-erp-prod, is inaccessible via RDP. After investigation, the cause was confirmed: the inbound rule that allowed port 3389 on the NSG associated with the VM's network interface was accidentally deleted by a team member. The VM is running, the OS disk shows no errors, and the VNet is functioning normally.
The environment has the following restrictions:
- The VM cannot be restarted during business hours (8 AM to 6 PM)
- Access to the Azure portal is available
- The current time is 2:30 PM
- An Azure Bastion is provisioned in the same VNet
What is the correct action to take at this moment?
A) Recreate the inbound rule in the NSG allowing port 3389 from the necessary source.
B) Recreate the inbound rule in the NSG and restart the VM so that network changes are applied.
C) Connect to the VM using Azure Bastion via port 443, without changing the NSG, to perform necessary corrections.
D) Wait until the end of business hours to restart the VM and apply the new NSG.
Scenario 3 — Root Cause
A developer reports that a newly created Linux VM, vm-devapp-01, does not accept SSH connections. The VM was created via CLI with the following relevant parameters:
az vm create \
--resource-group rg-desenvolvimento \
--name vm-devapp-01 \
--image Ubuntu2204 \
--size Standard_D2s_v3 \
--admin-username devuser \
--authentication-type password \
--admin-password "P@ssw0rd2024!" \
--public-ip-sku Standard \
--nsg-rule NONE
The VM has "Running" status in the portal. The public IP address was assigned correctly. The developer attempted to connect with the command:
ssh devuser@40.112.72.134
The connection hangs indefinitely without returning authentication error. The network team confirmed that there is no corporate firewall blocking port 22. The subscription has sufficient quota for the chosen size.
What is the root cause of the problem?
A) Password authentication type is not compatible with Ubuntu images on Azure; SSH key usage is required.
B) Public IP with Standard SKU requires manual route configuration before accepting inbound traffic.
C) The --nsg-rule NONE parameter created the VM without any inbound rules in the NSG, blocking traffic on port 22.
D) The Standard_D2s_v3 size does not include public network interface by default and requires additional configuration.
Scenario 4 — Diagnostic Sequence
An administrator receives an alert that VM vm-webserver-02 is inaccessible via HTTP (port 80). The VM has "Running" status, has a public IP, and is on a subnet with associated NSG. The administrator needs to diagnose the problem.
The available investigation steps are:
- Step P: Check if the web service (IIS or nginx) is running inside the VM via management connection
- Step Q: Check the VM execution status in the Azure portal
- Step R: Inspect inbound rules of the NSG associated with the subnet and network interface
- Step S: Use Network Watcher's Connection Troubleshoot feature to test port 80 connectivity
- Step T: Check if there is an Azure Load Balancer in front of the VM with load balancing rules configured for port 80
Which diagnostic sequence is the most logical and efficient?
A) Q → R → S → T → P
B) P → Q → R → S → T
C) S → Q → T → R → P
D) R → T → Q → S → P
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The error message is explicit: the vCPU quota for the Standard BSv2 family is at zero for the East US region. This is the central point of diagnosis and leaves no ambiguity.
The determining clue is in the error output itself, which specifies the vCPU family and available value. The fact that Standard_B2ms VMs were successfully created does not contradict this: B2ms belongs to the Standard Bsv2 family, while the selected size belongs to the Standard BSv2 family, which is a different family with independent quota.
The information about the Microsoft Entra Conditional Access policy update is irrelevant information inserted intentionally. Conditional access policies affect authentication, not resource provisioning via quota. The NSG also has no relation to the presented error.
Alternative A is a common misconception: the Contributor role has full permission to create VMs. Alternative C represents the most dangerous reasoning error: attributing the failure to a recent security change without evaluating the objective error message. Alternative D is technically incoherent, as managed disks are supported on virtually all VM sizes.
Answer Key — Scenario 2
Answer: C
The cause has already been identified (NSG without RDP rule), but the critical restriction is that the VM cannot be restarted during business hours and the current time is 2:30 PM. Azure Bastion is available in the VNet and operates on port 443 (HTTPS), which does not depend on NSG rules for RDP.
Bastion allows immediate administrative access to the VM without exposing port 3389 and without requiring restart. This resolves the urgent operational need within the imposed restrictions.
Alternative A would be valid outside the restricted hours, but recreates direct RDP port exposure, which is not necessary if Bastion is available. Alternative B commits the double error of recreating the RDP rule and restarting during prohibited hours. Alternative D ignores that Azure Bastion solves the problem immediately without restart, wasting system availability.
The most dangerous distractor is A: it technically seems like the most direct solution, but ignores that Bastion already exists and is the correct approach for the context.
Answer Key — Scenario 3
Answer: C
The --nsg-rule NONE parameter instructs Azure to create the VM without adding any inbound rules to the automatically generated NSG. By default, when this parameter is not specified, the CLI adds an inbound rule for SSH (port 22). When using NONE, no rule is created, and the NSG blocks all inbound traffic, including port 22.
The observed behavior, the connection that hangs without returning authentication error, is consistent with an NSG blocking traffic: the TCP packet receives no response (no RST), different from an incorrect password, which would return authentication prompt.
The irrelevant information is the network team's confirmation about absence of corporate firewall. It eliminates an external layer hypothesis, but does not point to the real cause within the VM configuration.
Alternative A is false: password authentication is supported on Ubuntu images in Azure, although not recommended. Alternative B represents a misconception about Standard SKU public IP behavior: they are secure by default (require NSG), but do not require manual route configuration. Alternative D is technically incoherent for Azure architecture.
Answer Key — Scenario 4
Answer: A
The correct sequence is Q → R → S → T → P, which follows the logic of progressive diagnosis from simplest and external to most internal and specific.
Q first checks if the VM is running, as all network diagnosis is irrelevant if the VM is stopped. R inspects the NSG, which is the network barrier closest to the VM and the most common cause of port inaccessibility. S uses Network Watcher to validate end-to-end connectivity on port 80, confirming or discarding network hypotheses. T checks if there is a Load Balancer with incorrect or missing rules, which could intercept traffic before reaching the VM. P only makes sense as the last step: accessing the VM interior to check the service assumes that the entire network layer is functional.
Alternative B reverses the logic by starting inside the VM before validating if there is network connectivity. Alternative C starts with a network diagnostic tool without first confirming the VM's basic state. Alternative D starts by inspecting the NSG without first confirming that the VM is active, which may waste time investigating network of a stopped VM.
Troubleshooting Tree: Create a Virtual Machine
Legend:
| Color | Node Type |
|---|---|
| Dark Blue | Initial symptom (entry point) |
| Blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Validation or resolution confirmation |
To use this tree when facing a real problem, always start from the root node, which represents the observed symptom. At each decision node, respond based on what is directly verifiable in the portal, CLI, or command output. Follow the branch corresponding to the observed answer without skipping steps. Red nodes indicate that the cause has been isolated and require specific corrective action. Green nodes describe exactly what to do. Reach the orange validation node to confirm that the problem has been resolved before closing the diagnosis.