Victor walks Cloud Shell: clone, read main.bicep, what-if, deploy, re-run to prove idempotency, then tear down.
Imperative clicks vs. declarative code
There are two ways to create anything in Azure, and this lab is really about the difference between them. The imperative way is a command that does an action — az storage account create — fine for a one-off, but it leaves no record of intent and can behave differently on a second run. The declarative way is a file that describes the desired end state, and Azure makes reality match it. Re-running is safe and does nothing if reality already matches. That second way is how real infrastructure is managed, and Bicep is Azure's language for it.
By the end of the next twenty minutes you will have deployed a storage account from a template, previewed exactly what a deployment would do before doing it, and seen a re-run correctly report that there is nothing to change. Small resource; the point is the method.
A certificate claims. A template proves.
You need a free Azure account, the Azure CLI (az), then be signed in with az login. First time? The 15-minute Set up your machine page covers the account, the installs (winget / brew / apt), and sign-in. Prefer zero installs? Run everything in Azure Cloud Shell (Bash), preinstalled and already signed in.
Every CAMPUX lab lives in a public repo — the guide, the Bicep template, and any code. This page walks the same steps; the files are at github.com/kloudcaptain/campux-labs. Run everything in Azure Cloud Shell (Bash), where az and bicep are already installed.
Get the template and a place to put it
Open Cloud Shell, clone the repo, and open the lab's Bicep folder. Read main.bicep — it is four things every Bicep file is made of: parameters (inputs), an optional variable or two, resources (what to create), and outputs (values handed back).
# Windows/Git Bash: stop it mangling /subscriptions/... arguments (harmless on macOS/Linux)
export MSYS_NO_PATHCONV=1
git clone https://github.com/kloudcaptain/campux-labs.git
cd campux-labs/lab-first-bicep-storage/bicep
cat main.bicep
Now make a resource group to deploy into:
RG="campux-lab-bicep-rg" az group create --name "$RG" --location eastus
"provisioningState": "Succeeded", and cat showed you the template — parameters, one storage resource, three outputs. That whole file is your infrastructure.Preview with what-if — look before you leap
what-if shows exactly what a deployment would do without doing it. Professionals run this before every deploy; it is the difference between a change you understood and a change you hoped about.
az deployment group what-if --resource-group "$RG" --template-file main.bicep
+ Microsoft.Storage/storageAccounts/… — a Create. Nothing exists yet; this is only a preview of what applying the template would do.Deploy
az deployment group create --resource-group "$RG" --template-file main.bicep --name firstbicep
Read back what it made, straight from the deployment's own outputs:
SA=$(az deployment group show -g "$RG" -n firstbicep --query properties.outputs.storageAccountName.value -o tsv)
az storage account show --name "$SA" --resource-group "$RG" \
--query "{tls:minimumTlsVersion, publicBlob:allowBlobPublicAccess, sku:sku.name}" -o json
TLS1_2, publicBlob: false, and Standard_LRS. The secure settings are written into the template, so no deployment of it can quietly forget them — the reason to template storage instead of clicking it.The payoff: idempotency
Run the exact same preview again, against the resource you just created:
az deployment group what-if --resource-group "$RG" --template-file main.bicep
+ Create and no - Delete — your account is not being recreated. You will usually see No change. (Azure sometimes lists a few managed properties as ~ noise even when nothing meaningful changed — that is a known quirk, not your template rebuilding anything.) This is the whole point of declarative infrastructure: the file describes the end state, reality already matches, so a re-run does nothing. Safe to run a hundred times.Change the file, see the diff
Change one input — the redundancy SKU — and preview again. Bicep tells you precisely what would change, before anything happens:
az deployment group what-if --resource-group "$RG" --template-file main.bicep --parameters sku=Standard_GRS
~ Modify with sku.name: "Standard_LRS" => "Standard_GRS". You changed one value and the tool reported the exact effect in advance. Apply it for real with az deployment group create … --parameters sku=Standard_GRS if you like.Tear it down
Always the last step of every lab. Delete the group and confirm it is gone, so nothing lingers to bill you.
az group delete --name "$RG" --yes
az group exists --name "$RG" # -> false
az group exists returns false. Your subscription is back exactly where it started.What you can now honestly claim
You authored and deployed an Azure resource from a Bicep template, previewed a deployment with what-if, saw that a re-run of an unchanged template changes nothing, and read a precise diff before applying a change. That is the on-ramp to everything else in cloud engineering: real infrastructure lives in files like this one, under source control, reviewed before it ships. From here, the same ideas apply to something with access control — the next lab gives an App Service a managed identity and a least-privilege role, with a Bicep path built on exactly what you just learned.
- The three secure properties in the template — TLS 1.2 minimum, no public blob access, HTTPS only — are also current Azure defaults, so they will not by themselves show up as a change. They are written explicitly anyway, because "the default today" and "guaranteed in writing" are not the same promise, and the second is the one an auditor accepts.
- Times and costs are honest estimates. An empty StorageV2 account costs effectively nothing at rest, but the teardown step is not optional — a resource forgotten in a corner is how a free experiment becomes a line item.