§1
The nine, one line each
The order is the argument: you cannot automate what you cannot version, cannot review what is not in code, and cannot ship safely without a pipeline that gates itself. Git first, then infrastructure as code, then the pipeline that carries it — each class the prerequisite for the next.
- 17 · Git Fundamentals
- The object model underneath the commands: every change a named, revertible diff — and rebase and bisect to rewrite history cleanly and find the commit that broke it.
- 18 · Repositories & Collaboration
- How more than one engineer works on the same code without chaos — the pull-request flow, reviews, and traceability from a board item to the commit that closed it.
- 19 · Branching Strategies
- Trunk-based and its alternatives: feature flags to decouple deploy from release, semantic versioning, and a merge queue that keeps the trunk green.
- 20 · Infrastructure as Code: Bicep
- Azure's own declarative language — loops and conditions to describe the estate once, a linter to catch mistakes, and a diff you review before it lands.
- 21 · Infrastructure as Code: Terraform
- The multi-cloud alternative and the concept Bicep hides: state and its backend, modules, for_each, and import to bring existing resources under management.
- 22 · GitHub Actions Fundamentals
- The pipeline itself — triggers, jobs, steps — the machine that runs when you push.
- 23 · Actions → Azure with OIDC
- The pipeline authenticates to Azure with a federated token, not a stored secret — nothing to leak, nothing to rotate.
- 24 · Runners & Advanced Pipelines
- Where the work executes, and the patterns real delivery uses — matrices, protected environments with approvals, and publishing versioned packages.
- 25 · Scripting for Cloud Engineers
- The glue: Bash, PowerShell, and Python that automate what no template ships with — jq to parse JSON, retries for flaky calls, secrets kept out of the log, and loud failure.
§2
The ideas that stay
Tools churn fastest in this phase — and matter least. These five instincts outlast every runner, action, and syntax change.
- If it isn't in Git, it doesn't exist
- Version control is not a backup; it is the single source of truth a team reviews, reverts, and reasons about.
- Declare the end state
- Infrastructure as code describes what should exist, not the steps to get there. A re-run changes nothing if reality already matches — idempotency is the whole point.
- The pull request is the gate
- Change is proposed, previewed, and reviewed before it touches production. The plan-on-PR, deploy-on-merge loop is professional delivery in one sentence.
- No secrets in the pipeline
- OIDC federation removes the stored credential entirely — the same instinct as Phase One's managed identity, now applied to CI/CD.
- Automate, then fail loudly
- A script that fails silently is worse than no script. Guardrails and loud errors are what make automation safe to trust.
If it isn't in Git, it doesn't exist.
§3
What you can now do
These are the capabilities a team hands a mid-level engineer — and now ones you could take on day one.
| You can… | Built on |
|---|---|
| Rebase and bisect a Git history, and keep a trunk green with feature flags and a merge queue | Classes 17–19 |
| Author Bicep or Terraform — loops, modules, for_each — and import existing resources under state | Classes 20–21 |
| Preview a change with what-if or plan before anything is applied | Classes 20–21 |
| Build a GitHub Actions pipeline with matrices and protected environments that deploys to Azure on merge | Classes 22, 24 |
| Authenticate a pipeline to Azure with OIDC — zero stored secrets | Class 23 |
| Script routine operations in Bash, PowerShell, or Python — jq, retries, no secret in the log | Class 25 |
Case File · Campux Retail
The estate learns to deploy itself
Phase Three, seen through one client
Campux's clicked-together estate became code: the Build I governance written in Bicep, the Build II network described in a template, and a pipeline that plans on a pull request and deploys on merge with no secret in the repo. In Build III you close the same loop yourself — a merge that deploys, a bad change that rolls back — and it is the artifact that convinces an interviewer you have shipped, not just studied.
§4
In your head
Five questions, none answerable from a single class — each resolves only when two or three of the nine click together. Answer each in your head before you open the thread. Fast means it landed; slow means the thread names the class to revisit.
A change to production infrastructure must be reviewed by a second engineer before it can possibly land. What makes that reviewable in the first place?
The thread · Classes 17, 20The infrastructure is code in Git, so the change is a diff on a pull request — and a what-if or plan preview shows exactly what it would do before anyone approves. You cannot review a click; you can review a diff.
Your pipeline deploys to Azure every day. Where is the secret it uses to authenticate — and if the answer is "there isn't one," why not?
The thread · Class 23There is no stored secret. OIDC federation lets GitHub present a short-lived token that Azure trusts for that repo and workflow. Nothing is stored, so nothing can leak or expire in the night — the same lesson as the managed identity in Phase One.
The same deployment runs a second time with no changes to the template. What should happen, and what is that property called?
The thread · Classes 20–21Nothing should happen — no resource recreated, no change made. That is idempotency: the template declares the end state, reality already matches, so a re-run is safe to run a hundred times.
A single-cloud Azure shop asks whether to use Bicep or Terraform. Give a defensible answer and the one real trade-off.
The thread · Classes 20–21Either is defensible; the trade-off is state. Bicep is Azure-native and keeps no state file to manage; Terraform is multi-cloud but you own its state and its locking. For a pure-Azure shop, Bicep removes a moving part.
Two engineers need to change the same infrastructure in the same week without breaking each other. What lets them?
The thread · Classes 18–19Branches and pull requests over a trunk-based flow: each works on a branch, proposes a reviewed diff, and merges to the trunk. History records who changed what and why, and a bad merge is one revert away.
Notes
- A recap adds nothing new — if a line here is the first time an idea feels solid, the class it names is one click up in the index, and re-reading it now is time well spent. ↩
- Phase Three aligns to the AZ-400 (DevOps Engineer) ground. This page is not exam prep, but if you can do everything in §3 without notes, the exam's practical half holds few surprises. ↩
Now prove it · Phase Three milestone
Build III — The GitOps Loop