Configuration drift

What it is

Configuration drift is the silent divergence between an environment’s desired state (what your IaC defines) and its actual running state (what’s really deployed). It happens when someone changes a resource outside the approved definition — the old manual “fix” in the Portal, an ad-hoc az command, or a hotpatch on a server.

Why it exists

Drift is the natural enemy of IaC. If reality and code disagree, then: the definition no longer represents production, the next apply can overwrite or delete the ad-hoc change, environments differ from each other, and reproducibility and auditability break down. Detecting and resolving drift is what keeps “everything as code” truthful.

Key ideas

• Sources of drift: hand edits in the Portal, emergency imperative commands, scripts/apps that change resources, human error, or missing resources.
• Detection: run terraform plan (or az deployment what-if for ARM/Bicep) against live Azure to surface un-declared changes. Config-management agents (DSC/Ansible) periodically re-assert inside-VM state.
• Resolution: either re-apply desired state (converge back) or adopt the change into the code (update the definition to match reality — the legitimate fix).
• Prevention via immutable infrastructure and pipelines: no writes outside the definition, write-only permissions, and gate changes through PRs.

How it fits (diagram)

Exam notes

• Know the two responses to drift: reconcile (apply desired state) vs absorb/update the manifest — pick based on whether the change is wanted.
• az deployment group what-if and terraform plan are your drift-detection commands.
• Acuity: template-level IaC does not enforce inside-VM config — validate drift at both the resource layer and the OS/app layer.

Related

desired-state · infrastructure-as-code · terraform · bicep · arm-template · immutable-infrastructure

📘 Source: Microsoft Learn — Configuration Drift