Challenge - Configure Remote State and Backend Migration

Terraform records what it has built in a state file. By default that file sits on the local disk of whoever ran terraform apply, which is fine until a second engineer joins. Then there are two state files, each describing a different version of reality, and the next apply either duplicates resources or destroys ones it does not recognize. Local state has no locking either, so two people running apply at the same moment can interleave writes and corrupt the record of what actually exists.

A remote backend moves that file to shared storage. With the azurerm backend, state lives in a blob container in an Azure Storage Account: encrypted at rest, versioned by the storage account, and locked through a blob lease so a second apply waits rather than collides. Terraform can move an existing local state into a backend without touching a single deployed resource, because state describes infrastructure rather than defining it. Getting that migration right is the difference between a clean handover and a plan that offers to rebuild everything you already have.

By completing this Intermediate challenge, you will be able to:

• Configure an azurerm remote backend so Terraform stores its state in Azure Storage instead of on local disk
• Migrate an existing local state file to a remote backend without recreating or destroying any resource
• Confirm a migrated backend is operational by proving a fresh plan reports no drift
• Explain where Terraform keeps its state before, during, and after a backend change

Prerequisites

Before attempting this challenge, you should be comfortable with:

• Writing and editing Terraform configuration files (HCL syntax)
• Understanding Terraform state and backend configuration
• Running Terraform CLI commands (init, plan, apply)
• Navigating Azure Storage Accounts and blob containers

Recommended Lab: Introduction to Azure Terraform