Phase 00 — The Azure Principal: Control Plane, Well-Architected & Tradeoffs

Difficulty: ⭐⭐☆☆☆ (conceptual) → the judgment it builds is ⭐⭐⭐⭐⭐ Estimated Time: 1 week (12–18 hours) Prerequisites: none — this is the orientation that makes the other 15 phases cohere

Why This Phase Exists

Before you touch Terraform, Entra ID, NSGs, or Service Bus, you have to understand what job you are actually being hired to do on Azure — because at the principal level the job is not "operate the portal," it is "make correct tradeoffs under conflicting requirements, and debug the layer everyone else stands on."

The reference JD says it plainly: this is "not a 'click in the portal' role and not a 'run one Terraform module' role. It is about owning the cloud platform layer itself." And the hardest part is "making correct tradeoffs" and being "the escalation point when it breaks at 2 a.m."

Two truths organise everything that follows, and this phase plants both:

1. There is exactly one control plane. Every write to Azure — a VM, a role assignment, a policy, a private endpoint — is an idempotent PUT to a resource ID through Azure Resource Manager (ARM). Authenticate (Entra token) → authorize (RBAC, then deny wins) → validate (Policy) → route to the resource provider. If you hold this one request shape, every later phase is "what does this provider do once ARM hands it the request?"
2. Every design is a tradeoff across five pillars. The Well-Architected Framework — Reliability, Security, Cost Optimization, Operational Excellence, Performance Efficiency — is the rubric every design review scores against. You cannot max all five; the principal names the pillar being traded, quantifies both ends with numbers (SLA math, the bill), chooses, and writes the ADR.

So Phase 00 builds the mental model and the calculator for those tradeoffs. Every later phase plugs a real Azure service into a slot in the model you build here. Skip this phase and you will learn 15 services and still not be able to architect — which is exactly the failure mode that keeps strong engineers stuck at senior.

Concepts

• Azure Resource Manager (ARM) as the single control plane. Every write is an idempotent PUT to a resource ID; ARM authenticates, authorizes (RBAC − NotActions, then deny wins), validates (Policy), then routes to the resource provider. Re-issuing the same PUT converges to the same state — the property the entire IaC model depends on.
• Control plane vs data plane. ARM/RBAC/Policy decide what exists and who may manage it (Actions); the blob, secret, message, and token are a separate system with its own identity, throttling, and SLA (DataActions). A storage Owner is not automatically a Blob Data Reader. This single distinction explains a huge fraction of "I have access but I'm getting 403" incidents.
• The resource ID hierarchy and scopes. The canonical ID /subscriptions/{s}/resourceGroups/{rg}/providers/{ns}/{type}/{name} is the unit of RBAC scope, Policy scope, tagging, and locks. Scopes nest Management Group → Subscription → Resource Group → resource, and assignments inherit downward. Resource providers (Microsoft.Storage, Microsoft.Network, …) own the types and must be registered.
• The Well-Architected Framework five pillars — Reliability, Security, Cost Optimization, Operational Excellence, Performance Efficiency — and how every design trades them against each other.
• SLA composition math. Serial dependencies multiply (A = ∏ Aᵢ — more hops, lower SLA); redundant components combine (A = 1 − ∏(1 − Aᵢ) — zones/regions raise it); and (1 − A) × 43 200 converts a nines-target into downtime minutes/month. Availability zones and paired regions are how you buy the redundancy term.
• Cost modeling basics & "spend the headroom." Compute hours × price, storage GB-month, and egress GB are the first-order bill; unused reliability or latency headroom is a cost lever, not a virtue.
• The Architecture Decision Record (ADR). The lightweight artifact that makes a tradeoff durable and reviewable: name the pillar, quantify both ends, choose, and record what would change your mind. A design review (interview Round 5) is a room pressure-testing your ADRs.

Labs

Lab 01 — WAF Tradeoff Modeler (flagship, implemented)

→ Lab folder: lab-01-waf-tradeoff-modeler/

Integrated-Scenario Suggestions (carried through the whole track)

These scenarios are the spine of the capstone (Phase 15). Keep them in mind from now — each later phase contributes a real, tested component, and each one forces the five-pillar tradeoff you model here:

1. A regulated multi-subscription landing zone — management-group hierarchy, policy-as- code baselines, RBAC inheritance, and subscription vending (P04–P05). Tradeoff: security & governance ↔ developer velocity.
2. A secure event-driven serverless platform — Functions + Durable + Service Bus + Event Grid behind Private Endpoints, secrets in Key Vault via Managed Identity (P10–P12). Tradeoff: reliability (exactly-once-effect) ↔ operational simplicity.
3. A global API front door — APIM with JWT scope authorization and token-bucket rate limiting, multi-region with Front Door (P09). Tradeoff: performance/availability ↔ cost (egress, duplicated compute).
4. A private-networking hub-and-spoke — NSGs, UDRs, Azure Firewall, Private DNS (P06). Tradeoff: security isolation ↔ operability (the #1 Private Endpoint DNS failure).
5. An observability + reliability backbone — Azure Monitor, KQL, alert rules, retry + circuit breaker + SLA composition (P13–P14). Tradeoff: cost (telemetry volume) ↔ fidelity / time-to-detect.

For each, write the one-paragraph WAF tradeoff now (which pillar dominates, what you'd trade, the number that decides it). You'll refine it as the matching phase lands.

Guides in This Phase

• HITCHHIKERS-GUIDE.md — the 30-minute orientation; read first
• WARMUP.md — the full zero-to-principal primer; read slowly
• BROTHER-TALK.md — the candid, off-the-record version

Key Takeaways

• The job is tradeoffs across five pillars, made on one control plane, encoded into platforms and defended in ADRs — not portal clicks.
• Every Azure write is one idempotent PUT to a resource ID. Control plane (manage) and data plane (the blob/secret/message) are different systems with different identity, throttling, and SLA. Owner ≠ Blob Data Reader.
• SLA and cost are arithmetic you do before the review, not after the incident: serial multiplies, redundant combines, nines convert to minutes, and the bill has a shape.
• "Make it reliable / cheap / fast" is not a requirement until you attach numbers to the pillars; this phase's lab is where you learn to attach them.

Deliverables Checklist

• Lab 01 implemented; all tests pass against solution.py and your lab.py.
• You can draw the control-plane request path (Entra → ARM → RBAC → Policy → RP) from memory and parse any resource ID into its scope.
• You can compose a serial and a redundant SLA in your head and convert it to minutes/month (99.9 % → 43.2; 99.99 % → 4.32).
• You can take any "design X on Azure" prompt and immediately name the dominant pillar and the pillar you'd trade.
• You can write a one-page ADR for a real decision (template in WARMUP.md).