Desired state configuration for environments
Design and implement desired state configuration
The objective names four technologies. Know what each one is, and which are current.
| Technology | Layer | Status |
|---|---|---|
| ARM templates | Azure resources | Current — JSON |
| Bicep | Azure resources | Current — DSL that transpiles to ARM |
| Azure Automation State Configuration | In-guest (OS) | Retires 30 Sep 2027 |
| Azure Machine Configuration | In-guest (OS) | Current — the successor |
Bicep and ARM are the same deployment engine
Bicep is authored more concisely and transpiles to ARM JSON; both are submitted to Azure Resource Manager. Choosing Bicep is an authoring decision, not a change of deployment model — which is why a scenario about "simplifying template authoring without changing the deployment mechanism" points at Bicep.
In-guest is a different layer
ARM and Bicep create and configure Azure resources. Neither installs a package inside a VM. That boundary is what makes the in-guest tools necessary at all, and questions frequently test whether you can tell the two layers apart.
The retirement, restated
Azure Automation State Configuration will be retired on 30 September 2027; transition to Azure Machine Configuration. Machine Configuration combines features of the DSC Extension and Automation State Configuration, and supports hybrid machines through Arc-enabled servers.
Both still appear in the objective, so both are examinable — but only one is where new work should go.
Primary sources