11.2 Desired State Configuration & Azure Machine Configuration

11.2 Desired State Configuration & Azure Machine Configuration

While Infrastructure as Code tools like Bicep and Terraform excel at provisioning cloud fabric resources (virtual networks, storage accounts, Kubernetes clusters, and virtual machines), they do not natively manage the software configurations inside virtual machine operating systems. Operating systems require software packages, system services, security registries, environment variables, and filesystem baselines.

Without continuous inside-the-OS management, virtual machines suffer from configuration drift: manual administrative interventions, uncoordinated patches, or software crashes that cause running servers to deviate from approved compliance baselines. For the AZ-400 exam, candidates must understand PowerShell Desired State Configuration (DSC), the mechanics of the Local Configuration Manager (LCM), the operational role of Azure Automation State Configuration, and the modern migration to Azure Machine Configuration (formerly Azure Policy Guest Configuration) powered by Azure Arc.

---

1. Configuration Drift and Continuous Compliance

Configuration drift occurs when an operational server's state gradually diverges from its defined specification. Examples include:

• An engineer logging into a production VM via SSH or Bastion and manually editing a configuration file to resolve an emergency incident.
• A Windows service crashing or being stopped manually and never restarted.
• An unauthorized registry key modification that disables TLS 1.2 or weakens cipher suites.
• Package updates applied to one server in a cluster but missed on others.

Continuous compliance requires an automated inside-the-guest agent that periodically checks the actual OS state against a declared baseline and remediates discrepancies without human intervention.

---

2. PowerShell Desired State Configuration (DSC) Architecture

PowerShell DSC is a declarative configuration platform built into Windows and cross-platform PowerShell. It separates the configuration specification from the execution mechanism.

DSC Script Anatomy

A PowerShell DSC script uses specialized declarative keywords:

• Configuration: The top-level block defining the configuration container.
• Node: Specifies the target host or computer names.
• Resource Blocks: Declarative definitions of system components (File, Archive, Environment, Group, Registry, Script, Service, User, WindowsFeature, WindowsProcess).

# Example: PowerShell DSC Configuration Script
Configuration WebServerBaseline
{
    param (
        [string[]]$NodeName = 'localhost'
    )

    Import-DscResource -ModuleName 'PSDesiredStateConfiguration'

    Node $NodeName
    {
        # Enforce that IIS Web Server feature is installed
        WindowsFeature IIS
        {
            Ensure = 'Present'
            Name   = 'Web-Server'
        }

        # Enforce that the World Wide Web Publishing Service is running
        Service W3SVC
        {
            Name        = 'W3SVC'
            StartupType = 'Automatic'
            State       = 'Running'
            DependsOn   = '[WindowsFeature]IIS'
        }

        # Ensure production directory exists
        File WebDirectory
        {
            Ensure          = 'Present'
            Type            = 'Directory'
            DestinationPath = 'C:\inetpub\wwwroot\api'
        }
    }
}

# Compiling the configuration generates a localhost.mof file
WebServerBaseline

The Compilation Phase (MOF Generation)

A common exam point is that DSC configuration scripts (.ps1) cannot be executed directly on target nodes. The PowerShell script must first be compiled into a Managed Object Format (.mof) document based on the Common Information Model (CIM) standard. The resulting MOF file contains the serialized desired state consumed by the target machine.

---

3. The Local Configuration Manager (LCM)

The Local Configuration Manager (LCM) is the operating system engine that executes on each target node (Windows and Linux). The LCM is responsible for receiving MOF configurations, testing the current state, and applying changes.

LCM Configuration Modes (ConfigurationMode)

The behavior of the LCM is controlled by its ConfigurationMode property:

Critical LCM Operational Properties

• ConfigurationModeFrequencyMins: Dictates how often (in minutes) the LCM evaluates the machine against the current configuration to check for drift and enforce compliance (Default: 15 minutes).
• RefreshFrequencyMins: In pull mode, dictates how often (in minutes) the LCM contacts the central pull server to check for updated MOF files (Default: 30 minutes). RefreshFrequencyMins must be an integer multiple of ConfigurationModeFrequencyMins.
• RebootNodeIfNeeded: When set to $true, permits the LCM to automatically reboot the target virtual machine if a resource requires a reboot to complete installation (e.g., certain Windows Server features).
• ActionAfterReboot: Specifies whether the LCM continues configuration processing (ContinueConfiguration) or halts (StopConfiguration) following a system reboot.

---

4. Azure Automation State Configuration (Managed DSC Pull Server)

Azure Automation State Configuration provides a cloud-hosted, managed DSC pull server integrated into an Azure Automation account.

┌────────────────────────────────────────────────────────────────────────┐
│                     Azure Automation Account                           │
│  ┌──────────────────────┐               ┌───────────────────────────┐  │
│  │ DSC Scripts (.ps1)   │──[Compile]───►│ Node Configurations (.mof)│  │
│  └──────────────────────┘               └─────────────┬─────────────┘  │
└───────────────────────────────────────────────────────┼────────────────┘
                                                        │ Pull (Every 30m)
                                                        ▼
                                            ┌───────────────────────┐
                                            │ Azure VM (LCM Engine) │
                                            │  - ApplyAndAutoCorrect│
                                            │  - Drift Evaluation   │
                                            └───────────────────────┘

Key Operational Steps in Azure Automation DSC

1. Upload Configuration: Author the PowerShell DSC script (.ps1) and upload it to the Azure Automation Account under Configuration Management → State Configuration (DSC) → Configurations.
2. Compile Configuration: Trigger compilation within Azure Automation (Start-AzAutomationDscCompilationJob). This produces compiled Node Configurations (ConfigurationName.NodeName) stored in Azure Automation.
3. Register Nodes: Virtual machines are registered with the pull server using the Azure VM DSC extension (Microsoft.Powershell.DSC for Windows, nx for Linux) or via PowerShell Register-AzAutomationDscNode.
4. Assign Node Configuration: Map the compiled node configuration to the registered virtual machine.
5. Monitor Compliance: The Azure Automation portal visualizes the status of each node: Compliant, Non-Compliant, Failed, or Pending.

---

5. Modern Evolution: Azure Machine Configuration (Azure Policy)

While Azure Automation State Configuration served as the standard for years, Microsoft has transitioned configuration management into Azure Machine Configuration (formerly known as Azure Policy Guest Configuration).

Why the Architecture Evolved

1. Elimination of Standalone Automation Accounts: Automation DSC required provisioning and maintaining dedicated Automation Accounts, managing separate access keys, and troubleshooting cloud compilation jobs.
2. Unified Governance Plane: Enterprise security demands governing the inside of a VM (e.g., auditing installed software, TLS settings, password policies) using the exact same policy definitions, scopes, and compliance dashboards that govern the outside of a VM (e.g., disk encryption, network security groups, tagging).
3. Native Policy Integration: Machine Configuration definitions are published directly as Azure Policy definitions and assigned via Management Groups, Subscriptions, or Resource Groups.

How Azure Machine Configuration Works

• Agent Extension: Virtual machines require the Machine Configuration extension (AzurePolicyforWindows or AzurePolicyforLinux).
• Managed Identity Requirement: The virtual machine must have a System-Assigned or User-Assigned Managed Identity enabled. The Machine Configuration agent uses this managed identity to authenticate against the Azure Policy service and retrieve configuration packages from secure storage.
• Policy Effects:
  • auditIfNotExists: Audits settings inside the virtual machine without modifying them, generating compliance reports in Azure Policy.
  • deployIfNotExists: Automatically provisions the Machine Configuration extension and deploys custom remediation packages to fix non-compliant configurations inside the guest operating system.

Authoring Custom Machine Configuration Packages

Custom packages are built using PowerShell Core and the GuestConfiguration module:

1. Author a DSC configuration defining desired baseline settings.
2. Compile the DSC configuration into a MOF file.
3. Run New-GuestConfigurationPackage to package the MOF file and required dependencies into a signed .zip artifact.
4. Upload the .zip package to an Azure Blob Storage container accessible by the VM's managed identity.
5. Run Publish-GuestConfigurationPackage to generate and publish an Azure Policy definition referencing the package.

Hybrid and Multi-Cloud Governance via Azure Arc

Azure Machine Configuration natively supports hybrid physical and virtual machines running on-premises, in VMware, or across other clouds (AWS, GCP) via Azure Arc-enabled servers.

• When the Azure Connected Machine agent is installed on an external server, Azure Arc exposes that machine as a first-class Azure Resource Manager resource (Microsoft.HybridCompute/machines).
• Azure Machine Configuration policies apply identically to both native Azure VMs and Arc-enabled hybrid servers, establishing a single enterprise governance plane across the entire fleet.

---

6. Architecture Comparison Matrix

---

7. Realistic Exam Scenarios & Common Traps

Scenario: Remediating Configuration Drift in Mission-Critical Clusters

Context: A security audit reveals that unauthorized administrators have disabled Windows Defender Firewall and altered TLS registry entries across 50 production VMs. The existing DSC configuration reports these machines as Non-Compliant in Azure Automation, but the settings are never corrected automatically. Root Cause & Fix: The virtual machines' Local Configuration Manager is configured with ConfigurationMode = 'ApplyAndMonitor'. In this mode, the LCM detects and logs drift but takes no corrective action. The DevOps engineer must update the LCM meta-configuration to ConfigurationMode = 'ApplyAndAutoCorrect'. At the next ConfigurationModeFrequencyMins interval, the LCM will automatically re-apply the baseline and restore the firewall and TLS settings.

Common Exam Traps to Avoid

• Trap: Confusing RefreshFrequencyMins with ConfigurationModeFrequencyMins. RefreshFrequencyMins governs how often the machine checks the pull server for newly published configurations (default: 30 min). ConfigurationModeFrequencyMins governs how often the local LCM evaluates and auto-corrects drift against the currently cached configuration (default: 15 min).
• Trap: Forgetting the VM Managed Identity requirement for Machine Configuration. If an Azure Policy assignment targeting guest configurations fails to evaluate or remediate a VM, verify whether the VM has a Managed Identity. Azure Machine Configuration relies on Managed Identity to access configuration packages in Azure Storage.
• Trap: Attempting to deploy raw .ps1 scripts as DSC node configurations. The Local Configuration Manager cannot parse raw PowerShell scripts directly. The DSC script must be compiled into a .mof file before it can be assigned to a node.