IaC in Practice: Desired State & Deployment Environments

From Templates to Continuous Compliance

Configuration Drift

Configuration drift occurs when the actual state of a server diverges from its intended configuration. Common causes:

• Manual changes via RDP/SSH (“just a quick fix” that is never documented)
• Failed or partial updates
• Software installations outside the pipeline
• Security patches that change settings

Drift is dangerous because environments that were once identical become unpredictably different. A bug that cannot be reproduced in staging might only exist because production has drifted.

Two approaches to prevent drift:

1. Detect and report — monitor for drift, alert the team, require manual remediation
2. Detect and auto-correct — automatically revert any drift to the desired state

Azure Automation State Configuration

Azure Automation State Configuration uses PowerShell Desired State Configuration (DSC) to define and enforce server configurations.

How It Works

1. Write a DSC configuration (PowerShell script defining desired state)
2. Compile it into a MOF (Managed Object Format) file
3. Assign the MOF to target nodes (VMs)
4. The Local Configuration Manager (LCM) on each node pulls and applies the configuration

Example DSC Configuration

configuration WebServerConfig {
    Node 'webserver01' {
        WindowsFeature IIS {
            Ensure = 'Present'
            Name   = 'Web-Server'
        }
        File WebContent {
            Ensure          = 'Present'
            Type            = 'Directory'
            DestinationPath = 'C:\inetpub\wwwroot\app'
        }
        Registry TLS12 {
            Ensure    = 'Present'
            Key       = 'HKLM:\SYSTEM\CurrentControlSet\...'
            ValueName = 'Enabled'
            ValueData = '1'
        }
    }
}

Configuration Modes

Mode	Behaviour	Use When
ApplyAndMonitor	Apply once, then only report drift (no auto-fix)	Audit-first environments, initial rollout
ApplyAndAutoCorrect	Apply and continuously fix any drift automatically	Production servers requiring strict compliance
ApplyOnly	Apply once, never check again	One-time setup, immutable infrastructure

Question

What are the three LCM configuration modes in Azure Automation DSC?

Click or press Enter to reveal answer

Answer

1) ApplyAndMonitor — applies the configuration once, then monitors for drift and reports it but does not auto-correct. 2) ApplyAndAutoCorrect — applies the configuration and automatically corrects any detected drift back to the desired state. 3) ApplyOnly — applies the configuration once and never checks again. Choose based on your compliance requirements.

Click to flip back

Azure Machine Configuration (formerly Guest Configuration)

Azure Machine Configuration is the modern replacement for Automation DSC when managing Azure VMs and Arc-enabled servers. It integrates with Azure Policy for compliance reporting.

Key Differences from Automation DSC

Machine Configuration is the strategic direction — Automation DSC is supported but not receiving new features

Capability	Azure Automation DSC	Azure Machine Configuration
Platform	Azure Automation account required	Built into Azure Policy — no additional infrastructure
Supported OS	Windows (PowerShell DSC)	Windows and Linux
Configuration format	PowerShell DSC / MOF files	PowerShell DSC v3 or custom (machine configuration packages)
Compliance reporting	Automation DSC dashboard	Azure Policy compliance dashboard (unified view)
Assignment model	Pull from Automation account	Azure Policy assignment (inherited, scoped)
Remediation	LCM auto-correct modes	Policy remediation tasks (audit-only or deploy-if-not-exists)
Arc support	Limited	Full support for Arc-enabled servers (on-premises and other clouds)
Direction	Retiring September 2027 (Linux retired Sept 2023) — migrate to Machine Configuration	Actively developed — the future of Azure config management
Best for	Existing DSC investments, Windows-only	New projects, cross-platform, Azure Policy integration

Question

What is Azure Machine Configuration and how does it differ from Automation DSC?

Click or press Enter to reveal answer

Answer

Machine Configuration (formerly Guest Configuration) manages OS-level configuration through Azure Policy rather than a separate Automation account. It supports Windows AND Linux, integrates with Azure Policy compliance reporting, works with Arc-enabled servers (on-premises), and uses policy assignment for configuration delivery. Automation DSC requires a dedicated Automation account, is Windows-focused, and is in maintenance mode.

Click to flip back

Machine Configuration Workflow

1. Author a machine configuration package (PowerShell DSC v3 or custom)
2. Publish the package to Azure Blob Storage or a built-in package
3. Assign via Azure Policy (audit mode or enforce mode)
4. The Guest Configuration agent on each VM checks compliance every 15 minutes
5. Results appear in the Azure Policy compliance dashboard

Two policy effects control behaviour:

• AuditIfNotExists — report non-compliance but do not fix (audit mode)
• DeployIfNotExists — automatically remediate drift (enforce mode)

💡 Exam tip: Provisioning vs configuration management

The exam draws a clear line between two layers:

Resource provisioning (WHAT to create):

• ARM templates, Bicep, Terraform
• Create VMs, databases, App Services, networking
• Runs once per deployment

Configuration management (HOW to configure what is inside):

• Automation DSC, Machine Configuration
• Install software, set registry keys, configure OS settings
• Runs continuously to prevent drift

When a question asks about “ensuring IIS is installed and TLS 1.2 is enabled on all VMs” — this is configuration management (DSC/Machine Config), NOT Bicep/Terraform.

When a question asks about “provisioning a VM with a specific SKU in East US” — this is resource provisioning (Bicep/Terraform), NOT DSC.

Azure Deployment Environments

Azure Deployment Environments (ADE) provide self-service, template-based infrastructure for developers. Instead of submitting a ticket and waiting days for an environment, developers spin up pre-approved infrastructure in minutes.

How It Works

1. Platform engineers create a Dev Center with project definitions
2. They define environment types (Dev, Test, Staging, Production)
3. They build a catalogue of approved IaC templates (Bicep or Terraform) stored in a Git repository
4. Developers self-serve: pick a template, provide parameters, click deploy
5. Guardrails enforce policies — developers cannot exceed resource limits or create non-compliant resources
6. Auto-delete policies destroy idle environments after a configurable period (cost control)

Key Components

Component	Purpose
Dev Center	Central management hub for projects and catalogues
Project	Logical grouping — maps to a team or application
Environment Type	Classification (Dev, Test, Staging) with different policies
Catalogue	Git repository containing approved IaC templates
Environment Definition	A specific template in the catalogue (e.g., “3-tier web app”)
Environment	A running instance created by a developer from a definition

💡 Scenario: Jordan builds a self-service platform

☁️ Jordan at Cloudstream Media creates a Dev Center for the engineering team:

Catalogue templates:

• “Microservice sandbox” — App Service + SQL Database + Redis Cache
• “Full-stack dev” — AKS cluster + ACR + PostgreSQL + Storage Account
• “Data pipeline” — Event Hub + Stream Analytics + Cosmos DB

Guardrails:

• Dev environments limited to B-series VMs (cost control)
• Auto-delete after 7 days of inactivity
• All resources tagged with owner and project automatically

Developer experience: Avery (dev lead) needs a new environment for a feature branch. She opens the Azure Developer CLI, picks “Microservice sandbox,” names it feature-payments, and has a running environment in 8 minutes. When the feature merges, the environment auto-deletes after 7 idle days.

This eliminates the “wait 3 days for infra team to provision an environment” bottleneck while maintaining cost and compliance guardrails.

Question

What is Azure Deployment Environments and who is it designed for?

Click or press Enter to reveal answer

Answer

Azure Deployment Environments provides developer self-service infrastructure provisioning with guardrails. Platform engineers define approved templates in a catalogue (Bicep/Terraform stored in Git). Developers create environments from those templates on demand. Guardrails (policies, resource limits, auto-delete) keep costs and compliance in check. It bridges the gap between developer agility and platform governance.

Click to flip back

Comprehensive IaC Comparison

Use the right tool for the right layer — do not use Bicep for OS configuration or DSC for resource provisioning

Tool	Layer	Scope	State	Best For
ARM Templates	Resource provisioning	Azure only	Azure manages state	Legacy templates, maximum compatibility
Bicep	Resource provisioning	Azure only	Azure manages state	New Azure-only projects, clean syntax
Terraform	Resource provisioning	Multi-cloud	External state file	Multi-cloud environments, existing Terraform teams
Automation DSC	OS configuration	Windows VMs	Automation account	Existing DSC investments, Windows-only shops
Machine Configuration	OS configuration	Windows + Linux (Azure and Arc)	Azure Policy	Modern config management, cross-platform, compliance
Deployment Environments	Self-service provisioning	Azure	Dev Center	Developer self-service with governance guardrails

Knowledge Check

Dr. Amira's government client requires that all Windows VMs have TLS 1.2 enabled and that any drift is automatically corrected. The solution must report compliance through Azure Policy. Which tool should Amira recommend?

ABicep templates with TLS configuration in VM extensionsBAzure Automation State Configuration with ApplyAndAutoCorrect modeCAzure Machine Configuration with DeployIfNotExists policyDTerraform with a provisioner script that sets TLS registry keys

Check Answer

Knowledge Check

Jordan wants to enable developers to create their own test environments from approved templates without involving the platform team. Environments should auto-delete after 7 days of inactivity. What should Jordan implement?

AAzure Automation runbooks triggered by a self-service portalBAzure Deployment Environments with a Dev Center catalogue and auto-delete policiesCTerraform Cloud workspaces with developer-specific variable setsDARM template deployment via Azure DevOps pipeline with manual trigger

Check Answer

Knowledge Check

Which configuration mode should you use for an initial rollout where you want to apply the desired state and monitor for drift WITHOUT automatically fixing it?

AApplyOnlyBApplyAndAutoCorrectCApplyAndMonitorDAuditIfNotExists

Check Answer

🎬 Video coming soon

Desired State Configuration and Deployment Environments

Next up: Pipeline Maintenance: Health, Migration and Retention