§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 substrate of everything that follows: every change becomes a reviewable, revertible diff with a name attached.
- 18 · Repositories & Collaboration
- How more than one engineer works on the same code without chaos — pull requests, reviews, history.
- 19 · Branching Strategies
- Trunk-based and its alternatives: how teams keep shipping fast without shipping breakage.
- 20 · Infrastructure as Code: Bicep
- Azure's own declarative language — describe the estate, deploy it idempotently, review the diff before it lands.
- 21 · Infrastructure as Code: Terraform
- The multi-cloud alternative, and the concept Bicep hides: state, the file that remembers what exists.
- 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 actually executes, and the patterns — environments, approvals, matrices — real delivery uses.
- 25 · Scripting for Cloud Engineers
- The glue: the Bash and PowerShell that automate the tasks no pipeline template ships with — and how to fail loudly.
§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 |
|---|---|
| Use Git and a branching strategy to make every change reviewable and revertible | Classes 17–19 |
| Author Bicep or Terraform to deploy Azure infrastructure as reviewable code | Classes 20–21 |
| Preview a change with what-if or plan before anything is applied | Classes 20–21 |
| Build a GitHub Actions pipeline that deploys to Azure on merge | Classes 22, 24 |
| Authenticate a pipeline to Azure with OIDC — zero stored secrets | Class 23 |
| Script routine cloud operations in Bash or PowerShell, with loud failure | 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