Week 14 - Infrastructure as Code
Why use Infrastructure as Code
Every Azure resource you have used in this course was handed to you already built: the shared Postgres database, the storage account, the Container Apps job. In Week 6's Azure CLI chapter you even ran az group list to see the resource groups, and found that your account was deliberately blocked from creating one. Someone else provisioned (created and set up as cloud resources) all of it. This week you learn how that someone does the job properly.
The obvious way to create a cloud resource is to click through the Azure portal: fill in a form, press create, repeat. That works once, and it is fine for a throwaway exploration you will discard. It does not work when you need the same environment three times (dev, staging, production), when a teammate needs to reproduce your setup, or when you need to know six months later exactly what was configured and why. This chapter is about the alternative: Infrastructure as Code (IaC) (defining cloud resources in version-controlled files you deploy with a command).
By the end of this chapter, you should be able to:
Manual setup has three failure modes that get worse as a team grows. Picture one Azure VM created by clicking through the portal:
Standard_B2s, then next month someone resizes it by hand to fix an incident. Now the live VM no longer matches anyone's memory or notes. Multiply this across dozens of resources and nobody can say what production actually looks like.https://gist.githack.com/lassebenni/4f9b6611ef0feea4f090230bc7673191/raw/week_14__manual_vm_problems_visual.html
Infrastructure as Code (IaC) means defining your cloud resources in version-controlled files and creating them by running a deploy command, instead of clicking through a portal. The file is the source of truth: it says what should exist (desired state), it lives in git (version controlled), and deploying it produces exactly those resources every time (idempotent and repeatable).
That one change fixes all three failure modes:
Here is that idea as a tiny Bicep fragment for the same VM story: the size lives in the file, not in someone's memory.
// Excerpt: the VM size is declared in code (full template also creates VNet, NIC, public IP)
resource vm 'Microsoft.Compute/virtualMachines@2023-09-01' = {
name: 'vm-hyf-demo014'
location: location
properties: {
hardwareProfile: {
vmSize: 'Standard_B1ls' // change this here, then redeploy
}
// ... osProfile, storageProfile, networkProfile ...
}
}
Deploying the file is one Azure CLI command. This terminal capture is from a real deploy into a throwaway resource group in the class tenant:
https://gist.githack.com/lassebenni/1b203f20108b322e67b15cd3a5a28da6/raw/week_14__bicep_vm_deploy_terminal.html
After provisioningState: Succeeded, the portal shows the same truth the file declared: VM name, size Standard_B1ls, status Running.
Azure portal Overview for vm-hyf-demo014 after a Bicep deploy: Status Running, Size Standard B1ls, resource group rg-hyf-week14-demo, West Europe.
<aside>
⚠️ Demo only: this chapter uses a VM so the portal screenshot matches the failure-mode story above. Your Week 14 assignment deploys a storage account and nested container into $CLASS_RG, not a VM (VMs cost more and need networking your student role does not grant).
</aside>
Before you write any Bicep, lock in the three failure modes with a resource you already know.
<aside> ⌨️ Hands on: Pick one Azure resource you already used in this course (storage account, Postgres, or a Container Apps job). In three short bullets, write how portal-only setup could hit drift, no reproducibility, and onboarding friction for that resource. Keep it concrete (who changes what, what a teammate cannot reproduce).
</aside>
A storage account is a small example on purpose. The thing a data engineer actually provisions is a whole platform: the database, the registry, the job, the scheduler, the vault, the permissions. Every Azure resource you have used since Week 6 was written down by someone in exactly this way.
https://gist.githack.com/lassebenni/51b3167bdf3c329e210321f72c2e59f1/raw/week_14__data_platform_as_code_visual.html
The skill does not change with the resource type. A Databricks workspace is a different resource line in the same file, deployed with the same command.
On Azure, the native language for this is Bicep (Azure's native IaC language), and it is what you will write for the rest of the week. Bicep compiles to ARM templates (the JSON documents Azure Resource Manager actually accepts, which you rarely hand-write). In Week 6 you listed a resource group you were not allowed to create; by the end of this week you will deploy resources into that shared group (a storage account and more) as Bicep code. You still do not create the resource group itself.
<aside> 💡 Using AI to help: LLMs are genuinely good at scaffolding IaC templates from a plain-English description of what you want. The out-of-week Bonus - AI-assisted data enrichment uses AI in a data pipeline, but you can also lean on it this week to draft Bicep. Always read what it produces critically (⚠️ no real data, no PII).
</aside>
https://lasse.be/simple-hyf-teach-widget/mcq.html?bank=week_14_ch1_intro_iac_quiz&embed=1
If Infrastructure as Code still feels abstract, this ten-minute video makes the same argument from the other side: a developer who managed everything through the Azure portal, and what changed when he moved to code.
https://www.youtube.com/watch?v=a_mf8H7eQVc
The next chapter covers the concepts that make IaC work (declarative state, idempotency, drift) before you write any Bicep. This is a mental-model check. You are ready when:
<aside> 📚 For the IaC tool landscape, layers of IaC, and advanced Bicep, see the optional Going Further topic pages. None of it is required for Week 14.
</aside>
Next up: IaC concepts, where you learn the ideas behind IaC, declarative desired state, idempotency, and drift, before writing your first template.
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.