You're a great admin... on-prem. Now, become a great admin in the cloud and prove it by passing the Microsoft Certified: Azure Administrator Associate exam!
Creating a virtual machine in Azure involves setting up several key components that work together to provide a functional, secure, and performant computing environment. The process starts in the Azure portal where you select a resource group, give the VM a name, and choose a deployment region that determines where your virtual machine physically runs. You then pick an operating system image such as Windows Server or Ubuntu Linux, and create a local administrator account with a secure username and password that meets complexity requirements.
By default, a new VM can be accessed from the internet using Remote Desktop Protocol (RDP) for Windows or SSH for Linux, which can pose security risks if left open. To protect the VM, you should set Public inbound ports to None during creation and instead use Azure Bastion host for secure remote access without exposing the VM to the public internet. Network Security Groups (NSGs) add another layer of protection by creating rules that allow or deny traffic based on IP address, port, and protocol, while Azure Firewall provides centralized, stateful inspection and threat intelligence filtering for broader protection.
In the Disks section, you choose the type of OS disk such as Standard SSD or Premium SSD, which directly affects the VM's performance and cost. You also configure the VM to connect to a specific virtual network subnet, and it's best practice to place the VM in a subnet separate from other critical resources to avoid conflicts. For more complex setups, Azure virtual network peering can connect the VM to a subnet in a different virtual network, enabling communication across separate network environments.
A virtual machine's network identity comes from its connection to a Virtual Network (VNET) and a specific subnet within it. The Network Interface Card (NIC) is the virtual component that enables this network communication, and each NIC must be in the same Azure region and subscription as the VM it is attached to. You assign the VM's NIC two types of IP addresses: a Private IP address is required for internal communication within the VNET, while a Public IP address is optional and enables direct inbound access from the internet. For specialized roles like firewalls or routers, you can enable IP Forwarding on a NIC, allowing the VM to act as a Network Virtual Appliance (NVA).
The chosen VM size dictates the maximum network bandwidth and disk throughput the VM can achieve. For high availability, you can deploy VMs across Availability Zones, which are physically separate datacenters within an Azure region. For Generation 2 VMs, you can enable Trusted Launch, which uses a Virtual Trusted Platform Module (vTPM) and Secure Boot to protect the startup process from malware. Other important optimizations include enabling Disk Encryption for data-at-rest security and consulting Azure Advisor for recommendations on improving performance and reducing costs.
Azure Disk Encryption protects data at rest on virtual machines by encrypting both operating system and data disks using BitLocker for Windows machines and DM-Crypt for Linux machines. The encryption keys are managed through Azure Key Vault, which must be located in the same region and subscription as the virtual machines being protected—this regional alignment is critical because the encryption process requires the Key Vault and VM to communicate without crossing regional boundaries.
A system architecture showing how Azure Disk Encryption uses BitLocker or DM-Crypt on VM OS and data disks, with encryption keys managed and retrieved from an Azure Key Vault configured with soft-delete, purge protection, and access policies.
Before encrypting any virtual machine, you must create an Azure Key Vault to store your encryption keys, which acts as a cryptographic key management system protecting sensitive secrets using FIPS-validated hardware security modules. When creating the vault, you must enable the --enabled-for-disk-encryption parameter so the Azure Disk Encryption extension can retrieve keys during the boot process. For managed disks, it is mandatory to enable both soft-delete and purge protection on the Key Vault—soft-delete retains deleted keys for 90 days allowing recovery from accidental removal, while purge protection ensures deleted keys cannot be permanently erased until the retention period expires.
Administrators can enable encryption using Azure CLI, Azure PowerShell, or Resource Manager templates with the encryption process requiring a snapshot or backup of the VM beforehand to prevent data loss. When encrypting Linux virtual machines, the EncryptFormatAll feature can format and encrypt all data volumes, but must be used carefully to avoid accidental data erasure. Unlike Windows, disabling encryption on a Linux OS disk is not supported once applied, and during Linux OS volume encryption the VM should be considered unavailable to prevent file access issues that could block the process.
For additional security, you can use a Key Encryption Key (KEK) to wrap the disk encryption secret before storing it in the vault, providing envelope encryption that protects the secret even if the vault is accessed. Azure Disk Encryption only supports RSA keys and does not allow Elliptic Curve keys, with 2048-bit keys being standard while Windows Server 2022 and Windows 11 require 3072-bit or 4096-bit keys. Managing KEKs allows for easier key rotation without re-encrypting the entire disk, and all KEK and secret URLs must be versioned to meet Azure's security requirements.
Monitoring the encryption process uses the Get-AzVmDiskEncryptionStatus cmdlet or az vm encryption show command to verify the current state of disks. Common restrictions include lack of support for Basic tier VMs, ephemeral OS disks, and certain high-performance NVMe storage types. Before enabling encryption, you must ensure the VM has access to specific network endpoints for Azure storage and Key Vault, and on Linux systems disks must be mounted in /etc/fstab using persistent block device names with the "nofail" option to remain accessible after encryption.
Before moving a virtual machine, both the source and target subscriptions must reside within the same Microsoft Entra ID tenant, and the administrator performing the move needs Owner permissions to assign roles and manage identities. While virtual machines with managed disks can move easily, any unmanaged disks must be converted to managed disks first. Several configurations block VM movement: Virtual Machine Scale Sets with Standard SKU load balancers cannot be moved, VMs in an availability set must be moved together rather than individually, and marketplace VMs with attached plans cannot cross subscription boundaries without being deprovisioned and redeployed. You must also disable Azure Disk Encryption before moving across subscriptions, and any active resource locks must be removed.
Virtual machines rely on associated resources like Network Security Groups (NSGs), load balancers, and public IP addresses, and moving these dependent resources concurrently prevents breaking connections. The Azure Resource Mover tool can automatically validate dependencies and manage cross-region relocations. During the move, Azure locks the source resources preventing modifications and potentially causing brief downtime. After moving across regions, the VM receives a new public IP address because public IPs are region-specific and cannot travel, requiring manual updates to public DNS records and external firewalls.
Because resource IDs change during a move, existing Role-Based Access Control (RBAC) assignments become orphaned and must be recreated at the destination to restore access. If the VM uses a system-assigned managed identity, you must re-register it with dependent Azure services to restore automated authentication. For Azure Backup, you must unregister the VM from the original Recovery Services vault and set up protection in a new vault, while diagnostic settings require manual reconnection to the correct Log Analytics Workspace. Custom maintenance schedules and update configurations must also be reapplied to ensure the VM continues receiving updates properly.
Resizing an Azure virtual machine lets you scale resources up or down as workload demands change, though the process is disruptive because the VM must restart even without full deallocation. In many cases, the VM must be deallocated when the target size is not available on the current hardware cluster, which releases dynamic IP addresses but keeps OS and data disks intact. Administrators can perform resizing through the Azure Portal, Azure PowerShell (modifying HardwareProfile.VmSize and running Update-AzVM), or the Azure CLI (using az vm resize). Before starting, check availability with tools like Get-AzVMSize to confirm the target size is supported on the current hardware cluster.
Resizing VMs inside an Availability Set creates challenges if the new size is unavailable on existing hardware—all VMs in the set must be deallocated before any single member can resize. Administrators must track subscription quotas limiting total cores per region, requiring a formal support request for limit increases when quotas are reached. Certain architectural constraints prevent direct resizing between VM families, such as moving from a size with a local temporary disk to one without, or switching from SCSI-based controllers to NVMe-enabled ones. Using Azure Capacity Reservations can reserve compute resources in the target region to reduce production risks during resizing.
Different VM sizes offer varying levels of compute power, memory, and storage capabilities, with cost influenced by CPU cores, memory, storage type, and usage patterns. Key performance factors include the number of CPU cores (more cores handle more simultaneous processes), memory size (higher memory aids memory-intensive applications), and disk I/O (SSDs and premium storage speed up data access). Azure Advisor provides cost optimization recommendations by identifying underutilized VMs that are candidates for downsizing. Choosing the optimal VM size involves trade-offs: high IOPS and throughput suit data-intensive applications while general-purpose VMs are more cost-effective for less demanding work.
Azure VM sizes are grouped into series optimized for specific workloads: general purpose series like D and B provide balanced CPU-to-memory ratios for testing and development; compute optimized series like F offer high CPU-to-memory ratios for batch processing and web servers; memory optimized series like E, M, and HX are designed for in-memory databases and big data analytics; storage optimized series like Lsv3 deliver high disk throughput for data warehousing; and GPU accelerated series like NC and NV incorporate graphics processors for video editing and deep learning. The naming convention conveys family, subfamily, vCPU count, and additional features like premium storage or specific CPU vendors.
Azure offers several managed disk types with different performance and cost characteristics: Standard HDD disks are lowest-cost for workloads tolerating higher latency like backups; Standard SSD disks offer better reliability at moderate cost for web servers; Premium SSD disks deliver high performance with low latency for production databases; and Azure Ultra Disks are designed for the most demanding workloads like SAP HANA with the ability to dynamically adjust IOPS and throughput without restarting the VM. Ultra Disks cannot be used as OS disks, cannot be converted from other types, do not support caching or Azure Disk Encryption, and only support deployment to a single VM within an availability zone.
An Azure VM uses three primary disk roles: the OS disk contains the operating system and is attached at creation, data disks store application data and can be attached during or after creation, and a temporary disk provides short-term non-persistent storage. You can expand data disk capacity live without stopping the VM, but expanding an OS disk requires deallocating the VM first followed by extending the partition and file system within the OS. Disk caching settings significantly impact I/O performance: ReadOnly caching works well for frequent read operations, while None provides best performance for write-heavy workloads like database logs.
A snapshot is a point-in-time, read-only copy of a disk used for backup and recovery, and can be full or incremental (storing only changes since the last snapshot). For multi-disk VMs, application-consistent snapshots coordinate across all disks to ensure data integrity. A VM Restore Point captures all managed disks attached to a VM at once, while Azure Disk Backup automates periodic incremental snapshots according to a defined policy.
Azure Disk Encryption (ADE) protects data at rest using BitLocker for Windows and DM-Crypt for Linux, integrating with Azure Key Vault for key management with options for Azure-managed or customer-managed keys. Beyond ADE, Server-Side Encryption (SSE) automatically encrypts data when stored on Azure's physical disks, while encryption at host provides end-to-end encryption on the VM host before writing to storage and can encrypt temporary disks and caches. Azure role-based access control (RBAC) controls who can manage disks and encryption keys by assigning specific roles to users, groups, or applications.
For high-availability solutions, shared disks allow an Azure managed disk to be attached to multiple VMs simultaneously in a cluster configuration, necessary for workloads like Windows Server Failover Clustering. To protect against zonal failures, use zone-redundant storage (ZRS) for disks and deploy VMs across availability zones.
High availability and fault tolerance ensure VMs and workloads stay running even when hardware fails, maintenance occurs, or disasters happen. Azure offers three main strategies: availability zones are physically separate datacenters within a region each with independent power, cooling, and networking, providing up to 99.99% uptime when VMs are deployed across multiple zones; availability sets group VMs so Azure can distribute them across fault domains (different physical racks with separate power and network) and update domains (groups that reboot together during maintenance), providing 99.95% uptime; and Virtual Machine Scale Sets (VMSS) deploy and manage load-balanced VMs that can automatically scale based on demand.
To create VMs in availability zones, you specify which zones to deploy into when creating the virtual machine—each zone is a separate physical location so a failure in one location does not affect others. For availability sets, Azure automatically distributes VMs across different fault domains and update domains, with fault domains protecting against hardware failures by separating VMs onto different racks, and update domains ensuring not all VMs restart simultaneously during planned maintenance. The general practice is to have at least two or three of each domain type for proper resilience.
For storage, Locally Redundant Storage (LRS) replicates data three times within a single datacenter, while Zone-Redundant Storage (ZRS) replicates across three availability zones to protect against datacenter failures, and Geo-Redundant Storage (GRS) replicates to a distant secondary region for disaster recovery. Use availability zones when you need protection against entire datacenter failures and want 99.99% uptime, and use availability sets when your region does not support zones, when you need extremely low network latency between VMs, or when 99.95% uptime meets your requirements. Align managed disks with fault domains of their parent VMs so storage does not become a single point of failure.
Administrators manage individual instances within a Virtual Machine Scale Set (VMSS) using Azure CLI or PowerShell, transitioning VMs through states like start, stop, restart, or deallocate. Choosing to deallocate is cost-effective because it releases underlying compute resources so you only pay for storage. When modifying a scale set model with a new OS image or configuration, the upgrade policy determines how updates apply: Automatic mode pushes changes simultaneously potentially causing downtime, Rolling mode updates in sequential batches pausing to verify stability, and Manual mode leaves existing instances untouched requiring individual updates.
Scale sets integrate with an Azure Load Balancer or Application Gateway using the Application Health extension to probe the application running inside the VM rather than just checking if powered on—if the probe detects an unhealthy state, the upgrade process pauses preventing bad configurations from rolling out. When deploying, administrators must choose between Uniform and Flexible orchestration modes, a foundational setting that cannot be changed after creation. Flexible orchestration is the modern standard supporting up to 1,000 VMs with different sizes, operating systems, and pricing models like Spot and on-demand instances.
Autoscaling allows scale sets to automatically adjust instance counts based on demand: scale out adds instances during traffic spikes to prevent slowdowns, while scale in removes instances when demand drops to lower costs. To set up autoscaling, define autoscale profiles with metric triggers monitoring CPU usage, memory consumption, or network traffic—for example, scaling out when average CPU exceeds 75% and scaling in when below 25%. Best practices include setting appropriate minimum, maximum, and default capacity limits, continuously monitoring triggering metrics to ensure alignment with user patterns, and distributing instances across multiple availability zones for resiliency during rapid scaling events.
To protect applications from hardware failures, scale sets distribute VMs across Availability Zones and Fault Domains, with availability zones being physically isolated datacenters and fault domains grouping VMs sharing physical racks. Enabling zone-redundant networking requires integrating a Standard SKU Load Balancer. For consistent software environments at massive scale, you can deploy up to 1,000 instances using custom images stored in the Azure Compute Gallery. After provisioning, automate software installation using VM Extensions like the Custom Script Extension or PowerShell DSC, and secure communication with other cloud resources using Managed Identities that register the scale set with Microsoft Entra ID for secure authentication without hardcoding credentials.
Prepare and test your skills
Prepare and test your skills
Availability Zones deploy virtual machines across physically separate datacenters within an Azure region to protect against datacenter failures and deliver up to 99.99% uptime. In contrast, an Availability Set distributes virtual machines across separate physical racks using fault domains and update domains to guard against hardware failures and planned maintenance, providing up to 99.95% uptime. Availability Zones protect against entire datacenter outages, whereas Availability Sets are suited for regions without zone support or for workloads requiring extremely low network latency.
The Azure Key Vault must reside in the same subscription and Azure region as the virtual machine and have the setting enabled for disk encryption so keys can be retrieved during boot. It is also mandatory to enable soft-delete, which retains deleted keys for 90 days, along with purge protection to prevent permanent deletion during that retention period. Additionally, the vault must use RSA encryption keys because Elliptic Curve keys are not supported for disk encryption.
No, expanding an operating system disk requires deallocating the virtual machine before the capacity, partition, and file system can be extended. In contrast, data disk capacity can be expanded live without stopping or deallocating the virtual machine.
An Azure Virtual Machine Scale Set supports three upgrade modes that apply updates simultaneously, in sequential batches, or individually upon manual request. Automatic mode pushes changes to all instances at the same time and can cause downtime, while Rolling mode updates instances in sequential batches and pauses between them to verify application stability. Manual mode leaves existing instances untouched when the scale set model changes, requiring an administrator to apply updates to each instance individually.
StudyCerts
StudyCerts