Your first Bicep deploy: a storage account as code.

Read the step before copying. Bash commands belong in Git Bash on Windows or Azure Cloud Shell set to Bash; PowerShell uses different syntax. A JSON, YAML, Bicep or application-code example belongs in the named file, not directly at the terminal prompt. Follow any shell-specific instructions below.

Keep the same terminal open so earlier variables remain available. Copy one complete command block without the terminal's $ prompt. A backslash continues a command onto the next line. If Bash shows a lone >, it is waiting for the rest of a quote, command or file block. Finish the complete block; if the paste was incomplete, press Ctrl+C and copy it again. Do not paste the next step into an unfinished command.

A line such as RG="training-group" stores a value without printing it. Output captured with $(...) is also stored; a blank screen alone does not prove failure. A sleep deliberately waits, and -o none suppresses normal output. Wait for your normal prompt, then run the step's checkpoint. After an error, stop and keep the exact command and message; later steps cannot repair a missing resource. Never share passwords, access tokens or secret values in a screenshot.

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.

Coming straight from Class 12? You have not met Git or Bicep yet, and you do not need either to start. Use the first path: it writes the template with the same file block you practised in the terminal warm-up. If you have done Classes 17 and 20, the second path clones the full version from the repository.

Path 1, no Git. Open Cloud Shell (Bash, which already has Bicep), make a folder, and write the file. Paste the whole block, from cat down to the line that says only EOF:

mkdir -p first-bicep && cd first-bicep
cat > main.bicep <<'EOF'
param location string = resourceGroup().location
param sku string = 'Standard_LRS'

resource storage 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: 'campux${uniqueString(resourceGroup().id)}'
  location: location
  sku: {
    name: sku
  }
  kind: 'StorageV2'
  properties: {
    minimumTlsVersion: 'TLS1_2'
    allowBlobPublicAccess: false
    supportsHttpsTrafficOnly: true
  }
}

output storageAccountName string = storage.name
EOF
az bicep build --file main.bicep && echo "compiles"

Read it as three parts, the same three choices you made by hand in Class 12:

• param lines are inputs with defaults. location borrows the resource group's region; sku is the redundancy dial, LRS to start.
• The resource block is the storage account. The text in quotes after resource storage is its type and API version. uniqueString(...) builds a name no one else has, because storage names are global. The three properties are the secure settings from Class 12: modern TLS, no anonymous blob access, HTTPS only.
• output hands one value back after the deploy, here the account's name, so you do not have to look it up.

az bicep build only checks the file and turns it into the JSON Azure reads; it creates nothing. If it prints an error with a line number, compare that line with the block above. If it prints compiles, carry on.

Path 2, after Class 17. The repository version adds descriptions, allowed values, tags and two more outputs. Same steps after this point.

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

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

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:

Commands inside $(...) save their output in a variable. Check the printed identifier or the checkpoint before continuing.

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

Run the exact same preview again, against the resource you just created:

az deployment group what-if --resource-group "$RG" --template-file main.bicep

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

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

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.