Virtual Machines — AZ-104 Study Guide

Creating and configuring a VM

A VM create wizard asks you to settle a dozen things at once, but which of those are you actually stuck with later? Almost none, because an Azure virtual machine (VM) is not one object but several resources stitched together, each manageable on its own afterward. Azure runs and patches the physical host while you run and patch the guest operating system inside the VM (Azure VM overview^[1]). The diagram above groups those resources by the create-time decision each belongs to.

A VM is not one object but several resources stitched together at create time, each of which is a resource you can manage on its own afterward:

Image: the OS and any preinstalled software the disk starts from (a Marketplace image, your own image from an Azure Compute Gallery, or a custom managed image).
Size: the VM SKU, which fixes vCPU count, memory, and supported features (covered under Managing VM sizes below).
Networking: a virtual network and subnet, a network interface (NIC), an optional public IP, and a network security group (NSG) that filters traffic.
Authentication: for Linux, an SSH public key or a password; for Windows, a username and password. Choose key-based SSH for Linux to avoid a reusable password.
Disks: a managed OS disk plus optional managed data disks (covered under Managing VM disks).

Because each piece is a separate resource, the VM is malleable after creation: you can resize^[2] it, attach or detach data disks, or change its NIC without rebuilding. The one resource that is not persistent is the temp disk, a small local disk (drive D: on Windows, /dev/sdb on Linux) meant only for scratch data such as a page file; its contents are lost on deallocation or host migration, so never store anything you need to keep there.

A VM is several independent resources stitched together; only the temp disk is non-persistent (VM overview).

Availability: single VM, sets, zones, scale sets

This section explains how Azure turns redundancy into an SLA, and why the four options sit where they do in the diagram above. The shared model is simple: a single VM is one point of failure, and you reduce that risk by spreading VMs across infrastructure the platform fails independently. Every option below is a different granularity of that spreading, and the SLA you get is a direct consequence of which granularity you pick.

Start at the top of the diagram. If the workload must grow and shrink with demand, only a Virtual Machine Scale Set autoscales, so that branch ends there (the scale set is covered in its own section below). If not, the next question is whether the app must survive losing a whole datacenter.

Availability sets: fault and update domains

An availability set^[3] is a logical grouping of VMs inside a single datacenter. Azure assigns each VM in the set two coordinates:

A fault domain is a group of VMs that share a common power source and network switch, a hardware-failure boundary. An availability set spreads VMs across up to 3 fault domains, so one power or switch failure takes down only the VMs in that domain.
An update domain is a group of VMs rebooted together during planned host maintenance. A set has up to 20 update domains, and the platform reboots only one update domain at a time, giving it 30 minutes to recover before moving to the next.

With two or more VMs in an availability set you meet the 99.95% SLA; both the fault- and update-domain counts are fixed when the set is created and cannot be changed afterward (availability set overview^[3]). Because the spreading is within one datacenter, an availability set does not protect against a datacenter-wide outage. That is the reconciling distinction with zones below.

Availability zones: separate datacenters

An availability zone^[4] is a physically separate zone within a region, each with its own power, cooling, and networking; every zone-enabled region has three availability zones. Spreading a workload's VMs across two or more zones earns the 99.99% SLA and survives the loss of an entire datacenter, the protection an availability set cannot give. The trade-off is slightly higher VM-to-VM latency than an availability set, whose VMs sit in closer physical proximity (availability options^[5]). You cannot combine an availability set with zones: a set is a single-datacenter construct, so for zone redundancy you place VMs in zones directly (or use a zone-spanning scale set).

Single VM

A lone VM has no redundancy grouping, but if its OS and data disks are all Premium SSD or Ultra Disk, it still carries a 99.9% single-instance SLA. It is the right choice only when an outage of that one VM is acceptable. Both the availability set and the scale set are free constructs, you pay only for the VM instances they contain.

Choosing a VM availability option; SLAs from Availability options.

Managing VM disks and types

A VM's disks split into three roles and five managed types, and only certain combinations are allowed. The model in the diagram above: a VM always has one OS disk and one temp disk, and you attach zero or more data disks, and each of the persistent (managed) disks is independently assigned one of five performance types.

The three disk roles

OS disk: a persistent managed disk holding the bootable operating system; registered as drive C: (Windows) or mounted at /dev/sda (Linux).
Data disk: a persistent managed disk you attach for application data; a VM size caps how many data disks it can hold.
Temp disk: the non-persistent scratch disk introduced earlier; it is not a managed disk and its data is lost on deallocation, so it never holds anything durable.

Managed disks^[6] are block storage that Azure provisions, replicates, and manages as a resource, you don't manage the underlying storage account.

The five managed disk types

Ordered by performance ceiling (disk types^[7]):

Type	Max IOPS	Max throughput	OS disk?
Standard HDD	2,000 (3,000 with performance plus)	500 MB/s	Yes
Standard SSD	6,000	750 MB/s	Yes
Premium SSD	20,000	900 MB/s	Yes
Premium SSD v2	80,000	2,000 MB/s	No (data disk only)
Ultra Disk	400,000	10,000 MB/s	No (data disk only)

Three allowed-combination rules drive most disk questions, and each is the answer to a recognizable stem:

OS-disk eligibility. Only Standard HDD, Standard SSD, and Premium SSD can be an OS disk; Ultra Disk and Premium SSD v2 are data-disk-only, so a high-IOPS database VM pairs a Premium SSD OS disk with an Ultra or Premium SSD v2 data disk.
Ultra Disk + availability set. Ultra Disk does not support availability sets^[7], it supports only single-VM and availability-zone deployments. A scenario combining "Ultra Disk" with "availability set" is the trap; use an availability zone instead.
Resize and live tuning. Most managed disks can be expanded, and you can change a disk's type (for example Standard SSD to Premium SSD), but changing the type requires the VM to be deallocated. Ultra Disk and Premium SSD v2 are the exception: you can adjust their provisioned IOPS and throughput at runtime without detaching the disk.

Disk size is provisioned (billed) capacity, not used capacity, a 200-GiB Standard SSD maps up to the next offered tier (E15, 256 GiB) and is billed for that tier (disk billing^[7]).

A VM's three disk roles and the five managed disk types by IOPS ceiling; figures from Disk types.

Disk encryption: SSE, encryption at host, ADE

Which data each encryption layer actually covers is the single most-tested distinction in this subtopic. Building on the disk model from above, three encryption layers apply: all three encrypt the OS and data disks at rest; they differ in whether they also cover the temp disk and caches, and in where the encryption runs. The diagram above lays the three layers in rows so you can read each layer's coverage straight across, and where it runs on the left.

Server-side encryption (SSE): always on

Server-side encryption^[8], also called encryption-at-rest or Azure Storage encryption, is always enabled and cannot be turned off. It encrypts the OS and data disks as they persist on the storage cluster, using platform-managed keys by default or customer-managed keys (CMK) when you configure a Disk Encryption Set (DES). Its boundary is the key fact: SSE does not encrypt the temp disk or disk caches.

Encryption at host: extends SSE to temp disk and caches

Encryption at host^[8] is a VM option that enhances SSE so the temp disk, disk caches, and the data flowing between the VM and storage are all encrypted. The encryption happens on the Azure host, not inside the VM, so it does not consume the VM's CPU. It is Microsoft's recommended option for new VMs, and it is what Microsoft Defender for Cloud's "encrypt temp disks, caches, and data flows" recommendation looks for.

Azure Disk Encryption (ADE): in-guest BitLocker/DM-Crypt

Azure Disk Encryption^[8] (ADE) encrypts the OS and data disks from inside the guest OS, using BitLocker on Windows and DM-Crypt on Linux. ADE is integrated with Azure Key Vault to store the disk-encryption keys (with an optional key-encryption key, KEK), so an ADE deployment requires a Key Vault. That requirement is itself a common exam discriminator. Because it runs in the guest, ADE uses the VM's CPU and does not work for custom Linux images. ADE is scheduled for retirement on September 15, 2028; Microsoft directs new VMs to encryption at host instead.

How to tell them apart on the exam

Reconcile the apparent overlap with one question: does the temp disk need to be covered? If yes, SSE alone is insufficient: you need encryption at host (or ADE). If the stem says "without a guest agent" or "without using the VM's CPU," the answer is encryption at host, never ADE. If the stem explicitly names BitLocker or DM-Crypt, it is describing ADE. SSE is the right answer only when the requirement is plain encryption-at-rest of the managed disks with no mention of temp disk, caches, or in-guest encryption.

All three layers cover OS and data disks; only encryption at host adds the temp disk and caches (disk encryption).

Sizing, moving, and scale sets

This section covers the remaining administrative operations on a VM (resizing, moving it between scopes, and wrapping it in a scale set) and the exam patterns each one carries.

Managing VM sizes

A VM's size (SKU, e.g. Standard_D2s_v5) sets its vCPU count, memory, and feature support, and VM sizes are grouped into families by purpose: general purpose (B, D), compute optimized (F), memory optimized (E, M), storage optimized (L), and GPU (N) (VM sizes^[9]). You can resize^[2] a running VM to another size in the same family if the current host cluster supports the target size; if it doesn't, the portal requires the VM to be stopped (deallocated) first, and the VM restarts on a different cluster. The recurring constraint: not every size is available in every region, and resizing across families may force a deallocation.

Moving a VM

Three "moves" are distinct, and conflating them is the classic trap; the diagram above splits them by intent (move resources^[10]):

To another resource group or subscription: re-parents the VM only; the region is unchanged and the VM keeps running. During the move both the source and target resource groups are locked for up to four hours (no create/delete/resize). A cross-subscription move requires both subscriptions in the same Microsoft Entra ID (formerly Azure Active Directory) tenant, and the VM must move with its dependent resources (disks, NIC, virtual network) together.
To another region: a separate replication operation using Azure Resource Mover^[11] or Azure Site Recovery. The move-resource-group operation can never change a resource's physical region.

A move also changes the VM's resource ID (the path includes the resource group and subscription), so any scripts, dashboards, or RBAC role assignments referencing the old ID must be updated. Role assignments are not carried across and become orphaned.

Virtual Machine Scale Sets

A Virtual Machine Scale Set^[12] (VMSS) manages a group of VMs that autoscale horizontally: Azure adds instances (scale out) when an autoscale^[13] rule's metric (e.g. average CPU) crosses a threshold and removes them (scale in) when it falls, or on a schedule. This is the capability availability sets lack. Orchestration mode is fixed at creation and cannot be changed:

Flexible orchestration (recommended) manages standard IaaS VMs, supports up to 1,000 instances, can mix VM sizes, operating systems, and Spot with on-demand, and spreads instances across fault domains and/or availability zones. SLA is 99.95% across fault domains and 99.99% across multiple zones (orchestration modes^[14]).
Uniform orchestration deploys identical instances from one profile at very large scale, managed through scale-set-specific APIs rather than standard VM APIs.

Like availability sets, the scale set resource is free: you pay only for the running VM instances. Autoscaling is horizontal (more/fewer instances); changing an instance's size is vertical scaling and is a resize, not autoscale.

A resource-group or subscription move keeps the region; changing region is a separate replication, not a move.

VM availability and scaling options

Dimension	Single VM	Availability set	Availability zones	VM Scale Set (Flexible)
VM SLA	99.9% (Premium/Ultra disk only)	99.95% (2+ VMs)	99.99% (across 2+ zones)	99.95% across FDs / 99.99% across zones
Failure isolation	None	Fault + update domains, one datacenter	Physically separate datacenters in a region	Fault domains and/or zones
Automatic scaling	No	No	No (zone placement only)	Yes, metric or schedule autoscale
Max instances	1	200	n/a (placement attribute)	1,000 (Flexible)
Ultra Disk support	Yes	No	Yes	Yes

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

An availability set needs 2+ VMs to earn the 99.95% SLA

An availability set is a single-datacenter grouping that spreads VMs across fault and update domains, but the 99.95% Azure SLA applies only when you place two or more VMs in the set: a set with one VM gives no redundancy and no set-level SLA. The set itself is free; you pay only for the VM instances. Because the spreading is inside one datacenter, it protects against hardware, power, and switch failures but not a datacenter-wide outage.

Trap Expecting the 99.95% availability-set SLA from a single VM in the set. The SLA requires two or more VMs across the fault domains.

Availability zones cross datacenters for the 99.99% SLA

Availability zones are physically separate zones within a region, each with independent power, cooling, and networking, and every zone-enabled region has three of them. Spreading a workload's VMs across two or more zones earns the 99.99% SLA and survives the loss of a whole datacenter, the resilience an availability set cannot provide. The cost is slightly higher VM-to-VM latency than an availability set, whose VMs are physically closer.

8 questions test this

A single VM gets 99.9% only if all its disks are Premium SSD or Ultra

Azure grants a 99.9% single-instance VM SLA, but only when the OS and all data disks are Premium SSD or Ultra Disk; a VM using Standard storage gets no single-instance SLA. This is the floor option with no redundancy grouping, appropriate only when an outage of that one VM is tolerable. For anything that must stay up, spread VMs across an availability set or zones.

Trap Claiming a single VM with Standard HDD/SSD disks carries the 99.9% SLA. The single-instance SLA requires Premium SSD or Ultra Disk on every disk.

An availability set has up to 3 fault domains and 20 update domains, fixed at creation

Azure assigns each VM in an availability set a fault domain (a group sharing a power source and network switch, up to 3) and an update domain (a group rebooted together during planned maintenance, up to 20). Only one update domain reboots at a time, with 30 minutes to recover before the next. Both counts are set when the availability set is created and cannot be changed afterward, so size them up front.

3 questions test this

Fault domains isolate hardware failure; update domains isolate maintenance reboots

The two domain types answer different failure modes. A fault domain is a physical boundary: VMs in different fault domains don't share a power source or network switch, so a hardware fault hits only one. An update domain is a maintenance boundary: Azure reboots update domains one at a time during host updates, so a planned reboot never takes the whole set down at once. An availability set distributes VMs across both simultaneously.

3 questions test this

Availability sets can't autoscale. Use a scale set when capacity must follow demand

Availability sets provide redundancy but have no automatic scaling: the instance count is whatever you deployed. When a workload must add instances under load and remove them when idle, you need a Virtual Machine Scale Set, which autoscales horizontally on a metric (such as average CPU) or a schedule. Reach for the availability set only when the instance count is fixed and you just need redundancy.

Trap Choosing an availability set for a workload that must scale out and in with demand. Availability sets never autoscale; a Virtual Machine Scale Set does.

1 question tests this

Your company runs a nightly media-rendering job that must process thousands of independent work items. The workload is stateless, requires…

Flexible orchestration is the recommended VMSS mode and is fixed at creation

A Virtual Machine Scale Set's orchestration mode is chosen at creation and can never be changed. Flexible orchestration is Microsoft's recommended mode: it manages standard IaaS VMs with the normal VM APIs, scales to 1,000 instances, can mix VM sizes, operating systems, and Spot with on-demand instances, and spreads instances across fault domains and availability zones. Uniform orchestration instead deploys identical instances from one profile for very large, homogeneous fleets.

Trap Planning to switch a scale set from Uniform to Flexible later. Orchestration mode is immutable after the scale set is created.

VMSS autoscale is horizontal; changing a VM's size is a separate resize

Autoscale on a Virtual Machine Scale Set is horizontal: it adds instances (scale out) when a metric crosses a threshold and removes them (scale in) when load drops, or follows a schedule. Increasing an individual VM's vCPU/memory is vertical scaling and is a resize operation, not autoscale. A question describing 'more power per instance' points to a resize; 'more instances under load' points to scale-set autoscale.

Trap Treating a VM resize (bigger SKU) as autoscale. Autoscale changes the instance count horizontally, while a resize changes one VM's size vertically.

1 question tests this

Your company runs a nightly media-rendering job that must process thousands of independent work items. The workload is stateless, requires…

Managed disks come in five types; Ultra and Premium SSD v2 can't be the OS disk

The five managed disk types in ascending performance are Standard HDD, Standard SSD, Premium SSD, Premium SSD v2, and Ultra Disk, with IOPS ceilings of about 2,000–3,000, 6,000, 20,000, 80,000, and 400,000 respectively. The OS disk must be Premium SSD, Standard SSD, or Standard HDD: Ultra Disk and Premium SSD v2 are data-disk-only. A high-IOPS database VM therefore pairs a Premium SSD OS disk with an Ultra or Premium SSD v2 data disk.

Trap Selecting Ultra Disk or Premium SSD v2 as the OS disk. Both can only be attached as data disks; the OS disk falls back to Premium SSD, Standard SSD, or Standard HDD.

Ultra Disk doesn't support availability sets. Only single VM or availability zones

Ultra Disk supports single-VM and availability-zone deployments but not availability sets. A scenario that needs both the highest disk IOPS (Ultra Disk) and platform redundancy must use an availability zone, not an availability set. This pairs with Ultra's other limits: it can't be an OS disk and doesn't support disk caching.

Trap Attaching an Ultra Disk to a VM in an availability set. Ultra Disk is unsupported there; use a single VM or an availability zone instead.

1 question tests this

You have an Azure subscription that contains a virtual machine named VM1 with an Ultra Disk attached as a data disk. You need to configure…

The temp disk is non-persistent. Never store durable data on it

Every VM has a temp disk (drive D: on Windows, /dev/sdb on Linux) for scratch data such as a page or swap file. It is local to the host, not a managed disk, and its contents are wiped on deallocation or when Azure migrates the VM to another host. Anything that must survive belongs on the OS disk or a data disk, both of which are persistent managed disks.

Trap Placing application data or a database file on the temp disk. It is wiped on deallocation/host migration, so durable data must go on a managed OS or data disk.

Server-side encryption is always on but doesn't cover the temp disk

Server-side encryption (SSE), also called encryption-at-rest, is always enabled on managed disks and can't be turned off; it encrypts the OS and data disks with platform-managed keys, or customer-managed keys when you attach a Disk Encryption Set (DES). Its boundary is the testable point: SSE does not encrypt the temp disk or disk caches. To cover those, layer on encryption at host.

Trap Assuming default SSE encrypts the temp disk and caches. It covers only the persisted OS and data disks; the temp disk needs encryption at host.

1 question tests this

You have an Azure subscription that contains a virtual machine named VM1 running Windows Server. You need to ensure that all data at rest…

Encryption at host covers temp disk and caches without using VM CPU

Encryption at host extends SSE so the temp disk, disk caches, and data flowing between the VM and storage are all encrypted, and it runs on the Azure host rather than inside the guest, so it consumes no VM CPU. It is Microsoft's recommended encryption option for new VMs and is what Microsoft Defender for Cloud's 'encrypt temp disks, caches, and data flows' recommendation detects. Choose it when the temp disk must be encrypted without a guest agent.

2 questions test this

Azure Disk Encryption uses BitLocker/DM-Crypt in the guest and needs a Key Vault

Azure Disk Encryption (ADE) encrypts the OS and data disks from inside the guest OS (BitLocker on Windows, DM-Crypt on Linux) and integrates with Azure Key Vault to store the disk-encryption keys, so an ADE deployment requires a Key Vault. Because it runs in the guest, ADE uses the VM's CPU and doesn't work for custom Linux images. A stem naming BitLocker or DM-Crypt is describing ADE specifically.

Trap Configuring ADE without an Azure Key Vault. ADE stores its keys in Key Vault, so the deployment fails without one.

1 question tests this

You have an Azure subscription that contains a Windows Server virtual machine named VM1. Your security team requires that the operating…

Prefer encryption at host over ADE. ADE retires September 15, 2028

Azure Disk Encryption is scheduled for retirement on September 15, 2028, after which ADE-encrypted disks will fail to unlock on reboot. Microsoft directs new VMs to encryption at host, which covers more (temp disk and caches) without using VM CPU. For a new long-lived VM, encryption at host is the forward-looking answer; ADE remains only for the specific BitLocker/DM-Crypt-in-guest requirement.

Moving a VM by resource group or subscription never changes its region

Moving a VM to another resource group or subscription only re-parents it: the physical region is unchanged and the VM keeps running. To relocate a VM to a different region you must replicate it with Azure Resource Mover or Azure Site Recovery; the move-resource-group operation can't change a resource's region. A question asking how to move a VM 'to another region' is testing that distinction.

Trap Using a move-to-resource-group or move-to-subscription operation to relocate a VM to a new region. Those never change the region; use Azure Resource Mover or Site Recovery.

3 questions test this

A cross-subscription move requires the same Entra tenant and locks both resource groups

Moving a VM across subscriptions requires both subscriptions to belong to the same Microsoft Entra ID (formerly Azure Active Directory) tenant, and the VM must move together with its dependent resources (disks, NIC, and virtual network). During the move both the source and target resource groups are locked for up to four hours, so you can't create, delete, or resize resources in them while it runs.

Trap Expecting a cross-subscription move to work across two different Entra tenants. Both subscriptions must share one tenant first (transfer billing ownership otherwise).

3 questions test this

A move changes the resource ID and orphans role assignments

Because a resource ID embeds the subscription and resource group, moving a VM changes its ID: any scripts, dashboards, or templates referencing the old ID must be updated. Azure role assignments are not carried across the move and become orphaned, so you must recreate them on the moved resource. Plan to re-point references and re-grant RBAC after a move.

Resizing across VM families may force a deallocation

A VM's size (SKU) fixes its vCPU, memory, and feature support, and sizes are grouped into families by purpose (general purpose, compute optimized, memory optimized, storage optimized, GPU). You can resize a running VM if its current host cluster supports the target size; if it doesn't (often when moving to a different family) the VM must be stopped (deallocated) first and restarts on a new cluster. Not every size is offered in every region.

Trap Assuming any resize is hot. Moving to a size the current host cluster doesn't support requires deallocating the VM first.

The scale set and availability set resources are free; you pay for instances

Neither a Virtual Machine Scale Set nor an availability set carries a charge for the grouping construct itself: billing is purely for the VM instances they contain (plus their disks and networking). This means the redundancy or autoscaling capability is free to adopt; cost scales only with the number and size of running instances.

The Custom Script Extension times out after 90 minutes

A Custom Script Extension run is allowed up to 90 minutes; a script that runs longer fails the extension with a timeout. For long jobs, split the work into scripts that each finish inside 90 minutes. This 90-minute limit is an exception to the shorter timeout most other VM extensions use.

Trap Assuming the Custom Script Extension shares the shorter timeout of most VM extensions and letting a long job run past 90 minutes; it caps at 90 minutes and then fails with a timeout.

5 questions test this

VM extensions need a healthy Azure VM Agent and access to 168.63.129.16

The Azure VM Agent must be installed and reporting Ready for any extension to install or run; if it is missing or unhealthy, extensions fail. The agent signals readiness over the Azure platform IP 168.63.129.16 (WireServer, ports 80/tcp and 32526/tcp), so a guest firewall or NSG that blocks it breaks extensions. An extension already in a failed provisioning state will also block any new extension until it is fixed.

Trap Blaming a failed extension on the script while a guest firewall or NSG blocks 168.63.129.16 or the VM Agent is unhealthy; the agent must report Ready and reach the WireServer IP first.

4 questions test this

Azure Disk Encryption needs a same-region Key Vault enabled for disk encryption and a supported VM size

Azure Disk Encryption requires a Key Vault in the same region and subscription as the VM, with the vault's 'Enabled for disk encryption' access policy turned on. ADE is not supported on Basic or A-series VMs (or VMs with under 2 GB RAM), and you set VolumeType=All to encrypt both OS and data disks. You cannot apply ADE to a VM whose disks use server-side encryption with customer-managed keys (SSE + CMK).

Trap ADE (in-guest BitLocker/DM-Crypt) and SSE with customer-managed keys are mutually exclusive. Pick one.

5 questions test this

You can only place a VM in an availability set at creation. Change it by recreating the VM

A VM's availability set is fixed at creation; you cannot add or move an existing VM into (or between) availability sets. To do it, delete the VM while keeping its managed disks, then recreate the VM from those disks specifying the target availability set, which preserves the data.

Trap Expecting to move an already-running VM into an availability set in place; the set is fixed at creation, so you must delete and recreate the VM from its disks.

4 questions test this

Default availability set: 3 fault domains, 5 update domains; use the Aligned SKU for managed disks

A new availability set defaults to 3 fault domains and 5 update domains (update domains can be raised up to 20). For VMs with managed disks, set the availability set sku.name to Aligned so storage fault domains align with compute. The maximum managed-disk fault domains varies by region (some regions support only 2) so configure no more fault domains than the region allows.

Trap Leaving an availability set on the default Classic SKU for managed-disk VMs; managed disks require the Aligned SKU so storage fault domains align with compute.

3 questions test this

Also tested in

AZ-900 Microsoft Azure Fundamentals

Creating and configuring a VM

Availability: single VM, sets, zones, scale sets

Availability sets: fault and update domains

Availability zones: separate datacenters

Single VM

Managing VM disks and types

The three disk roles

The five managed disk types

Disk encryption: SSE, encryption at host, ADE

Server-side encryption (SSE): always on

Encryption at host: extends SSE to temp disk and caches

Azure Disk Encryption (ADE): in-guest BitLocker/DM-Crypt

How to tell them apart on the exam

Sizing, moving, and scale sets

Managing VM sizes

Moving a VM

Virtual Machine Scale Sets

VM availability and scaling options

Decision tree

Cheat sheet

Also tested in

References