IaC: declarative vs imperative explained

Infrastructure as code (IaC) means describing infrastructure in text files kept in version control, so a change is a commit instead of a series of clicks. A declarative definition states the end result and lets the tool work out the steps; an imperative script lists the steps and leaves you to handle the starting state. If an exam question says “desired state”, “repeatable” or “the same result no matter how many times it runs”, the answer is declarative and idempotent. Bicep, ARM templates and Terraform are declarative. A Bash or PowerShell script that calls az commands in order is imperative.

The same task written both ways

The task: a resource group must contain one storage account with a given name and SKU.

The imperative version is a script: create the resource group, create the storage account, set the tier. Run it twice and the result depends on how each command treats an object that already exists: some fail, some create a duplicate, some silently overwrite settings. Safe reruns need the author to know each case and add checks. Run it against an environment that has drifted and it does nothing about the drift unless the author anticipated that case. Every “what if it is already there” branch is code the author has to write and maintain.

The declarative version is a Bicep file that contains the storage account resource with its name, SKU and kind. Deploy it to an empty resource group and the account is created. Deploy it again and nothing changes. Change the SKU in the file and deploy again, and the account is updated. The file always describes the final state, and Azure Resource Manager (ARM) decides what to create, update or leave alone. Microsoft’s Bicep documentation says exactly this: Bicep files are idempotent, so deploying the same file many times gives the same resource types in the same state, and you maintain one file that represents the desired state instead of many files for updates.

Decision table

Microsoft’s guidance on IaC states a preference for declarative definition files where possible: they describe what an environment needs, not how to build it, and they reduce the debt of maintaining imperative deployment scripts. The same page defines idempotence as an operation that always produces the same result, so a deployment sets the target to the same configuration whatever its starting state.

Where state lives and why exams ask

Declarative tools must compare “what I want” with “what exists”. They differ in where they keep what exists.

• Bicep and ARM templates keep no state file you manage. Azure itself is the record. The Bicep overview lists “no state or state files to manage” as a benefit, and the what-if operation checks the live environment to preview changes (az deployment group what-if).
• Terraform records real infrastructure in a state file and uses it to decide what must change. Its plan step lists what will be created, changed or destroyed, and apply carries it out. The state file is a managed asset: shared, locked and protected, because it can contain sensitive values.
• Ansible describes the desired state of a machine or service through modules. The glossary defines idempotent as an operation whose result is the same performed once or repeatedly. Ansible is agentless and push-based and is used more for configuring what runs inside machines than for creating cloud resources (see Ansible vs Terraform).

Declarative does not mean “cannot delete anything by surprise”. ARM has two deployment modes. Incremental is the default: resources in the template are added or updated and other resources in the group are left alone. Complete deletes resources in the resource group that are not in the template. Microsoft now recommends incremental mode and says to use deployment stacks when deletion is wanted, because complete mode will be gradually deprecated. Whatever mode you use, run what-if first.

Incremental mode has a second trap. A redeployed resource has all properties reapplied: properties you leave out of the template are reset to defaults, not preserved. The template is the final state, not a patch.

Which exams test this

How exam questions are built around it

Questions rarely ask for a definition. They describe a team problem and ask which approach fixes it.

• “Environments drift”, “snowflake”, “must be reproducible” point to IaC kept in source control, edited in the source rather than in the target.
• “Desired state”, “regardless of current state”, “run repeatedly” point to declarative and idempotent. A script with if checks can be idempotent too, but it is the author’s work; the declarative tool gives it by design.
• “Preview the changes” points to what-if for Bicep and ARM, plan for Terraform.
• “A resource disappeared after redeploying” points to complete mode, or to a property left out of the template.
• “No state file to maintain” points to Bicep over Terraform. “Multiple clouds” points to Terraform. For the Azure-only choice see ARM vs Bicep vs Terraform.
• State inside a machine (packages, services, files) points to configuration management such as Ansible or Azure Machine Configuration, not to a resource template.

The usual wrong answer is a script chosen for “automation”. A script automates, but only a declarative definition gives the repeatability and preview the stem asks for.

Practice questions

Go deeper

• What is infrastructure as code? (Microsoft Learn)
• What is Bicep? (Microsoft Learn)
• ARM deployment modes (Microsoft Learn)
• Terraform introduction (HashiCorp)
• Related on this site: CI/CD explained, YAML pipelines basics, Git branching strategies, and the skills outline guide.