Infrastructure as Code on Azure with Bicep and Terraform

A Bicep file declares resources in a terse, readable syntax. Parameters (param) are inputs you supply at deploy time; resource blocks describe desired state, each pinned to a resource type and apiVersion. The excerpt below, the same storage account used throughout this lab, shows the whole pattern in seven lines: a name parameter and a storage account that inherits its resource group's location.

// main.bicep
param name string
resource sa 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: name
  location: resourceGroup().location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}

Expected output:

$ az deployment group create -f main.bicep -g tyf-rg --query "properties.provisioningState" -o tsv
Succeeded

The symbolic name sa is only a reference inside the file, it is not the deployed name and never appears in Azure. What lands in Azure is the value of the name parameter. Before deploying, compile and validate: az bicep build surfaces syntax errors with line numbers locally, and az deployment group what-if asks ARM what would change, without changing anything.

COMPILE AND PREVIEW (no changes made)

az bicep build --file main.bicep

az deployment group what-if \
  --resource-group tyf-rg \
  --template-file main.bicep \
  --parameters name=tyfiac01

The preview says exactly one resource will be created and nothing else will move, that is the green light to deploy for real. The create command is identical, minus the what-if operation.

What this teaches: Bicep is ARM JSON with the verbosity removed; it compiles to a template before anything reaches Azure.

Before writing any Terraform resources, decide where its state will live. The default is a local terraform.tfstate file, fine for a solo experiment, unacceptable for a team: two people running apply at once would race, and the file itself is easy to lose or leak. The azurerm backend stores state as a blob in Azure Storage and, crucially, takes a lease on the blob during every state operation, that lease is the lock that prevents concurrent applies from corrupting each other.

BACKEND CONFIGURATION, backend.tf

terraform {
  required_version = ">= 1.7.0"

  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.97"
    }
  }

  backend "azurerm" {
    resource_group_name  = "tyf-tfstate-rg"
    storage_account_name = "tyftfstate01"
    container_name       = "tfstate"
    key                  = "iac-lab.tfstate"
  }
}

provider "azurerm" {
  features {}
}

Expected output:

Initializing the backend...
Successfully configured the backend "azurerm"!
Terraform has been successfully initialized!

Three things to note here. First, the backend block cannot use variables, backend configuration is evaluated before anything else, so these values are literals (or supplied at init time with -backend-config). Second, the key is the blob name; use one key per environment so dev and prod state never mix. Third, features {} is a required empty block for the azurerm provider, forgetting it is a classic first-run error.

What this teaches: Remote state is what makes Terraform a team tool; local state is a single point of failure and confusion.

Now express the same infrastructure in Terraform's HCL. To keep the comparison honest, this configuration manages the same resource group and adds a second storage account, Terraform and Bicep each manage their own resource here, but through the same resource group, so you can see both tools' outputs side by side in one place. (Two IaC tools managing the same resource is an anti-pattern you should avoid in real environments; here the separation is explicit.)

TERRAFORM CONFIGURATION, main.tf

resource "azurerm_storage_account" "iac" {
  name                     = "tyftfdemo01"
  resource_group_name      = "tyf-rg"
  location                 = "canadacentral"
  account_tier             = "Standard"
  account_replication_type = "LRS"
  account_kind             = "StorageV2"
  min_tls_version          = "TLS1_2"

  tags = {
    deployedBy  = "terraform"
    environment = "dev"
  }
}

output "storage_account_id" {
  value = azurerm_storage_account.iac.id
}

Expected output:

$ terraform validate
Success! The configuration is valid.

The block label pair, "azurerm_storage_account" and "iac", is the resource's address inside Terraform (azurerm_storage_account.iac), and it is this address, not the Azure name, that the state file tracks. Run terraform fmt and terraform validate now; fmt normalizes layout, validate checks syntax and internal consistency against the provider schema.

What this teaches: HCL describes the same desired state in a different syntax; the concepts of plan, apply, and drift transfer directly.

terraform init does three jobs: downloads the azurerm provider from the registry, configures the remote backend, and migrates state into it (there is nothing to migrate on a first run). Watch its output for the backend confirmation line, if init silently falls back to a local backend, everything that follows loses the locking and sharing you set up.

Then the core workflow, chained: plan -out tf.plan computes the change set and saves it to a file, and apply tf.plan executes exactly that saved plan, not a recomputation of it. Saving the plan and applying the file (rather than running a bare terraform apply) guarantees that what you reviewed is what runs, which is why pipelines always use this two-step form.

Expected output:

Plan: 2 to add, 0 to change, 0 to destroy.
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

What this teaches: Plan is the what-if of Terraform; reading the diff before applying is the habit that prevents outages.

Drift is any difference between your code and reality. Create some deliberately: change a tag on the Terraform-managed storage account through the Azure CLI, simulating a well-meaning colleague editing in the portal. Then run a plain plan. Terraform refreshes its view of the live resource first, then compares, and reports the difference as a change it wants to make.

SIMULATE OUT-OF-BAND CHANGE, THEN PLAN

# A "portal edit", done via CLI for repeatability:
az resource tag --ids $(az storage account show -n tyftfdemo01 -g tyf-rg --query id -o tsv) \
  --set tags.environment=production

terraform plan -detailed-exitcode; echo "exit=$?"

Expected output:

$ terraform plan -detailed-exitcode
# azurerm_storage_account.demo will be updated in-place
~ tags = { "env" = "lab" -> "prod" }
Plan: 0 to add, 1 to change, 0 to destroy.

The -detailed-exitcode flag makes the result scriptable: exit 0 means no drift, exit 1 means an error, exit 2 means drift (changes pending). With no drift, the output is the one-liner below, this is the state you want to return to after remediation.

Bicep's equivalent drift check is what-if: re-run az deployment group what-if against main.bicep and any out-of-band change to tyfiac01 shows up as a ~ modify entry. Same idea, stateless implementation, ARM reads live state every time instead of consulting a state file.

What this teaches: Drift detection proves the state file is a snapshot, not a live view; reality always wins.

The fix for drift is not to edit the resource back by hand, that just creates a new unrecorded change. The fix is to re-apply the code, letting the tool converge reality onto the declared state. For Terraform that is another apply of a fresh plan; for the Bicep-managed resource it is re-running the same deployment. Afterwards, both drift checks should come back clean.

CONVERGE AND CONFIRM

terraform plan -out fix.plan && terraform apply fix.plan
terraform plan -detailed-exitcode; echo "exit=$?"          # expect exit=0

az deployment group create -g tyf-rg --template-file main.bicep --parameters name=tyfiac01 --query properties.provisioningState
az deployment group what-if -g tyf-rg --template-file main.bicep --parameters name=tyfiac01

Expected output:

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

Leave everything running. The Testing & Validation section checks this live environment, and cleanup happens at its end, not here.

What this teaches: Remediation through code keeps the repository as the single source of truth; manual fixes are undocumented by definition.