Week 14 - Infrastructure as Code
Why use Infrastructure as Code
This page is optional. Nothing here is required for Week 14's learning goals or the assignment. Back to the Going Further overview.
Week 14 teaches one tool. In an interview you will be asked why that one, and what you would use instead. This page gives you enough to answer honestly without claiming expertise you do not have.
| Tool | Cloud scope | Language | State |
|---|---|---|---|
| Bicep | Azure | Bicep DSL → ARM | Azure tracks deployments |
| ARM templates | Azure | JSON | Azure tracks deployments |
| Terraform | Multi-cloud | HCL | State file (remote backend in teams) |
| Pulumi | Multi-cloud | Python / TS / … | State file (Pulumi service or self-managed) |
These are two spellings of the same thing. ARM templates are the JSON that Azure Resource Manager actually accepts. Bicep is a friendlier language that compiles down to that JSON: when you run az deployment group create --template-file main.bicep, the CLI transpiles it first. You can watch this happen with az bicep build --file main.bicep --stdout, which prints the ARM JSON your five-line resource expands into.
Practically nobody hand-writes ARM anymore. You still meet it in three places: older repositories, templates exported from the portal, and error messages, which sometimes report positions in the generated JSON rather than in your Bicep.
Terraform is the multi-cloud option: one language (HCL) that provisions Azure, AWS, GCP, and hundreds of other providers. The core ideas transfer directly from this week. It is declarative, it is idempotent, and it has a preview step (terraform plan) that does the same job as what-if.
Two differences matter in practice:
terraform destroy, and delete lines in the plan, are first-class. That is the behaviour newcomers expect from Bicep and do not get, unless they use deployment stacks.Pulumi takes the same desired-state model but has you write a general-purpose language: Python, TypeScript, Go, C#. The appeal is loops, functions, and unit tests in a language you already know rather than a DSL. The cost is that infrastructure code becomes as easy to over-engineer as application code. Recognition is enough for this week.
The honest short version:
Nobody should switch tools on the strength of a syntax preference. The genuine reasons are cloud scope, what your team already runs, and who has to operate the state.
<aside> 💭 Learning Bicep first is not a detour if you end up on Terraform. Desired state, idempotency, preview-before-apply, and parameterised environments are the same ideas in both. The syntax is the small part.
</aside>
Whichever tool wins the argument, the practices from this week transfer intact: templates live in git, changes go through pull requests, a preview runs before an apply, secrets stay out of the files, and someone still has to tear down what they created.
The HackYourFuture curriculum is licensed under CC BY-NC-SA 4.0 https://hackyourfuture.net/
Built with ❤️ by the HackYourFuture community · Thank you, contributors
Found a mistake or have a suggestion? Let us know in the feedback form.