← AZ-104: Azure administration in production
04 / 7 · 23 MIN

Declarative deployments and virtual machines

Interpret a change’s effect before executing it.

Concept and mechanism

Bicep describes intended resources and properties. Compilation validates part of the definition but is not equivalent to comparing remote state. What-if supports inspecting predicted changes without applying deployment; it has limitations and does not alone guarantee application behavior. In incremental mode, existing resources omitted from the template remain. This does not mean omitted properties of a declared resource are preserved: its definition represents that resource’s state and values may return to defaults. Review the property set and scope, especially for resources with nested configurations.

Guided application

For a production change, retain template version, nonsecret parameters, and review results. Handle passwords through secure parameters and appropriate supply mechanisms; do not later expose them in outputs or logs. Plan validation and recovery before the window. In daily VM operations, distinguish still-allocated Stopped from Deallocated. Guest operating-system shutdown may retain compute charges; deallocation does not automatically remove disks and other billable resources. Confirm effective state and dependencies before proposing savings or retirement.

IN PRACTICE

An incremental template stops mentioning a VM: omission does not retire it. Retirement needs a planned operation and decisions about disks, backups, and dependencies.

Common pitfalls

Treating incremental as partial property patching; publishing secrets in outputs; confusing a stopped VM with zero cost.

Related topics: Availability, scale, and releases · Networks and layered diagnosis

Take this idea with you

Confirm intended state and effect, including resources remaining after the change.

Create account

Reference: ARM deployment modes · AZ-104; skills measured 2026-04-17