Configuration Management and IaC Strategy

What it is

Infrastructure as code (IaC) describes servers, networks and services in files that a tool applies. Because the description is code, you can store it in Git, review it in pull requests, test it and deploy it repeatedly with the same result.

Configuration management is the related job of setting up the software and settings inside machines. The exam asks you to recommend a technology and then define a strategy: how the code is stored, tested and deployed.

How it works

Provisioning tools

Rule of thumb: an Azure only team that wants a native tool picks Bicep. A multi cloud organization or one already using it picks Terraform.

Configuration management tools

Mutable infrastructure is updated in place with a configuration tool. Immutable infrastructure is replaced: you build a new image or container and swap it in. Immutable avoids drift and is simpler to roll back.

A strategy for IaC

1. Source control. Keep infrastructure code in Git, in its own repository or beside the application. Use branches, pull requests and policies exactly as for code. Never keep secrets in it. Reference Key Vault secrets instead.

2. Structure for reuse. Use modules (Bicep modules, Terraform modules, template specs, Azure Verified Modules) and separate parameter files per environment (a .bicepparam file or .tfvars file) so the same code builds dev, test and production.

3. Automated testing.

4. Automated deployment. The pipeline deploys, not a person. Use environments with approvals. For production, run the preview, require approval, then apply the same plan.

5. Safe state handling.

• Terraform state must be stored remotely (an Azure Storage blob container is common), with locking so two runs cannot apply together. Do not commit state, which can hold secrets.
• ARM and Bicep have no state file, because Azure Resource Manager is the source of truth.

6. Drift detection. Drift is when real resources no longer match the code. Run what-if or terraform plan on a schedule, and block portal changes with policy or role assignments.

ARM and Bicep deployment details

param location string = resourceGroup().location
resource sa 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: 'stdemo${uniqueString(resourceGroup().id)}'
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}

In pipelines use AzureResourceManagerTemplateDeployment@3 or AzureCLI@2 with az deployment. In GitHub use the azure/arm-deploy action or run the CLI.

Choosing quickly

A worked scenario

A platform team manages networks and App Services in Azure. They write Bicep modules, keep a .bicepparam file per environment and run a pipeline that lints, runs what-if and posts the result on the pull request. After merge the pipeline deploys to test, then waits for approval before production. A nightly job runs what-if against production and alerts if it shows changes, which means somebody changed a resource by hand.