Setting Up Azure Key Vault
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.
Encrypting Virtual Machines
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.
Key Encryption Key Management
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 and Operational 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.
Move a virtual machine to another resource group, subscription, or region
Prerequisites and Limitations
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.
Dependencies and Network Considerations
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.
Post-Move Remediation
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.
Manage virtual machine sizes
Resizing Operations
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 Challenges and Constraints
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.
VM Series and Capabilities
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.
Manage virtual machine disks
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.
Disk Management Operations
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.
Snapshots and Backups
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.
Encryption and Security
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.
High Availability with Shared Disks
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.
Deploy virtual machines to availability zones and availability sets
High Availability Strategies
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.
Configuring Availability Zones and Sets
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.
Storage Redundancy and Deployment Best Practices
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.
Instance Lifecycle and Upgrade Policies
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.
Health Monitoring and Orchestration
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 Configuration
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.
Network and Post-Deployment Configuration
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.
StudyCerts
StudyCerts