Virtual machine options, and what a virtual machine needs

What every virtual machine comes with

Creating a virtual machine is a set of decisions rather than one: a region, a size (which fixes CPU, memory and disk throughput), an image, disks, and where it sits on the network. Three things always come with it. It needs a virtual network with a subnet to live in, a network interface attached to that subnet, and at least an operating system disk to boot from. Many sizes also present a temporary local disk whose contents do not survive a move to another host, so nothing you care about belongs on it.

A public IP address is optional, and often the wrong choice — plenty of machines are reachable only from inside the virtual network, over a VPN, or through a jump host, which is usually the safer design. A storage account is not required either: a managed disk is its own resource type and Azure looks after the storage behind it, so you choose the disk's type and size rather than an account to keep it in. That was the older unmanaged model, and it is still offered as a distractor.

$ az vm stop --name api-01 --resource-group payments# powered off, but the hardware is still reserved# the compute charge is still running$ az vm deallocate --name api-01 --resource-group payments# the hardware is released and the compute charge stops# the disks keep billing either way, because they still exist

Scaling up and scaling out

Scaling up means a bigger machine. It requires a resize, usually with a restart, has a hard ceiling at the largest size available in the region, and leaves you paying peak prices around the clock unless somebody remembers to shrink it again. Scaling out means more machines, and it is where the cloud's economic advantage actually lives, because instances added for a busy hour can be removed afterwards.

Virtual Machine Scale Sets are the virtual machine expression of scaling out: identical instances built from one configuration, created and removed by autoscale rules against a metric such as CPU or by a schedule, load balanced across, and optionally spread across availability zones. The contrast the exam draws is with an availability set, which improves the availability of a FIXED number of machines and never changes the instance count in response to anything.

Availability sets, and the choice you cannot make later

An availability set is a placement instruction. Azure distributes its members across fault domains — groups of racks sharing power and a top-of-rack switch — so that one hardware failure cannot take every member, and across update domains, which are rebooted at different times during planned host maintenance so that one maintenance window cannot either. Both operate inside a single datacentre, which is precisely why availability zones are the next level up when the region offers them.

The detail that makes a question: joining an availability set is a creation-time decision. You cannot move an existing machine into one afterwards, so a scenario that describes a running cluster and asks how to add it to a set is asking you to notice that you cannot. The other creation-versus-runtime distinction worth carrying is billing: deallocating a machine stops the compute charge, while its disks keep billing for exactly as long as they exist.

Azure Virtual Desktop centralises the desktop, not the device

Azure Virtual Desktop delivers virtualised Windows desktops and applications from Azure: the session runs there, the data stays there, and the endpoint is reduced to a screen, a keyboard and a mouse. Windows multi-session lets several users share one host, which is what makes it economic for large numbers of people. When a requirement names the desktop itself, from unmanaged devices, with nothing stored locally, that is Virtual Desktop — not a pile of individually built virtual machines with remote desktop exposed to the internet.