This chapter covers Azure Virtual Machine (VM) deployment, a core topic in the Compute domain (Objective 3.1) of the AZ-104 exam. Approximately 15-20% of exam questions touch on VM deployment, sizing, networking, and management. You will learn the full lifecycle of creating a VM, including choosing the right size, configuring disks, networking, and high availability options. Mastery of this content is essential for passing AZ-104.
Jump to a section
Deploying an Azure VM is like constructing a custom building on a prepared plot. The building's foundation is the virtual network (VNet) and subnet—you must choose the right plot (region) and ensure it's zoned correctly (availability zone). The building's frame is the VM size (SKU) determining how many floors (vCPUs) and square footage (RAM) you have. The operating system is like the interior design—you pick from pre-designed templates (Azure Marketplace images) or bring your own blueprints (custom image). Just as a building needs a unique address (private IP) and optionally a public-facing street address (public IP), your VM gets a private IP from the subnet's address range. Disks are like storage rooms: the OS disk is the main storage for the building's core systems, while data disks are additional cabinets for tenant data. You can attach extra disks (data disks) up to the building's weight limit (VM size's max data disks). To connect remotely, you install a door (RDP/SSH) with a specific lock (password or SSH key pair). The building inspector (Azure Resource Manager) ensures all permits (RBAC roles) and blueprints (ARM templates) are in order. If you need high availability, you build twin buildings in different zones (availability zones) behind a load balancer. Scaling out means constructing identical buildings from the same blueprint (VMSS). Misconfiguring the subnet is like building on the wrong lot—your building won't get utilities (network connectivity).
What is an Azure Virtual Machine?
An Azure Virtual Machine (VM) is an infrastructure-as-a-service (IaaS) compute resource that provides virtualized server capabilities in the cloud. You have full control over the operating system, installed software, and configuration. Azure VMs are ideal for lift-and-shift migrations, custom applications, and scenarios requiring persistent storage and specific OS configurations.
Why Deploy VMs?
VMs offer flexibility unmatched by PaaS services. You can run any application that runs on Windows or Linux, customize the OS, and have direct administrative access. This is critical for legacy applications, custom software, or when you need to install drivers, agents, or third-party tools. However, VMs require more management overhead than PaaS alternatives.
How VM Deployment Works Internally
When you deploy a VM in Azure, the following happens at the infrastructure level:
Resource Allocation: Azure's fabric controller selects a physical host in the chosen region and availability zone (if specified) that has sufficient capacity for the requested VM size (vCPUs, RAM, temporary storage).
Network Attachment: The VM's virtual NIC (vNIC) is attached to a virtual network (VNet) and subnet. The vNIC receives a private IP address from the subnet's address range via DHCP. If a public IP is assigned, Azure's SDN maps that public IP to the private IP using 1:1 NAT.
Disk Creation: Azure creates the OS disk (managed disk by default) and attaches it as a SCSI device. The OS disk is initialized with the selected image (e.g., Windows Server 2022 Datacenter). Data disks are created and attached similarly.
Boot: The VM boots from the OS disk. The boot diagnostics service captures serial console output and screenshots to aid troubleshooting.
Agent Installation: The Azure VM Agent (for Windows) or Linux Agent (for Linux) is installed automatically on Marketplace images. This agent enables extensions, custom script execution, and backup integration.
Key Components and Defaults
#### VM Sizes - General Purpose (B, Dsv3, Dv3): Balanced CPU-to-memory. Ideal for testing, small databases, low-traffic web servers. Default size for many quick creates is Standard_D2s_v3 (2 vCPUs, 8 GB RAM). - Compute Optimized (Fsv2): High CPU-to-memory ratio. For batch processing, web servers, gaming. - Memory Optimized (Esv3, Ev3): High memory-to-CPU. For large databases, SAP HANA. - Storage Optimized (Lsv2): High disk throughput and I/O. For big data, SQL, NoSQL. - GPU (NC, NV): For heavy graphics rendering, machine learning. - Burstable (B-series): For workloads that don't need full CPU continuously. They accumulate CPU credits when idle and burst when needed. Default size: Standard_B1s (1 vCPU, 1 GB RAM).
Default Values:
Number of data disks: depends on VM size. Standard_D2s_v3 supports up to 4 data disks.
Max IOPS: Standard_D2s_v3 provides 3200 IOPS (uncached) and 12800 IOPS (cached) with premium storage.
Temporary disk: Each VM size includes a temporary SSD (D: on Windows, /dev/sdb on Linux). This disk is ephemeral and data is lost on deallocation. Default size for Standard_D2s_v3 is 50 GB.
#### Disks - OS Disk: Default size is 127 GB for Windows, 30 GB for many Linux images. You can change size during creation. - Data Disks: Up to 32,767 GB each. Managed disks are recommended: Standard HDD (up to 2000 IOPS), Standard SSD (up to 6000 IOPS), Premium SSD (up to 20,000 IOPS per disk). - Ephemeral OS Disk: Uses local SSD for faster read/write. Only supported for certain VM sizes (e.g., Dsv3, Esv3). Data is lost on deallocation.
#### Networking - Private IP: Assigned via DHCP from the subnet. Default is dynamic; you can set static. - Public IP: Optional. If assigned, you can choose between dynamic (changes on stop/start) and static (persists until deleted). - Accelerated Networking: Enables SR-IOV for lower latency and higher throughput. Supported on most VM sizes. Default is disabled; you must enable it during creation or later. - Network Security Group (NSG): Applied to the subnet or vNIC. Default inbound rules allow RDP (3389) and SSH (22) only if you specified them during creation. All other inbound traffic is denied by default.
#### Availability Options - Availability Set: Logical grouping of VMs to protect against rack-level failures. VMs are placed on different fault domains (up to 3) and update domains (up to 20). SLA: 99.95%. - Availability Zone: Physical separation within a region. Each zone is an isolated datacenter. SLA: 99.99%. - Virtual Machine Scale Sets (VMSS): For auto-scaling and load balancing. Supports manual and autoscale rules.
Configuration and Verification Commands (Azure CLI)
Create a VM:
az vm create \
--resource-group myRG \
--name myVM \
--image UbuntuLTS \
--admin-username azureuser \
--ssh-key-value ~/.ssh/id_rsa.pub \
--size Standard_D2s_v3 \
--vnet-name myVNet \
--subnet mySubnet \
--public-ip-address myPublicIP \
--nsg myNSG \
--zone 1List VM sizes in a region:
az vm list-sizes --location eastus --output tableResize a VM (requires deallocation if not in same hardware family):
az vm deallocate --resource-group myRG --name myVM
az vm resize --resource-group myRG --name myVM --size Standard_DS3_v2
az vm start --resource-group myRG --name myVMAttach a data disk:
az vm disk attach \
--resource-group myRG \
--vm-name myVM \
--name myDataDisk \
--size-gb 128 \
--sku Premium_LRSEnable boot diagnostics:
az vm boot-diagnostics enable \
--resource-group myRG \
--name myVM \
--storage https://mystorageaccount.blob.core.windows.net/How It Interacts with Related Technologies
Azure Backup: VM backup uses the VM agent to create application-consistent snapshots. You can back up entire VM or selected disks.
Azure Site Recovery: Replicates VMs to a secondary region for disaster recovery.
Azure Load Balancer: Distributes traffic to VMs in the same backend pool. Requires health probes (HTTP/TCP).
Azure DNS: Custom domain names for public IPs.
Azure Policy: Enforces rules on VM SKUs, disks, tags, etc.
Azure Monitor: Collects metrics (CPU, memory, disk IO) and logs. Alerts can trigger autoscale.
Common Pitfalls
Forgetting to deallocate before resize: If you resize a VM without deallocating, it may fail if the new size is on a different hardware cluster. Always deallocate first.
Using wrong disk SKU: Premium SSD requires a VM size that supports premium storage (e.g., DS-series, not D-series).
Not enabling accelerated networking: You must enable it at creation or later via CLI/PowerShell. It cannot be enabled on all sizes.
Ignoring temporary disk: Data on the temporary disk is lost on stop/deallocate. Do not use for persistent data.
Choosing wrong availability option: Availability sets protect against rack failures but not datacenter failures. For datacenter-level protection, use availability zones.
Choose Region and Resource Group
Select the Azure region where the VM will be deployed. This determines data residency, latency, and available VM sizes. Use regions close to your users. Also choose or create a resource group, a logical container for all VM resources (disks, NICs, public IPs). Resource groups help with management and billing. You cannot move a VM across regions without re-creating it.
Select VM Size and Image
Pick a VM size based on workload requirements. For production, use sizes that support premium storage and accelerated networking. For development, burstable B-series can save costs. Choose an OS image: Azure Marketplace images (Windows Server, Ubuntu, CentOS, etc.), custom images from Azure Compute Gallery, or a VHD uploaded to a storage account. The image determines the OS disk size and default configuration.
Configure Networking
Specify the VNet and subnet. If none exists, Azure can create a default VNet with a /24 subnet. The VM gets a private IP from the subnet. Optionally create a public IP (dynamic or static). Configure the NSG to allow inbound traffic (RDP/SSH). For production, use multiple NICs for separation of management and data traffic. Each NIC must be in a different subnet.
Configure Disks and Storage
Choose OS disk type: Standard HDD (low cost), Standard SSD (balanced), Premium SSD (high performance). For the OS disk, you can use ephemeral disks for stateless workloads. Add data disks for additional storage. Encryption at host is available (requires specific VM sizes). Managed disks are preferred for ease of management and high availability.
Set Administrative Credentials
For Windows VMs, provide a username and password (must be 12-123 characters with complexity). For Linux, provide a username and SSH public key (or password). Password authentication is less secure; SSH keys are recommended. You can also use Azure AD authentication for Windows VMs with domain join.
Configure High Availability and Management
Choose availability options: none, availability set, or availability zone. For production, use at least two VMs in an availability set or zones. Enable boot diagnostics for troubleshooting. Optionally enable managed identities for Azure resources to grant the VM access to Azure services without storing credentials. Add extensions like custom script or monitoring agent.
Review and Create
Review all settings. Azure performs validation checks (e.g., VM size availability, quota limits). If validation passes, click Create. Deployment takes a few minutes. You can monitor via Azure portal or CLI. After creation, connect using RDP or SSH. Verify network connectivity, disk mounts, and agent status.
Enterprise Scenario 1: Lift-and-Shift Migration of On-Premises SQL Server
A financial services company is migrating its on-premises SQL Server to Azure. They deploy a Standard_E8s_v3 VM (8 vCPUs, 64 GB RAM) with Premium SSD P30 disks (1 TB, 5000 IOPS) for the OS and data disks. They use availability zones (Zone 1 and Zone 2) for high availability, with SQL Server Always On Availability Groups. They configure accelerated networking for low latency. The VM is placed in a VNet peered with the corporate network via ExpressRoute. They use Azure Backup for daily backups. During testing, they discovered that the temporary SSD (E: drive) was not suitable for tempdb because it is ephemeral; they moved tempdb to a separate Premium SSD disk. Misconfiguration: initially they selected Standard_D8s_v3 without premium storage support, causing disk performance issues. They resized to E8s_v3 after deallocating.
Enterprise Scenario 2: Web Farm Scaling with VMSS
An e-commerce company deploys a Virtual Machine Scale Set (VMSS) of Standard_D2s_v3 VMs running Ubuntu with Nginx. They use autoscale rules based on CPU > 75% for 5 minutes to scale out, and CPU < 25% for 10 minutes to scale in. The VMSS is behind an Azure Load Balancer with a health probe on port 80. They use a custom image with the application pre-installed, stored in Azure Compute Gallery. They enable boot diagnostics and send logs to Log Analytics. During Black Friday, the scale set scaled to 100 instances. They hit a subscription vCPU quota (default 20 cores per region) and had to request a quota increase. They also learned that the autoscale cool-down period is 5 minutes by default, preventing rapid scaling.
Scenario 3: Dev/Test Environment with Burstable VMs
A startup uses B2s VMs (2 vCPUs, 4 GB RAM) for development servers. They accumulate CPU credits when idle and burst during builds. They use ephemeral OS disks to reduce costs, as VMs are frequently recreated. They store all persistent data in Azure Files. They use Azure DevTest Labs to manage quotas and auto-shutdown. A common mistake: they ran out of CPU credits during a build marathon, causing severe throttling. They switched to D2s_v3 for the build server and kept B2s for less intensive tasks.
AZ-104 Exam Focus on VM Deployment (Objective 3.1)
The exam tests your ability to choose the right VM configuration for given scenarios. Key areas: - VM Sizes: Know which size family is appropriate for compute-intensive vs. memory-intensive vs. general-purpose. Be able to identify that B-series is for burstable workloads, D-series for general, E-series for memory, F-series for compute. - Availability Options: Understand the difference between availability sets (fault/update domains) and availability zones (physical separation). Know the SLA percentages: 99.95% for sets, 99.99% for zones. The exam loves to ask: "You need 99.99% SLA, which option?" Answer: availability zones. - Disks: Know the difference between managed and unmanaged disks (managed are recommended). Know the performance tiers: Standard HDD, Standard SSD, Premium SSD, Ultra Disk. Premium SSD requires a VM size that supports premium storage (DS, ES, FS series). Ephemeral OS disk is for stateless workloads. - Networking: You must know that a VM gets a private IP from the subnet's range. Public IP can be dynamic or static. Accelerated networking requires specific VM sizes and must be enabled. - Common Wrong Answers: 1. "Availability set provides 99.99% SLA" – Wrong. It's 99.95%. Zones give 99.99%. 2. "You can resize a VM without deallocating if it's in the same family" – Wrong. You must deallocate even within the same family if the target size is on a different cluster. The exam may say "resize from D2s_v3 to D4s_v3 without deallocating" – that works because they are in the same family and cluster. But from D2s_v3 to E2s_v3 requires deallocation. 3. "Ephemeral OS disk persists data after deallocation" – Wrong. It is lost. 4. "You can attach a data disk to a VM while it's running without any preparation" – Partially true; you can attach a new disk online, but if it's an existing disk with data, you must detach first. - Numbers to Memorize:
Max data disks per VM size: varies, but typical for D2s_v3 is 4.
Default OS disk size: 127 GB for Windows.
Default temporary disk size: depends on size.
SLA: 99.95% for availability sets, 99.99% for zones.
Edge Cases:
You cannot change availability option (set vs. zone) after VM creation.
You cannot move a VM to a different region; you must recreate.
You can only enable accelerated networking at creation or later via CLI/PowerShell, not portal.
Eliminating Wrong Answers: If the question mentions "highest availability" and "datacenter failure", eliminate availability sets (they don't protect against datacenter failure). If it says "cost-effective for variable workloads", eliminate D-series and pick B-series. If it says "high disk I/O", eliminate Standard HDD.
VM sizes with 's' (e.g., DSv3) support premium storage; without 's' (e.g., Dv3) do not.
To resize a VM, you generally must deallocate it first; exception is resizing within the same family and cluster.
Ephemeral OS disk uses local SSD for better performance but data is lost on deallocation.
Availability sets provide 99.95% SLA; availability zones provide 99.99% SLA.
Accelerated networking must be enabled at creation or via CLI/PowerShell; not all sizes support it.
Managed disks are the default and recommended; unmanaged disks require storage accounts.
You can attach up to 64 data disks per VM, but the actual limit depends on the VM size.
Boot diagnostics require a storage account to capture serial console output and screenshots.
VM agent is automatically installed on Marketplace images; it enables extensions and backup.
You cannot change availability set or zone after VM creation; you must recreate the VM.
These come up on the exam all the time. Here's how to tell them apart.
Availability Set
Protects against rack-level failures within a datacenter
SLA: 99.95%
Up to 3 fault domains and 20 update domains
VMs are placed in the same datacenter
No additional cost for the set itself
Availability Zone
Protects against datacenter-level failures
SLA: 99.99%
Each zone is a physically separate datacenter
VMs can be in different zones, increasing latency
Data transfer between zones incurs egress charges
Mistake
Azure VMs automatically scale to handle increased load.
Correct
VMs do not autoscale on their own. You must use Virtual Machine Scale Sets (VMSS) with autoscale rules. A single VM remains at its allocated size unless you manually resize it.
Mistake
You can change the VM size without deallocating the VM.
Correct
You can only resize without deallocating if the new size is available in the same hardware cluster. In practice, most size changes require deallocation. The Azure portal will tell you if deallocation is needed.
Mistake
The temporary disk (D: drive on Windows) is safe for persistent data.
Correct
The temporary disk is ephemeral and data is lost when the VM is stopped/deallocated or moved to a different host. It should only be used for temporary data like page files or tempdb.
Mistake
All VM sizes support premium storage.
Correct
Only VM sizes with 's' in their name (e.g., DSv3, ESv3, FSv2) support premium storage. Sizes without 's' (e.g., Dv3) do not support premium disks.
Mistake
Availability zones provide the same protection as availability sets.
Correct
Availability zones provide physical separation across datacenters within a region, protecting against datacenter failures. Availability sets protect against rack-level failures within a single datacenter. Zones offer higher SLA (99.99% vs 99.95%).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
First, identify your workload type: general purpose (D-series), compute-intensive (F-series), memory-intensive (E-series), storage-intensive (L-series), or burstable (B-series). Then, determine required vCPUs, RAM, and disk IOPS. Use Azure's VM sizing tool or Azure Advisor recommendations. For production, choose a size that supports premium storage and accelerated networking. Always test with representative load.
Yes, you can expand the OS disk size, but only by increasing it (not decreasing). You must stop the VM, then resize the disk via portal or CLI. After resizing, you must extend the partition within the OS. For Windows, use Disk Management or diskpart. For Linux, use parted or resize2fs.
Managed disks are the default and recommended. Azure manages the storage accounts and handles high availability. Unmanaged disks require you to create and manage storage accounts, and you are limited to 20,000 IOPS per storage account. Managed disks offer simpler management, better scalability, and features like disk encryption sets.
You can use Azure Bastion, a jump box VM in the same VNet, or configure a point-to-site VPN. Azure Bastion provides secure RDP/SSH access through the portal without a public IP. Alternatively, you can use a VPN gateway or ExpressRoute to connect from on-premises.
Stopping (power off) the VM from the OS does not deallocate it; you continue to pay for compute resources. Deallocating (from Azure portal/CLI) releases the compute resources, stopping billing for vCPUs and RAM. The disks and IPs (if static) are retained. You pay only for storage. Deallocation is required for resizing in most cases.
Yes, you can move a VM (and its associated resources) to a different resource group or subscription using Azure Resource Manager move. However, the VM must be deallocated during the move. The move is limited to within the same region. You cannot move a VM across regions.
First, ensure the VM size supports accelerated networking (e.g., D/DSv3, E/ESv3). Then, stop and deallocate the VM. Enable accelerated networking on the NIC using CLI: `az network nic update --name myNic --resource-group myRG --accelerated-networking true`. Then start the VM. Verify by checking the NIC properties.
You've just covered Azure Virtual Machine Deployment — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?