Scripting for cloud engineers

Not everything deserves a pipeline. "Find every disk nobody is using." "Tag these forty resource groups." "Report which storage accounts allow public access." These are questions and chores, not infrastructure — running them through a pull request would be ceremony, and clicking through forty portal blades would be a morning. This is scripting country, and Azure gives you three respectable citizens of it. The choice between them is less important than beginners fear and more shop-dependent than partisans admit — but each has a home ground.¹

The honest guidance: learn the az CLI cold, because it is the lingua franca of every pipeline you built this phase; be conversant in PowerShell, because half the shops that interview you run on it; and know when a task has outgrown both and deserves Python. What follows — idempotency, loud failure, querying — applies identically to all three, because the discipline is the skill. The syntax is a costume.

Here is the question that sorts scripts from hazards: what happens when it runs twice? Scripts run twice constantly — a network blip mid-run, a colleague who did not know you already ran it, a scheduler that fired during the retry of the previous firing. A script that behaves differently on the second run is a coin toss wearing a file extension.

Idempotency

The property that running a script once or five times produces the same end state. Achieved by describing outcomes rather than actions: "ensure the group exists", never "create the group"; "set the tag", never "append to the list".

You have met this property twice already — it is why the same Bicep file deploys safely a hundred times, and why Terraform plans converge. Scripts have no engine doing that work for them, so you supply it, two ways. First, prefer verbs that are already idempotent: az group create succeeds harmlessly if the group exists with the same settings, and az tag update --operation merge sets a tag to a value rather than piling values up. Second, when the verb is not idempotent, check before acting: query whether the thing exists, and only create it if not. The anti-patterns to hunt in review are the ones that accumulate — names built from $RANDOM or timestamps (each run makes a new resource), appends to files or lists (each run makes them longer), counters incremented (each run drifts further). Drill 04 will hand you one of these and ask you to spot it; production will do the same, less politely.

The default behaviour of a shell script is the worst possible one: a command fails, and the script keeps going. Picture the two-line horror — line one, az account set --subscription prod-uction fails on the typo; line two, the cleanup loop runs anyway, in whatever subscription the shell happened to be pointed at. The Class Two dev environment, deleted by a script aimed at prod's leftovers. Loud failure is not a style preference; it is the difference between an error message and an incident.

Stop at the first error

Bash: set -euo pipefail at the top of every script — exit on error, on unset variables, on failures inside pipes. PowerShell: $ErrorActionPreference = 'Stop'. One line, non-negotiable, first thing a reviewer looks for.

Assert your context

Before anything destructive, prove you are where you think you are: query az account show and compare the subscription id against the one you intend. Wrong context is the classic scripting disaster, and it is one if statement away from impossible.

Exit with meaning

Exit code zero means success — to schedulers, pipelines, and the next script. A script that prints an error but exits zero tells every machine downstream that all is well. Fail with a non-zero code, and let Class Twenty-Two's workflows turn that into a red check somebody sees.

Notice the common thread with the whole phase: machines act on what your code signals, not what it prints. A pipeline cannot read a sad message in a log; it reads exit codes. The three habits above cost five lines total and convert the silent-continuation failure mode — the one that compounds for twenty minutes before anyone notices — into an immediate, visible, diagnosable stop.

Every az command returns JSON, and buried in that JSON is the one fact you wanted. The --query parameter — JMESPath, a query language for JSON — extracts it without a single line of parsing code. Four shapes cover nearly everything you will do:

# 1 · reach into one object
az account show --query id -o tsv

# 2 · project one field from a list
az disk list --query "[].name" -o tsv

# 3 · filter, then project
az disk list --query "[?diskState=='Unattached'].name" -o tsv

# 4 · filter, then shape a report
az disk list \
  --query "[?diskState=='Unattached'].{disk:name, gb:diskSizeGB, rg:resourceGroup}" \
  -o table

Read them as a grammar: [] walks a list, [?…] filters it with a condition, .field reaches in, and .{new:old} reshapes the survivors into exactly the columns you want. Pair the query with the right output: -o tsv for values a script consumes, -o table for reports a human reads, and JSON — the default — when the next tool wants structure. The fourth example already is half of this class's deliverable: unattached disks, sized and located, in one command. What separates a one-liner from an audit script is only the discipline of §2 and §3 wrapped around it.²

Nobody gets hired for FizzBuzz in Bash. The script cloud engineers actually write, at every employer, forever, is audit-and-report: sweep the estate for a condition somebody cares about, and produce a list a human can act on. It changes nothing — which means it is safe to run anywhere, safe to schedule, and the perfect first script to put your name on. Here is the whole shape:

#!/bin/bash
# audit.sh — untagged resource groups + unattached disks
set -euo pipefail

EXPECTED_SUB="<campux-subscription-id>"
ACTUAL_SUB=$(az account show --query id -o tsv)
if [ "$ACTUAL_SUB" != "$EXPECTED_SUB" ]; then
  echo "Wrong subscription: $ACTUAL_SUB" >&2
  exit 1
fi

echo "== Resource groups with no owner tag =="
az group list \
  --query "[?tags.owner == null].name" -o tsv

echo "== Unattached disks (paid for, used by nobody) =="
az disk list \
  --query "[?diskState=='Unattached'].{disk:name, gb:diskSizeGB, rg:resourceGroup}" \
  -o table

A script is a decision that repeats.

Every lesson of the class is in those twenty lines: loud failure at the top, an asserted context before anything else, idempotent by nature because it only reads, and two JMESPath queries doing the work that would otherwise be an afternoon of portal tabs. Note what it deliberately does not do: delete anything. An audit script that reports is welcome everywhere; the moment it acts, it needs the full Class Eight conversation about permissions and the full §2 conversation about running twice. Report first. Deletion is a separate decision, made by a human reading your table — and making that table appear every Monday morning is one Class Twenty-Two scheduled workflow away.