Exercise 1: Why No Disk-Space Alert Fired, Using the Four-Layer Model — Possible Solution
====================================================================

Azure Monitor's own real four-layer model draws a clean line between
what's collected automatically and what isn't. The virtual machine
host layer is collected automatically with zero setup, but it only
provides basic real metrics -- CPU utilization and whether the
machine is running -- nothing about the guest operating system's own
internal state.

Disk space usage lives one layer deeper, at the guest operating
system layer. Per the chapter's own real table, this layer is NOT
collected automatically -- it specifically requires deploying the
Azure Monitor Agent inside the VM before that data even exists as
something Azure Monitor can see, let alone alert on.

Because no Azure Monitor Agent had been deployed, disk-space usage was
never actually being collected as a metric at all -- there was
nothing for an alert to watch, regardless of how the alert itself
might have been configured.

ANSWER: This happened because disk-space data lives at the guest
operating system layer, which Azure Monitor does not collect
automatically -- the missing step was deploying the Azure Monitor
Agent to the VM. Without it, disk-space usage was never a real,
available metric in the first place, so no alert could ever have been
set up to watch it correctly.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly applies the chapter's own real four-layer framework to
identify exactly which layer disk-space data belongs to, and
identifies the specific missing real step (deploying the Azure
Monitor Agent) rather than describing the problem only vaguely as "a
monitoring gap."