4.2.5. Azure Machine Configuration
💡 First Principle: A VM that was correctly hardened at deployment can still drift out of compliance over time — a setting gets manually changed, a patch gets skipped — and without something actively watching the OS-level configuration, that drift goes unnoticed until it's exploited.
Azure Machine Configuration (built on the guest configuration extension) audits and, optionally, enforces OS-level settings inside a VM against a defined baseline — things like local security policy settings, registry values, or specific files being present or absent — extending Azure Policy's reach from resource-level properties (2.3.1) down into the operating system itself. It works on both Azure VMs and Arc-enabled hybrid/multicloud servers (4.2.3).
⚠️ Exam Trap: Azure Policy alone (2.3.1) evaluates resource-level properties visible to the Azure Resource Manager API — it can't see inside the guest OS. A scenario asking about enforcing an in-guest setting (like a specific Windows security policy or a required local file) needs Machine Configuration specifically, not a standard Azure Policy definition.
Reflection Question: Why can't a standard Azure Policy definition alone enforce a Windows local security policy setting inside a VM's guest OS, and what does Machine Configuration add to close that gap?
