Azure Virtual Machines for AZ-104

Azure Virtual Machines (VMs) are the core Infrastructure as a Service (IaaS) offering in Microsoft Azure. They provide full control over the operating system, software, and configuration, making them the go‑to solution for migrating existing workloads, running specialised software, and building highly customised environments. As an Azure Administrator, you are responsible for the entire lifecycle of a VM: from initial deployment and configuration to ongoing management, monitoring, and availability.

This guide covers Azure Virtual Machines from an administrator’s perspective. You will learn how to choose the right VM size, configure storage and networking, ensure high availability, apply security best practices, and handle common operational scenarios—all of which are tested in the AZ‑104 exam.

Azure Virtual Machine Architecture Overview

Every Azure VM is built from a set of interconnected components. Understanding how these parts fit together helps you make informed configuration decisions and troubleshoot effectively.

• Virtual Machine – The compute instance that runs your operating system and applications. It is defined by its size (vCPUs, memory) and the OS image.
• VM Size – Determines the number of vCPUs, amount of memory, and temporary storage. The size also influences the maximum number of data disks and network interfaces.
• Operating System Image – A pre‑configured template from Azure Marketplace (Windows Server, Ubuntu, Red Hat, etc.) or a custom image you create.
• Managed Disks – Persistent block storage for the OS and data. Azure manages the physical storage accounts; you choose the disk type (Standard HDD, Standard SSD, Premium SSD, Ultra Disk).
• Network Interface (NIC) – The connection point between the VM and a virtual network. A VM can have one or more NICs, each with its own private IP address configuration.
• Virtual Network (VNet) – The isolated network where the VM resides. The VNet provides private IP address space, subnets, and connectivity to other Azure resources.
• Subnet – A segment of the VNet. Placing VMs in specific subnets allows you to apply network security and route traffic.
• Network Security Group (NSG) – A stateful firewall that filters traffic to and from the NIC or subnet based on rules you define.
• Public IP Address – Optional. Provides inbound connectivity from the internet to the VM, typically used for remote management (RDP/SSH) or hosting internet‑facing services.
• Private IP Address – Assigned automatically or manually from the subnet’s address range. Used for internal communication within the VNet or hybrid network.

These components work together: the VM size and image define the compute capacity, the managed disks store the data, the NIC connects the VM to the subnet, and NSGs control the traffic flow.

Azure VM Deployment Options

As an administrator, you will create VMs using multiple tools, each suited to different scenarios.

• Azure Portal – Interactive, browser‑based creation. Ideal for ad‑hoc deployments and learning. You configure every setting through the UI.
• Azure CLI – Command‑line tool for interactive management and scripting. Useful for automation and quick, repeatable tasks.
• Azure PowerShell – Alternative command‑line environment with PowerShell‑specific syntax and integration with other Microsoft products.
• ARM Templates – Declarative JSON files that define infrastructure and configuration. They support Infrastructure as Code and ensure consistent, repeatable deployments.
• Bicep – A domain‑specific language that compiles to ARM templates, offering a cleaner syntax and easier authoring experience.

For the AZ‑104 exam, you should be familiar with all of these methods, but practical proficiency with the portal, CLI, and PowerShell is especially important because many scenario questions assume you can identify the correct command or configuration path.

Choosing Azure VM Sizes

Azure offers a wide range of VM sizes, organised into families optimised for different workloads. The size you choose affects performance, cost, and the maximum number of data disks and NICs.

VM Family	Typical Workload	Characteristics
General Purpose (D‑series, B‑series)	Development, testing, small web servers	Balanced CPU‑to‑memory ratio. B‑series is burstable and cost‑effective for low‑average CPU usage.
Compute Optimised (F‑series)	Batch processing, network appliances, gaming	High CPU‑to‑memory ratio. Suitable for compute‑intensive tasks.
Memory Optimised (E‑series, M‑series)	Relational databases, in‑memory analytics, SAP HANA	High memory‑to‑CPU ratio. Large memory sizes available.
Storage Optimised (L‑series)	Big data, data warehousing, log processing	High disk throughput and low latency. Often use local NVMe storage.

How to choose: Start by evaluating the workload’s resource requirements (CPU, memory, disk IOPS). Then select the smallest size that meets those needs with headroom for growth. Use Azure Monitor to analyse actual utilisation and resize if necessary. Remember that you can change a VM’s size at any time, though it may require a restart.

Azure VM Storage and Disks

Persistent data for a VM is stored on managed disks. Each VM has an OS disk and can have one or more data disks. A temporary disk is also present but should never be used for persistent data—its contents can be lost during maintenance events.

Managed disk types:

• Standard HDD – Low‑cost magnetic storage for backups and non‑critical workloads.
• Standard SSD – Consistent performance at a moderate price. Suitable for web servers and dev/test.
• Premium SSD – High‑performance SSD for production workloads with high IOPS and low latency requirements. Required for many Azure SLA guarantees.
• Ultra Disk – Configurable IOPS and throughput independently of disk size. Designed for the most demanding data‑intensive workloads.

Administrator considerations:

• Performance planning – Choose the right disk type and size based on IOPS and throughput needs. Premium SSD performance scales with disk size.
• Availability – Managed disks support Azure Backup and can be configured with disk snapshots for point‑in‑time recovery.
• Security – Enable Azure Disk Encryption (BitLocker for Windows, DM‑Crypt for Linux) to protect data at rest. Control access to snapshots and managed disks with RBAC.
• Resizing – You can increase disk size while the VM is running, but you may need to expand the filesystem inside the OS.

Azure VM Networking

Each VM requires at least one network interface connected to a virtual network subnet. The NIC defines the private IP address and associated NSGs and public IPs.

Networking essentials:

• Virtual Network and Subnet – Plan IP address spaces carefully. VMs in different subnets can route traffic through user‑defined routes or a firewall.
• Private IP Address – Can be dynamic (assigned by DHCP) or static. Use static for VMs that act as DNS servers, domain controllers, or other infrastructure roles.
• Public IP Address – Allocate a public IP only when necessary. Instead, consider Azure Bastion for secure remote access without exposing the VM to the internet.
• Network Security Groups – A stateful packet filter. Define inbound and outbound rules based on source, destination, port, and protocol. Apply NSGs to NICs or subnets, or both.
• Accelerated Networking – Reduces latency and improves throughput by bypassing virtual switches. Enable it on supported VM sizes for high‑performance workloads.

Common administration tasks:

• Allowing required application traffic while blocking everything else.
• Troubleshooting connectivity by verifying NSG rules, effective routes, and IP configuration.
• Setting up VNet peering to connect VMs across different VNets without going over the public internet.

Azure VM Availability and Resilience

High availability for VMs is an administrator’s responsibility. Azure provides several mechanisms to prevent downtime caused by hardware failures, maintenance, or datacenter outages.

Availability Sets
Place VMs across multiple fault domains (physical racks) and update domains (groups that are rebooted together during maintenance). Availability sets provide a 99.95% VM connectivity SLA. Use them for workloads that require resilience within a single datacenter.

Availability Zones
Physically separate locations within an Azure region, each with independent power, cooling, and networking. Deploying VMs across zones offers a 99.99% VM connectivity SLA and protects against datacenter‑level failures. Zone‑to‑zone latency is low, making this suitable for mission‑critical applications.

Virtual Machine Scale Sets
For workloads that need to scale out and maintain availability automatically, VM Scale Sets combine the concepts of identical VMs, autoscaling, and fault‑domain distribution. They are covered in depth in the Azure Compute Services guide.

SLA‑driven design: If a workload requires 99.95% or higher, you must use availability sets, zones, or scale sets. A single VM without any availability configuration has no SLA and can experience unplanned downtime.

Managing and Operating Azure Virtual Machines

Ongoing operations are a core part of the AZ‑104 exam. Expect questions about:

• Start, stop, restart, deallocate – Know the difference. Stopping from the OS keeps the VM allocated and incurring costs. Deallocating releases the vCPUs and stops compute charges.
• Resizing – You can change a VM size while it is running (if supported) or stopped (deallocated). Understand that resizing may move the VM to different hardware.
• Patch management – Use Azure Update Manager or Azure Policy to assess and apply OS updates. Automate patching with maintenance configurations.
• Monitoring – Enable Azure Monitor and Log Analytics for CPU, disk, and network metrics. Create alerts for high utilisation or errors.
• Backup – Configure Azure Backup to create application‑consistent snapshots. Define backup policy with retention and recovery points.
• Troubleshooting – Use boot diagnostics, serial console, and VM reset options when the OS is unreachable. Redeploy the VM to new hardware if a host issue is suspected.
• Access management – Control administrative access with RBAC and Azure AD credentials (for Windows VMs) or SSH keys (for Linux). Use managed identities to let VMs access other Azure resources without credentials.

Azure VM Security Best Practices

Security is a shared responsibility. As an administrator, you must implement layers of protection:

• Identity – Avoid using local admin passwords where possible. Windows VMs can join Azure AD and use Azure AD authentication. Linux VMs should use SSH key pairs.
• Role‑based access control (RBAC) – Grant users the minimum permissions needed to manage VMs. Use built‑in roles like Virtual Machine Contributor.
• Just‑in‑Time (JIT) VM Access – Temporarily open management ports for authorised users, reducing the attack surface. JIT is a feature of Microsoft Defender for Cloud.
• Disk encryption – Use Azure Disk Encryption (BitLocker/DM‑Crypt) or encryption at host. Data is encrypted at rest by default at the storage level, but OS‑level encryption adds another layer.
• Network security – Place VMs in a VNet with NSGs. Avoid assigning public IPs directly; instead, use Azure Bastion or Azure Firewall for secure access.
• Least privilege – Apply the principle to service accounts, managed identities, and resource permissions. Regularly audit access.

AZ‑104 Real‑World Virtual Machine Scenarios

Scenario 1: Lift‑and‑Shift Migration

A healthcare company wants to move an on‑premises Windows Server application to Azure. The application uses a third‑party agent that requires full OS access and cannot be containerised. The business requires a 99.95% availability commitment.

Solution: Deploy two Windows Server VMs into an availability set. Place the VMs in a dedicated VNet with NSGs limiting inbound traffic to RDP from a jump host. Use Premium SSD managed disks for performance and Azure Backup for data protection. Implement Azure Disk Encryption for data at rest. This design meets the SLA and security requirements while preserving full OS control.

Scenario 2: High‑Availability Web Application

An e‑commerce platform requires 99.99% availability for its web front‑end. The application is stateless and uses Azure SQL Database.

Solution: Deploy VMs across two availability zones within a region. Place them behind an Azure Load Balancer (Standard tier) with a health probe to route traffic only to healthy instances. Use VM Scale Sets to adjust capacity automatically based on CPU load. This setup provides zone‑level resilience and meets the required SLA.

Scenario 3: Connectivity Troubleshooting

A developer reports that a VM cannot connect to a back‑end database server on a different subnet. The database VM is running and accessible from other subnets.

Troubleshooting approach:

1. Check the effective NSG rules on the VM’s NIC to see if outbound traffic to the database port is blocked.
2. Verify the subnet’s NSG allows traffic from the source subnet.
3. Examine the route table to ensure traffic is not being forced to an appliance.
4. Test connectivity with Test-NetConnection or az network nic show-effective-route-table.
5. Review Azure Monitor logs for any dropped packets.

This structured method isolates the issue to network rules, routing, or service configuration.

Azure VM Common Mistakes

• Selecting incorrect VM sizes – Over‑provisioning wastes money; under‑provisioning hurts performance. Analyse actual workload patterns.
• Exposing VMs directly to the internet – Using a public IP with an open RDP/SSH port invites brute‑force attacks. Prefer Bastion or VPN.
• Ignoring availability requirements – A single VM without availability set or zone provides no SLA. Always design for the required uptime.
• Poor disk planning – Using Standard HDD for a high‑IOPS database leads to slow performance. Match disk type to workload.
• Insufficient monitoring – Without alerts, you may not notice a failing disk or full memory. Set up baseline monitoring early.

Azure Virtual Machines vs Other Compute Services

Service	When to Use	When to Avoid
Azure VMs	Full OS control, legacy or specialised software, lift‑and‑shift migrations	When a managed platform (PaaS) can meet your needs with less operational overhead
Azure App Service	Web apps, APIs, containerised apps without custom OS requirements	When you need OS‑level access or unsupported software
Azure Functions	Event‑driven, short‑running tasks, automation	Long‑running processes, predictable high‑volume workloads (consider containerisation or VMs)
Azure Kubernetes Service	Microservices orchestration, complex containerised environments	Simple single‑container workloads (use ACI or Web App for Containers)
Azure Container Instances	Quick, isolated containers, batch jobs	Multi‑container orchestration, service discovery, scaling

Key takeaway: Choose VMs when you need control. Choose a managed service when you value simplicity and reduced management burden.

Relationship with Other AZ‑104 Topics

VMs do not live in isolation. Your understanding of them must connect with:

• Networking – VNet design, subnets, NSGs, load balancers, and DNS.
• Storage – Managed disks, disk types, backup, and file shares.
• Identity – RBAC, managed identities, Azure AD authentication.
• Monitoring – Metrics, alerts, diagnostic settings, Log Analytics.
• Security – JIT access, disk encryption, Defender for Cloud, Key Vault integration.

A well‑rounded AZ‑104 preparation treats these domains as an integrated system, not as separate checklists.

Continue Learning

• AZ‑104 Compute Services Overview – See how VMs fit into the broader compute landscape.
• AZ‑104 Labs – Practice deploying and managing VMs with hands‑on exercises.
• AZ‑104 Scenarios – Apply your VM knowledge to real‑world administration problems.
• AZ‑104 Resources – Study guides, checklists, and official Microsoft references.
• Azure Foundations – Core cloud concepts that underpin all Azure services.

Deep Dive: Azure Virtual Machines

For a more detailed Azure Virtual Machines guide, architecture explanation, implementation details, and advanced cloud computing concepts, see:

Azure Virtual Machines Guide - CloudComputingDevPro

https://cloudcomputingdevpro.com/azure/services/compute/azure-virtual-machines/