Quartz 5

Azure from Zero — Foundation Path

Properties1
tagsaz-104, foundation, beginner, sequential

5 min read

Azure from Zero — the Foundation Path

Start here if you’ve never used Azure. This is the sequential onboarding the rest of the vault assumes. Do these in order — each step builds on the last. If you’re already comfortable administering Azure, you can skip ahead to the learning paths.

How to use this path

  1. Follow the numbered steps in order — they’re deliberately sequenced so you never meet a term you haven’t been prepared for.
  2. Each step links to a concept note (the “one page” explanation) plus a what-to-try.
  3. At the end of each section is a ✅ Checkpoint — if you can’t answer it, re-read that step before moving on.
  4. Time estimate: 2–4 hours if you’re new; 30–60 min for a familiarization pass.

Step 0 — Start with a workload, not a product

Azure resources only make sense when they support something a person or team owns. Read Workload, then describe the disposable training workload you will use throughout this path:

QuestionTraining answer
What outcome does it provide?A tagged training storage account that proves the control-plane loop.
Who owns the change and the cost?You, in a non-production subscription.
What runs and where is the boundary?Azure Storage; its public access remains disabled.
How does it authenticate and authorize?A test Entra group receives Azure RBAC at the resource-group scope.
How is it deployed, observed, recovered, and removed?Bicep through ARM; portal/CLI evidence; resource-group deletion.

Checkpoint: Point to the owner, identity, authorization scope, runtime/data service, network boundary, deployment path, observability evidence, recovery action, and cost owner. If any answer is unknown, the workload is not ready to create.

Step 1 — What is cloud computing?

Before anything Azure, grasp the responsibility model:

  • IaaS / PaaS / SaaS — the three service models and who manages what
  • Public cloud vs on-prem — Microsoft operates the underlying cloud infrastructure; you still own data, identities, access, and the cloud components you control.
  • Why cloud → on-demand capacity, managed services, and usage-based pricing whose meter and commitment vary by service

Try: Review the free-account offer and pricing for the service you intend to create. A free account or an unused resource does not guarantee zero cost.

Checkpoint: Explain why an IaaS VM leaves you responsible for its guest OS, while an App Service app shifts VM/OS operation to Microsoft but leaves you responsible for code, identity, configuration, and data.

Step 2 — The resource hierarchy (the mental model)

This is the single most important thing to grok first. Read in order:

  1. Management groups — group subscriptions
  2. Subscription — the billing + resource container
  3. Resource groups — logical grouping of resources
  4. Tenant — the separate container for identities
  5. Scope — how governance and RBAC apply

Checkpoint: “If I have a subscription in a management group, and I put a resource group in the subscription, where does a VM live?” Answer: in the resource group. Management groups and subscriptions are above it for governance, RBAC inheritance, and billing. The tenant is the separate identity directory trusted by the subscription.

Step 3 — Azure geography

  1. Regions
  2. Availability zones (why regions are paired)

Checkpoint: “Why would I choose westeurope over eastus2?” — latency to your users, data-residency, and service availability.

Step 4 — The control plane: ARM

  1. Azure Resource Manager (ARM) — the engine every management action goes through
  2. ARM templates & Bicep — declarative provisioning (ARM JSON or Bicep)

Checkpoint: “Every portal button, CLI command, and template eventually calls what?” — ARM.

Step 5 — The tools to drive it

  1. Azure portal
  2. Azure CLI / PowerShell
  3. Cloud Shell

Try one: in the portal’s Cloud Shell run az account show then az group list. Checkpoint: “What’s the difference between portal and ARM?” — portal/CLI/Shell are clients; ARM is the service that applies the change.

Step 6 — Identity and access (you can’t admin what you can’t authenticate)

  1. Microsoft Entra ID (the identity service)
  2. User accounts and groups
  3. RBAC — who can do what, where (the authorization model)
  4. Role definitions and role assignments

Checkpoint: “Who grants a user access to a VM?” — via an RBAC role assignment (for example, Contributor at the resource-group scope).

Step 7 — Prove the control-plane loop

Complete the foundation, hierarchy, and least-privilege lab before any administration path. Record each step with the lab evidence template. The lab creates the workload described in Step 0, verifies both administrator and Reader behavior, deliberately causes an authorization failure, restores the intended boundary, and removes the resources.

Checkpoint: Show the resource group, deployment, role assignment, failed Reader create attempt, restored Reader state, and cleanup evidence. You should now understand that ARM applies a requested management operation only after Entra authentication and RBAC authorization at a scope.

Step 8 — Where the modules plug in

Now that you have the mental model, the AZ-104 learning paths make sense:

  1. Manage identities and governance
  2. Configure and manage virtual networks
  3. Implement and manage storage
  4. Deploy and manage compute
  5. Monitor and back up resources

The mental model in one picture

Cloud model (IaaS/PaaS/SaaS)
        │
        ▼
Tenant (identities) ── trusts ──▶ Subscription (billing)
Management group ─▶ Subscription ─▶ Resource group ─▶ Resource
Region / Availability zone  (where things physically live)
        │
        ▼
ARM (control plane) ─▶ Portal ▌ CLI ▾ Cloud Shell
        │
        ▼
Microsoft Entra ID + RBAC  (who can do what, where)

Tenant · Subscription · Resource group · ARM · Entra ID · RBAC · Regions

Synthesis challenge

After the five AZ-104 paths, complete the integrated administration challenge.

Sources and re-audit

Re-audit when the Azure hierarchy, control-plane model, Cloud Shell behavior, or workload guidance changes.

Conceptual checkpoint

Explain the sequence in this path using one workload scenario: identify the boundary being changed, the identity or tool acting on it, the expected evidence, and the failure that would change your decision.

Graph View

Backlinks