Desired state
What it is
Desired state is the declared target — the authoritative description of how infrastructure and configuration should be at the end. In IaC, your definition file (bicep, ARM template, terraform, or a config-management manifest) is the desired state. The tooling’s job is to reconcile reality toward that state: compare current vs. desired, then change or delete what doesn’t match.
Why it exists
Without a declared target, you can only react to what’s already wrong (“someone changed the VM SKU — now what should it be?”). A desired-state model makes the end-state explicit, versioned, and verifiable, so applying it repeatedly is safe and environments converge instead of drifting.
Key ideas
- Declarative = desired state: you describe the end, not the steps. ARM/Bicep/Terraform all reconcile toward the declared state.
- Reconciliation (idempotent): resources already in the desired state are left untouched; only differences are acted on.
- Convergence: repeated applies drive the environment to the declared state, even after manual tampering — a first line of defense against drift.
- Config management angle: tools like DSC / Ansible / Chef also enforce a desired state for inside-the-VM configuration (packages, services, registry), complementing template-level IaC which manages the resource layer.
How it fits (diagram)
Exam notes
- With incremental ARM deployment mode, resources omitted from the template are left in place (→ potential drift); with complete mode they are deleted to match desired state (dangerous).
- Desired-state thinking is what makes IaC idempotent and re-runnable — a recurring AZ-400 theme.
- Contrast imperative (runbook of steps) vs desired-state (declared end): desired-state is the IaC best practice.
Related
infrastructure-as-code · bicep · arm-template · terraform · configuration-drift · immutable-infrastructure
📘 Source: Microsoft Learn — Desired State