Week 14 - Infrastructure as Code
Why use Infrastructure as Code
A single place to look up every Infrastructure as Code and Bicep term you meet this week. Entries are ordered by the chapter that first introduces the term: each term lives in exactly one place, and each chapter back-links to its glossary entry on first use. Skim the section for the chapter you are reading; the section above it covers terms you have already met.
Creating and configuring cloud resources (a storage account, a database, a job) so they exist and are ready to use. Until this week, teachers provisioned the Azure stack you used; now you provision resources yourself with Bicep. (Used in Why use Infrastructure as Code)
Defining cloud resources in version-controlled files and creating them with a deploy command, instead of clicking through a portal. The file is the source of truth. (Used in Why use Infrastructure as Code)
The gap that opens when live infrastructure no longer matches what anyone wrote down or intended, usually because someone changed a setting by hand in the portal. (Used in Why use Infrastructure as Code)
Azure's native language for Infrastructure as Code. You write readable .bicep files; tooling compiles them to ARM templates that Azure deploys. (Used in Why use Infrastructure as Code)
Azure Resource Manager templates: the JSON format Azure understands underneath (often called ARM JSON). Bicep compiles to ARM; you rarely hand-write the JSON. (Used in Why use Infrastructure as Code, Azure Bicep)
An approach that lists the steps to reach a result (for example a bash file of az storage account create commands). Scripts are usually imperative; you must handle "already exists" yourself. (Used in IaC concepts)
An approach that describes the end state ("there should be a storage account named X in region Y") and lets the tool work out the steps. Bicep is declarative. (Used in IaC concepts)
Running the same operation many times has the same effect as running it once. Deploy an unchanged template twice and Azure makes no meaningful second change. (Used in IaC concepts)
Separate deployments of the same template (for example dev, staging, prod) that stay identical except where parameters intentionally differ. (Used in IaC concepts)
Inputs you supply at deploy time so one template can produce different environments without editing the file. In Bicep they are declared with param. (Used in IaC concepts)
Azure's control plane: the HTTP APIs that create, update, and delete resources. The portal, the az CLI, and Bicep deploys all call these APIs. (Used in IaC concepts)
A domain-specific language: a small language designed for one problem area, not for general programming. Bicep is a DSL for declaring Azure resources and settings. Contrast with general-purpose languages like Python or JavaScript. (Used in Azure Bicep)
A declaration of a cloud object to create or update, written with the resource keyword and a type string such as Microsoft.Storage/storageAccounts@2023-01-01. (Used in Azure Bicep)
A value computed inside the template for reuse, declared with var. Unlike parameters, variables are not supplied at deploy time. (Used in Azure Bicep)
A value the deployment returns after success (for example a resource ID), declared with output. Useful for wiring later steps or checking what was created. (Used in Azure Bicep)
The date suffix on a Bicep resource type string (for example @2023-01-01). It pins which Azure Resource Manager schema that resource uses. (Used in Azure Bicep)
The Azure portal blade on a resource group that lists every deployment: template, parameters, time, and result. The auditable history portal clicks never leave. (Used in Azure Bicep)
A Bicep file you call from another Bicep file so you can define a resource once and reuse it (for example modules/storage.bicep). (Used in Bicep in practice)
A Bicep resource declared under a parent with parent: (for example a blob container under a storage account). Azure creates it inside the parent; deleting the parent usually removes the child too. (Used in Bicep in practice)
Parameters marked @secure() so Azure Resource Manager does not save their values to deployment history and does not log or display them. Still avoid putting real secrets in git. (Used in Bicep in practice)
Azure's managed secret store. For real secrets, templates can reference vault values at deploy time so passwords never sit in the Bicep file or your terminal history. (Used in Bicep in practice)
An Azure CLI preview (az deployment group what-if) that shows what a deploy would create, change, or leave alone before you apply it. Useful for spotting drift. (Used in Bicep in practice)
Bicep's default deploy behavior, which Azure names incremental mode: create or update resources declared in the template, but do not delete a resource just because you removed it from the file. Teardown is a separate, explicit step. The opposite setting, complete mode, deletes whatever the template leaves out; Microsoft marks it not recommended and is retiring it in favour of deployment stacks. (Used in Bicep in practice)
The planned create (+) and modify (~) lines from a what-if preview (or the same preview in a CI log). You review that diff before you apply the template. Related to a git file diff in a PR, but here the subject is Azure resource changes, not source files. (Used in Deploy Bicep from CI/CD)
A machine identity (app registration + credentials) that GitHub Actions uses instead of interactive az login. Same idea as Week 5's ACR push: see service principal there rather than redefining it here. (Used in Deploy Bicep from CI/CD)
The GitHub Actions secret that holds the service principal JSON (clientId, clientSecret, subscriptionId, tenantId) consumed by azure/login. For Week 14, fetch your copy from Key Vault as azure-credentials-week14-<yourname>, then paste it into the repo secret. Never commit that JSON. (Used in Deploy Bicep from CI/CD)
<aside> 💡 If a word is new, add your own one-sentence note next to it. A glossary you have edited is much stickier than one you have only read.
</aside>
This page is supplementary. Nothing here is tested directly; use it as a lookup while you work through the numbered chapters and the assignment.
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.