👨🏻 Brother Talk — Phase 01, Off the Record

No slides, no STAR method. This is me, your brother, telling you the things people only say after the second coffee. Read it once now, and again the week before your interview.

Listen. Almost everyone who's "good at Azure" can write a Bicep file and run a deploy. What almost nobody can do — and what instantly separates a senior from a principal in an interview — is explain what happens between the moment you hit Enter and the moment the resource exists. That gap, the inside of the deployment engine, is this whole phase. Once you can narrate it, ARM stops being a vending machine you put YAML into and becomes a system you operate.

Here's the thing that took me too long to internalize: ARM is not running your script. There is no script. You handed it a description of the world you want, and it figured out the order, did the diffs, and converged reality to match. The mental shift from "I'm telling the computer the steps" to "I'm declaring the end state and the engine reconciles" is the entire shift from imperative ops to infrastructure-as-code. Get that in your bones and you understand Terraform, Kubernetes, Bicep, and every reconciler ever built, because they're all the same loop: observe actual, compare to desired, converge.

Now let me give you the things that actually bite people.

Respect Complete mode like a loaded gun. I'm not being dramatic. The single most expensive Azure mistake I've watched happen — twice — is someone deploying in --mode Complete with a template that was missing a resource, and ARM deleting a production database to make the resource group match the file. And here's the part that matters for you: when it happened, the junior said "ARM has a bug, it deleted my DB." The principal said "no — Complete mode does exactly that, it's documented, and the real failure is that we deployed Complete without a what-if." The grown-up move isn't to fear the tool; it's to know its contract so precisely that you reach for it deliberately and never by accident. Default to Incremental. What-if before anything destructive. Lock the precious stuff. That's not caution, that's competence.

Idempotency is the most beautiful idea in this phase, and it's worth loving. The fact that you can run the same deploy a thousand times and the world doesn't drift — that the hundredth run is all NoChange — is why you can put infrastructure in CI and re-apply it on every commit without holding your breath. The whole modern practice of "infrastructure is code, reviewed in PRs, applied automatically" stands on that one property. When you build the lab and watch the second deploy come back all-NoChange, sit with it for a second. That green is the foundation everything else is built on. And learn where it cracks — a random resource name, an immutable property — because that's the bug that pages you at 2 a.m., when a deploy that should've been a no-op quietly recreated something.

The implicit-dependency thing is your party trick. Most people genuinely believe ARM deploys in the order you wrote the resources, or only in the order you put dependsOn. When you can look at a template and say "the NIC will deploy after the subnet even though there's no dependsOn, because the subnet.id reference creates an implicit edge" — you've shown you understand the engine, not just the syntax. That's a small thing that lands huge in an interview, because it proves you've been under the hood. Build the dependency extractor in the lab by hand and it'll be permanent knowledge, not a fact you memorized.

Don't skip the async part because the spinner hides it. az shows you a nice progress bar and then says "done," and it's tempting to think the PUT is the whole story. It isn't. Under that spinner is a poll loop checking provisioningState until it's Succeeded. The reason this matters: the day a deploy is stuck, the only useful question is "which resource's provisioningState is stuck, and why" — and if you've never thought about the async model, you'll just stare at the spinner feeling helpless. The principal pulls the deployment operations, finds the one resource that's Failed or blocked on quota or a policy modify, and fixes that. Calm in an incident comes from knowing what's actually happening, not from hoping the bar fills up.

The honest truth about this phase: the algorithm is not hard. Topological sort is a first-year data-structures exercise. Idempotency is one comparison. What makes this principal-level isn't the code — it's the judgment wrapped around it: knowing that Complete is a blast-radius decision, that what-if is a safety culture and not a command, that idempotency is a property you can break, that "deployed" means "polled to Succeeded." The lab is easy to pass and impossible to fully appreciate until you've connected each function to a real incident it would've prevented. So do that connecting. For every function you write, ask: what 2 a.m. page does this represent?

And here's the career angle, brother to brother. This phase is the keystone of all of IaC, which is half of this job. Terraform (next phase) is this same engine with a state file bolted on. Kubernetes is this same reconcile-to-desired loop. CloudFormation, Pulumi, Crossplane — same idea. If you truly own the ARM deployment engine — graph, idempotency, modes, async — you don't learn five more IaC tools, you recognize five more skins on the machine you already built. That's the leverage. That's why we start here. The people who plateau learn each tool fresh; the people who go principal learn the engine once and map everything to it.

Go build the engine. Watch the re-deploy come back all-NoChange. Then come find me in Phase 02 — that's where we put state and plan and ForceNew on top of this, and you'll see Terraform was never magic either.

— your brother 👨🏻