The owned car — everything above the hardware is yours
A virtual machine is the owned car from the hub: Azure runs the physical host and the virtualisation, and everything above that line — the operating system, its patches, the runtime, the application, the backups, the monitoring agents — is yours to install, configure and keep alive. This is the bottom rung of the compute spectrum, IaaS in its purest form, and it exists because some workloads genuinely need it: legacy software with specific OS requirements, a licensed application that must see a real machine, a system you are lifting from a data centre before you refactor it. When you need that control, nothing else will do; when you do not, the control is just chores.
The right way to hold a VM is deliberately. Each of the choices in this part — how big, from what image, how many, on what disks, with what extensions — is a decision you own precisely because you chose the rung that hands them to you. The skill is not avoiding VMs, which are sometimes exactly right, but carrying their chore list on purpose rather than by accident, and knowing the cost of each one so a design review does not surprise you.
Series, sizing and images — choosing the machine
Azure sells VMs in series tuned to different shapes of work, and the letter tells the story. The B-series is burstable — cheap machines that bank credits while idle and spend them on short spikes, ideal for a low-traffic box that occasionally works hard. The D-series is the general-purpose default, balanced CPU and memory. The E-series is memory-optimised for databases and caches; the F-series is compute-optimised for CPU-bound work. Within a series, a number and version give the exact size — vCPUs and RAM — so D4s_v5 reads as "general purpose, four vCPUs, version 5, premium-disk capable."1
Sizing is the same evidence-over-fear discipline from Part A, with sharper teeth because a VM does not autoscale itself: you pick the size, and it stays that size until you change it. Start from what the workload actually uses, not from the largest number that feels safe, and resize later — a two-minute stop-and-restart — if the metrics demand it. The machine boots from an image: a Marketplace image (a clean Windows or Linux install), a hardened image from your organisation's gallery, or a custom image you captured from a configured VM so every new machine starts identical. The image is where "every server is a little different" either begins or is prevented.
A VM does not right-size itself. That job stayed with you.
Staying up — availability sets versus zones
One VM is one machine, and one machine has one fate: when the host it sits on needs maintenance, or fails, your app goes with it. Azure gives you two ways to spread that risk across more than one machine, and knowing which is which is a reliable interview question. An availability set spreads your VMs across fault domains (separate racks, power and network) and update domains (patched at different times) within a single datacenter — it protects against a rack failure or a host update, but not against the whole datacenter going dark. Availability zones spread VMs across physically separate datacenters within a region, each with independent power and networking — protection against an entire facility failing.
The difference shows up in the SLA and the failure you are insuring against. A single VM on premium disks carries a modest single-instance SLA; two or more VMs in an availability set raise it; VMs spread across zones raise it further, because it now takes a whole-datacenter loss to take you down. The choice is a risk decision priced in money and blast radius: zones cost a little more and buy datacenter-level resilience, sets are cheaper and buy rack-level resilience. For most production workloads that must survive a facility problem, zones are the modern default; sets remain for workloads pinned to a single datacenter. Whichever you choose, one machine alone is a single point of failure you accepted, whether you meant to or not.
| Approach | Spreads across | Survives | Does not survive |
|---|---|---|---|
| Single VM | Nothing | Nothing beyond a reboot | Host failure or maintenance |
| Availability set | Fault + update domains, one datacenter | A rack failure or host update | Loss of the whole datacenter |
| Availability zones | Separate datacenters in a region | An entire datacenter failing | Loss of the whole region |
Managed disks and extensions — storage that outlives, code that configures
A VM's disks are managed disks: Azure handles the storage account plumbing beneath them, and — the fact that matters most — a data disk has its own lifecycle, so it can outlive the VM it is attached to. Delete or rebuild the machine and a data disk detaches and survives, ready to attach to the next one; the OS disk can be set to delete with the VM or persist. Disks come in tiers — Standard HDD for cold, cheap storage, Standard and Premium SSD for production, Ultra for the most demanding databases — and the tier is a cost-versus-performance decision you make per disk. Treating the data disk as separable from the machine is what lets you rebuild a broken VM without losing its data.
VM extensions are small agents Azure installs and runs inside the machine to handle configuration and management: the Custom Script Extension runs a setup script on first boot, the monitoring agent ships logs and metrics out to where Class Twenty-Eight collects them, and others handle desired-state configuration or anti-malware. Extensions are how you keep "every server is a little different" from creeping back in — the machine's setup is code that runs on provision, not a checklist someone follows by hand. That is the same infrastructure-as-code instinct from Phase Three, applied inside the box the VM gives you.
The POS batch job gets a right-sized VM — with the catch named
The nocturnal POS reconciliation — the job the hub sent to IaaS — finally gets its machine. It runs three hours a night and sits idle the rest, so you choose a B-series burstable VM sized to what the job actually consumes rather than to a comfortable round number, and you resolve to watch the graph for a week before touching the size. Its working data lands on a managed data disk kept separate from the OS disk, so if the machine is ever rebuilt from a fresh image, the reconciliation data is untouched and simply re-attaches.
Then you name the catch the hub promised the exam would test. You add an auto-shutdown schedule so the VM stops after the nightly window instead of billing around the clock — but auto-shutdown does not auto-start. Shutdown alone would fix the bill and break the job. So you pair it with a scheduler — an Azure Automation runbook or a Logic App — that starts the VM before the job and lets auto-shutdown stop it after. That pairing is the difference between "we turned it off" and "we run it only when needed," and it is exactly the leak Part 11a warned lives in always-on capacity.
Carrying the chore list on purpose
Lay the whole list out and the VM's true cost is visible: you size it, patch its OS, capture its image, arrange its availability, manage its disks, script its configuration, schedule its start and stop, and monitor all of it — every one a chore that App Service did for you in Part B. None of this is wasted when the workload genuinely needs the control; all of it is pure overhead when the workload did not. That is why the spectrum reads the way it does, and why the honest engineer reaches for a VM last, not first.
The next part answers the natural follow-on: what happens when you need not one VM but a fleet of them that grows and shrinks. A virtual machine scale set takes everything in this part and makes it elastic — many identical machines, from one image, scaling on a metric or a schedule. Keep this part's chore list in mind as you read it, because a scale set does not remove the chores; it multiplies the machine while letting you manage the fleet as one. Part 11f then places the VM against every lighter rung, so you choose it because a requirement demanded it, never by default.
The bill for a machine that works three hours a night
A batch VM has been billing twenty-four hours a day for a three-hour job since it was created. You right-sized it once and moved on, and the invoice kept climbing anyway. The fix is not a smaller machine — it is a schedule: auto-shutdown after the window, plus a runbook to start it before the job, because Azure will stop a VM on a timer but will not start one. You cut the run-time by seven-eighths without changing the machine at all, and you write down why, so the next person does not mistake "sized" for "scheduled."
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
B. Availability zones spread VMs across physically separate datacenters within a region, each with independent power and networking, so it takes a whole-facility loss to take you down. An availability set only spreads across racks and update groups inside one datacenter — it survives a rack failure or a host update but not the datacenter going dark, which is exactly the failure the question names. C makes each machine bigger and does nothing for resilience; a single large VM still has a single fate. D protects data, not availability. Match the spread to the failure: datacenter-level risk needs zone-level spread.
B. Azure's auto-shutdown stops a VM on a schedule but has no built-in auto-start — so shutdown alone fixes the bill and breaks the job, because the machine is off when the next night's run is due. You pair auto-shutdown with a scheduler that starts the VM before the window; the pair is what turns "always on" into "on only when needed." A states the exact false belief the drill exists to catch. C addresses run duration, not the idle hours that dominate the bill. D is unrelated to scheduling. The catch is specific and famous: shutdown is automatic, start is not.
OS patching, sizing, and the app and runtime. Those all sit above the line Azure draws at the hardware — on a VM, everything from the guest OS up is yours. The two rejects are Azure's side: the physical host, the virtualisation layer, and the physical disks in the datacenter are the provider's to maintain and replace. This is the shared-responsibility line from Class One drawn at its lowest, most chore-heavy position — which is exactly why a VM is the rung you justify, not the one you default to. Everything you keep here, App Service kept for you in Part B.
POS VM — cost + run plan
1. Size: B-series burstable, watched for a week then adjusted.
2. Data on a separate managed disk that survives a VM rebuild.
3. Auto-shutdown at 04:00; the VM auto-starts itself at 01:00.
4. Job window is 01:00-04:00 nightly.
Line three. The VM does not "auto-start itself" — Azure's auto-shutdown has no auto-start counterpart. The 04:00 shutdown will work, but nothing will bring the machine up at 01:00, so after the first shutdown the VM stays off and the reconciliation silently stops running. You need a scheduler — an Automation runbook or a Logic App — to issue the start. Lines one, two and four are sound: burstable suits a bursty job, a separable data disk survives rebuilds, and the window is just a stated fact.
Consider the consequence. The plan looks complete and even cost-aware, so it is approved; the first night runs fine because the VM happened to be on, then auto-shutdown fires and every subsequent night quietly does nothing. The books stop reconciling with no error to page on, and the gap is found weeks later at month-end. Encoding the false belief "shutdown implies start" into a plan is how a cost optimisation becomes an outage.
Separate the two questions being conflated. A backup answers "can I recover the data if it is lost or corrupted?" Availability answers "does the service stay up when a machine fails?" They are different axes, and the colleague has used an answer to the first as if it settled the second. Both matter; neither substitutes for the other.
Show where the single-VM-plus-backup plan breaks. When a host fails or goes in for maintenance, a single VM goes down, and "restore from backup" means minutes to hours of downtime while a new machine is provisioned and the restore runs — during which the service is simply offline. For anything users depend on, that outage is the failure, not the data loss. An availability set or zones keeps a second machine serving while the first is gone, so the host failure becomes a non-event instead of an incident.
Give the calibrated rule. Backups are non-negotiable and orthogonal — keep them regardless. But for a workload that must stay up, add availability: a set for rack-level protection within a datacenter, zones for datacenter-level protection, chosen by the blast radius you must survive. "We have backups" is a true statement that answers the wrong question when the incident is "the host just failed." The mature design carries both, because they insure against different disasters.
Respect the reason before you question it. "We know how VMs work" is a genuine advantage — a team operating tools it understands makes fewer mistakes than one fighting an unfamiliar platform. Do not wave that away. The question is whether the familiarity is worth the chore list a VM hands them for a workload that, on your own description, needs none of the control that chore list buys.
Price the control against the requirement. A standard stateless HTTP API with no special OS needs is the exact shape App Service was built for. On a VM the team would own OS patching, availability sets or zones, disk management, the load balancer, TLS renewal, and start/stop scheduling — all the chores Parts A through C showed App Service absorbing. "Full control" here is control over things they have no special requirement to control, which means it is pure overhead: the all-IaaS instinct from Class Four, wearing the costume of prudence.
Offer a path that honours the real concern. Suggest App Service for this API, and name what would legitimately send it back to a VM — a licensed component that must see a real OS, a dependency App Service cannot host, a compliance rule. If none of those is present, the familiarity argument is answered by the platform doing the operating for them, which frees the very attention they think they are protecting. Choosing App Service is not giving up control that matters; it is declining chores that do not.
Five things worth carrying out of Part D
- A VM hands you everything above the hardware: OS, patching, runtime, app, availability, backup. Most control, longest chore list — chosen deliberately, never by default.
- Series encode the workload shape: B burstable, D general, E memory, F compute. Size from evidence and resize later; a VM does not autoscale itself.
- Availability sets spread across racks in one datacenter; zones spread across separate datacenters in a region. Match the spread to the failure you must survive.
- Managed data disks have their own lifecycle and outlive the VM — rebuild the machine without losing the data. Extensions configure the box as code.
- Auto-shutdown stops a VM but does not start it. Pair it with a scheduler, or you fix the bill and break the job.
- The VM size names look like line noise until you learn to read them, and then they are almost self-documenting: the letter is the family (B, D, E, F and others), a following letter often flags a capability — an s means premium-storage capable — and the trailing v5 is the hardware generation. New generations appear regularly and old ones are retired, so treat any specific size here as an example of how to read the name, not a size to memorise. The families and their purposes are the durable part; the exact SKUs churn. ↩
- The single-VM SLA is worth stating carefully because it changed in a way that trips up older study material. Azure now offers a meaningful SLA for a single VM if it uses premium or ultra disks for all its disks — not zero, as the older "you need two VMs for any SLA" guidance implied. Two VMs in an availability set and VMs across zones raise the number further. The direction is settled — more spread, higher SLA — but check the current figures before you quote one to a stakeholder, because the exact percentages move. ↩