Infrastructure as code (IaC)
Manage infrastructure through code and version control. Infrastructure definitions are versioned, reviewed, and deployed like application code. Enables reproducible environments and reduces configuration drift.
From template to resource group
param env string
param planSku string
resource kv 'Microsoft.KeyVault/vaults@2023-07-01' = { … }
resource st 'Microsoft.Storage/storageAccounts@2023-05-01' = { … }
resource sb 'Microsoft.ServiceBus/namespaces@2022-10-01-preview' = { … }
resource plan 'Microsoft.Web/serverfarms@2023-12-01' = { … }
resource func 'Microsoft.Web/sites@2023-12-01' = { … }
resource appi 'Microsoft.Insights/components@2020-02-02' = { … }
$ az deployment group what-if -g rg-crx-prod-weu -p prod.bicepparam
Resource changes: 6 to create.
rg-crx-prod-weu
0/6 resourcesIllustrative example
Choosing the tool
All three are mature options. The right one depends on your cloud footprint and on the skills already in the team.
Bicep
Microsoft's language for Azure Resource Manager. Concise syntax, support for new Azure features from day one and no state file to manage, because Azure itself is the source of truth. My default for Azure-only estates.
Terraform
A multi-cloud tool with a large provider ecosystem. It keeps a state file that must be stored securely, for example in an Azure Storage account with locking. A good fit when you also manage other clouds or services such as GitHub through code.
ARM templates
The JSON format that Bicep compiles to. Still fully supported but verbose; existing templates can be decompiled to Bicep as a starting point for a migration.
Practices that keep infrastructure code maintainable
- Modules. Reusable building blocks for common patterns, such as a function app with its storage, monitoring and identity.
- One template, many environments. Differences between Dev, Test and Production live in parameter files, not in copies of the template.
- Preview every change. Run what-if (Bicep) or plan (Terraform) in the pull request, so reviewers see exactly what will be created, changed or deleted.
- No manual changes in the portal. Portal edits cause drift. Changes go through code, and scheduled what-if runs reveal drift early.
- Guardrails with Azure Policy. Policies enforce naming, allowed regions, tags and security baselines, whoever deploys.
- Identities instead of secrets. Managed identities and Key Vault references keep connection strings and keys out of templates.
What about Dynamics 365 and Dataverse?
Dynamics 365 and Power Platform solutions are not deployed with Bicep or Terraform: they travel as solutions through their own pipeline. Environments, DLP policies and tenant settings can be managed with the Power Platform Terraform provider, and the Azure resources around them, such as Functions, Service Bus and Key Vault, are a natural fit for infrastructure as code. Both pipelines can run side by side.
See ALM & CI/CD for Dynamics 365