Chapter 12 Terraform: Language & Workflow
HCL, providers and the lock file, variables and types, expressions and functions, data sources, count vs for_each, and the core workflow read like a reviewer.
In plain words
Imagine a LEGO set that comes with instructions showing the finished castle, not the steps. You hand the picture to a robot builder. It looks at the table, sees what is already built, and adds, swaps or removes bricks until the table matches the picture. If the castle is already right, it does nothing. If you change the picture (add a tower), it adds only the tower.
Terraform is that robot for cloud infrastructure. The picture is your .tf files (HCL), the robot's memory of what it built is the state, and the bricks are resources like azurerm_resource_group or azurerm_subnet. terraform plan shows what the robot would do; terraform apply does it. This chapter teaches the language of the picture and how to read the robot's plan before saying yes.
Why it matters on call
On a platform team, most infrastructure changes arrive as a Terraform pull request. Your job is often not writing the module but reading the plan in the PR and spotting the line that says # forces replacement on a storage account full of data, or a count list edit that will destroy four subnets to remove one. That is the difference between a boring Tuesday and an outage.
This chapter also covers the language half of the Terraform Associate exam (types, expressions, functions, count vs for_each, workflow flags), and the classic interview warm-ups: declarative vs imperative, Terraform vs Ansible, what init actually does. It comes after networking (Ch 8-9) because the examples build networks and subnets (a VNet is Azure's private network), and before state and modules (Ch 13), because you need to read HCL fluently before you can reason about where state lives. No cloud knowledge is assumed: each Azure resource is explained where it first appears.
Lessons
- What Terraform is for, and the blocks it is made of
- Providers, versions and the lock file
- Variables, locals and outputs
- Types, validation and custom conditions
- Expressions: references, operators, for, splat and templates
- Functions: the ones you use every day
- Data sources, references and the dependency graph
- count vs for_each - the one that causes outages
- The workflow, read like a reviewer
20 hands-on labs (missions, incidents and drills) run in the terminal: Open this chapter in the terminal Free, in your browser - a real Ubuntu terminal to try it in, with missions that check your work.
Questions people ask
Is Terraform the same thing as Azure Bicep or ARM templates?
Same idea, different scope. Bicep and ARM are declarative too, but Azure-only, and Azure itself tracks what was deployed. Terraform works with any provider (Azure, AWS, GitHub, Cloudflare) and keeps its own state file that you must store and protect. Teams pick Terraform when they want one workflow for everything, including non-Azure things, and one review process. The price is that state becomes your responsibility, which is what Ch 13 is about.
Do I need Ansible if I have Terraform?
They solve different problems. Terraform provisions: the VM, the network, the storage, the secret vault. Ansible (or cloud-init, or a prepared image) configures what runs inside a machine: packages, files, services - the Ch 1-2 work, automated. When most things run as containers (Ch 10-11), you often need little Ansible, because the "inside" is the image. You can technically run scripts from Terraform with provisioners, but that is a last resort; configuration management tools do it better and re-run cleanly.
What exactly is HCL, and is it just JSON?
HCL (HashiCorp Configuration Language) is a configuration language with blocks, arguments and expressions: references, conditionals, for loops, templates and about 120 built-in functions. It is not a general programming language (no user-defined functions, no arbitrary loops), which keeps configurations readable and plannable. Terraform also accepts a JSON syntax (.tf.json) meant for machine-generated code, but humans write HCL.
Why is the plan so important if apply shows it anyway?
Because the plan is the review. terraform plan -out=tfplan saves exactly what will happen, a human (or a policy check) reads it, and terraform apply tfplan does exactly that and nothing else. A bare terraform apply re-plans, and the world may have changed between your review and the apply. In CI the saved plan is the file a human approves before it is applied.
Does Terraform roll back if an apply fails halfway?
No. Whatever was created before the error exists in the cloud and is recorded in state. There is no transaction across cloud APIs. You fix the cause (a quota, a name conflict, a missing role) and apply again; Terraform compares code with the new reality and continues. This is why small, frequent applies are safer than one giant change.