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.
"Infrastructure as Code" is not one pile of YAML, and "we do IaC" is not one claim. Teams split it into layers that use different tools, live in different repositories, and often belong to different people.
| Layer | What you declare | Example tools |
|---|---|---|
| Cloud resources | Storage accounts, networks, databases, compute | Bicep (this week), Terraform, ARM |
| Data platform assets | Warehouse jobs, notebooks, pipelines, grants | Databricks Asset Bundles (DABs), dbt project files, Airflow DAGs in Git |
| App / service config | Container images, env vars, app settings | Docker + ACA/ACR definitions, GitHub Actions |
You declare an Azure storage account and a nested blob container in Bicep, then deploy them with az. The thing you are creating did not exist before, and after teardown it does not exist again. That is the layer the assignment grades, and it is the layer people usually mean when they say "infrastructure".
The tell: the resource shows up in the Azure portal under a resource group, and it appears on the bill.
Here the platform already exists. Somebody provisioned the workspace or the warehouse, probably with the layer above. What you declare is what runs on it: a job, a notebook, a model, a set of grants.
In Week 13 you configured a Databricks Job in the UI. The code-shaped version of that is Databricks Asset Bundles: a databricks.yml in git, deployed with databricks bundle deploy. Week 12's Airflow DAGs in git are the same idea for orchestration. dbt project files are the same idea for models.
The tell: deleting it does not release any cloud resource. The compute and storage underneath keep existing.
The layer closest to the application: which image runs, which environment variables it gets, which secrets it can read. Week 5's Docker work and Week 6's Container Apps job configuration live here, and much of it is expressed in the same GitHub Actions workflows you already write.
<aside> 📝 Why not one tool for all three? Bicep cannot usefully own a Databricks Job definition the way a bundle can, and a bundle cannot create the Azure storage account under your resource group. Real teams use both: Bicep or Terraform for the cloud shell, then bundles / dbt / Airflow-in-git for what runs on the platform.
</aside>
A mistake in the cloud-resource layer can delete a database. A mistake in the platform layer usually breaks a job run you can re-trigger. Teams review and gate the two layers differently for exactly this reason, and the cloud layer is the one that gets the required approvals.
The cloud layer is often owned by a platform or cloud team who will not merge your pull request quickly. The platform layer is usually owned by the data team itself. Knowing which layer your change is in tells you who you are waiting on, and it is a common source of "why is this taking three days" frustration in a first job.
Cloud resources change rarely and live for years. Platform assets change every sprint. Putting them in one repository with one pipeline means every job tweak re-runs a plan against your production network, which nobody wants.
| Week | What you built | Layer |
|---|---|---|
| Week 12 | Airflow DAGs in git | Platform assets |
| Week 13 | Databricks Job (UI), and Asset Bundles as the code version | Platform assets |
| Week 14 | Storage account and container in Bicep | Cloud resources |
| Weeks 5 to 6 | Dockerfile, Container Apps job config | App / service config |
You only need to recognise the split. When someone says "we do IaC", ask which layer they mean. The answer tells you what their pipeline actually protects.
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.