AZ-104: Prerequisites & Core Architecture
Azure subscription
What it is
An Azure subscription is a logical container for Azure resources and the billing (cost) boundary for them. Every resource you deploy belongs to exactly one subscription, and you may have many subscriptions. A subscription is also a boundary for access management and resource limits/quota.
Why it exists
When you sign up for Azure you consent to a subscription and pay for the resources inside it. Subscriptions give you a way to separate environments, teams, and cost so you can govern, bill, and limit each one independently while all of it is administered centrally.
Key ideas
- Container + boundaries — a subscription is simultaneously a resource container, an accounting/billing unit, and an access boundary with per-subscription service quotas (limits).
- Trusts an Entra ID tenant — each subscription is trusted by one Microsoft Entra ID (tenant). The tenant holds the identities; the subscription holds the resources those identities may access (subject to RBAC).
- Exactly one target — every resource lives in exactly one subscription (and exactly one resource-group).
- Multiple subscriptions — used for environments (dev/test/prod), billing separation, or compliance; often organized under management groups.
- One Account Administrator owns billing; Service Administrators / RBAC roles control resources.
How it fits (diagram)
Exam notes
- One resource → one subscription → one resource group. Nothing exists outside a subscription & RG.
- Subscription = billing + access + resource-limit (quota) boundary. Its purpose is NOT performance/geography.
- Subscription trusts a tenant for authentication; it is not the same thing as the tenant.
- You can move a subscription between management groups; transfer billing ownership.
Related
Path MOC · management-groups · resource-group · scope · entraid · cost-management
📘 Source: Microsoft Learn — Subscription
Resource group
What it is
A resource group is a logical container for Azure resources that are deployed and managed together for a specific solution. Each resource belongs to exactly one resource group, and a resource group lives inside exactly one subscription.
Why it exists
Instead of managing every resource in isolation, you group the resources of an application/lifecycle into one container so you can deploy, update, delete, monitor, and secure them as a unit — and apply RBAC and Azure Policy at that scoped boundary.
Key ideas
- One place, one owner — a resource can be in only one RG (but can later be moved between RGs/subscriptions).
- RG location ≠ resource locations. The RG’s region is where the RG’s metadata is stored; the resources inside it can be in any region. This is a classic trap.
- Lifecycle unit — deleting a RG deletes all resources inside it (a boundary of operation, not of geographic data residency).
- Deployment scope — ARM deployments and templates/Bicep target a RG.
- Group by lifecycle + environment, not by resource type (that’s a common anti-pattern — mixing all VMs in one RG complicates lifecycle).
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: azure-resource-manager/management/manage-resource-groups-portal
Exam notes
- RG location is where metadata sits — the RG itself is not a physical place and stores no resources’ data.
- Deleting a RG deletes everything inside it.
- Move of a resource across RGs/subscriptions is possible but has constraints (recreate vs move, some resources can’t move).
- Use RG to scope RBAC assignments and policies at an application boundary.
Related
Path MOC · subscription · arm · scope · resource-tags · azure-policy
📘 Source: Microsoft Learn — Resource Group
Management groups
What it is
Management groups are containers you use to organize subscriptions into a hierarchy so you can apply governance (Azure Policy, RBAC, budgets) once at a higher level and have it flow down to every subscription beneath. Above them all sits a root management group.
Why it exists
A large organization with many Azure subscriptions can’t configure policy/RBAC per-subscription. Management groups let you apply one policy or role assignment at the root (or a subtree) and have it inherit to all child subscriptions — a single point of control at scale.
Key ideas
- Tree of subscriptions — hierarchy: root management group → management groups → subscriptions (and logical groups beneath them). Up to 6 levels of depth (excluding the root and the subscription level).
- Each subscription is under exactly one management group; management groups can nest.
- Inheritance — Azure Policy and RBAC assignments made at a management group are inherited by every subscription/resource below it.
- The root management group is created for you; assigning an Owner/User Access Administrator over the root gives org-wide control (grant sparingly).
- Used for consolidated cost/budget and compliance across teams/units.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: governance/management-groups/overview
Exam notes
- Management groups manage subscriptions; resource groups manage resources — two different levels of the same hierarchy.
- Max 6 levels of management-group depth.
- Assign Azure Policy at a management group to enforce compliance uniformly instead of per-subscription.
- Group subscriptions by function, geography, or environment for logical organization & governance.
Related
Path MOC · subscription · scope · azure-policy · rbac
📘 Source: Microsoft Learn — Management Groups
Azure Resource Manager (ARM)
What it is
Azure Resource Manager (ARM) is the deployment and management layer (control plane) for Azure. It’s the single REST service that handles every request to create, read, update, or delete an Azure resource — whether that request comes from the portal, the Azure CLI/Cloud Shell, PowerShell, an SDK, or a template.
Why it exists
Without a single control plane, each tool would talk to each resource type in a different, inconsistent way. ARM gives Azure a consistent, centralized API for management and enforces authentication + authorization (RBAC) on every request, plus declarative deployment so you can describe the end-state instead of the step-by-step commands.
Key ideas
- Control plane vs data plane — ARM is the management plane (
PUT/GETon resource details, RBAC, creation). Access to the data inside a resource (e.g., a blob’s contents, a VM’s OS) is the data plane, handled by the resource itself (often with its own keys/SAS). AZ-104 distinguishes these. - AuthN + AuthZ on every call — every ARM request is authenticated via Entra ID and authorized via RBAC before the operation runs.
- Resource providers — ARM routes requests to the correct resource provider (e.g.,
Microsoft.Compute,Microsoft.Network,Microsoft.Storage), each of which registers resource types. - Declarative templates — ARM templates and Bicep are submitted to ARM as one idempotent
PUTdescribing the goal; ARM builds a dependency-ordered deployment plan. - Front-ends are equivalent — portal, CLI, PowerShell, SDKs all funnel into ARM’s REST API.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: azure-resource-manager/management/overview
Exam notes
- ARM = control plane; the resource = data plane. Know which operations hit which.
- RBAC is enforced by ARM at request time — an allowed caller still needs data-plane permissions for the data inside the resource.
- Templates let ARM deploy declaratively, idempotently, and in dependency order.
- Resource providers must be registered for the subscription before some resource types can be created.
Related
Path MOC · arm-template · bicep · resource-group · scope · rbac · azure-cli
📘 Source: Microsoft Learn — Arm
ARM templates
What it is
An ARM template is a JSON file that declaratively describes the resources you want to deploy to Azure and their relationships, in a logical object model. Azure Resource Manager reads it and provisions the resources idempotently — it diffs against the current state and applies only the changes needed to reach the declared goal.
Why it exists
Clicking through the Portal or imperative CLI is fine for one resource but not reproducible or auditable for a fleet. Templates make infrastructure code: versioned in git, reviewed, reused with parameters, and safely re-run (no surprise re-provisions).
Key ideas
- Idempotent / declarative: re-deploying the same template brings resources to the declared state — unchanged ones are left alone.
- Structure (top-level elements):
$schema,contentVersion,parameters,variables,functions,resources, andoutputs. - Scope: resource-group, subscription, management group, or tenant deployment.
- You can deploy incrementally (default) or complete; type parameters make templates reusable.
- Bicep is a modern DSL that compiles down to these JSON templates (same engine). Could use
ConvertTo-Json/portal “Export template” to get a starting point. - Deploy via Portal, Azure CLI (
az deployment), PowerShell, or Azure DevOps/GitHub Actions.
How it fits (diagram)
Exam notes
- ARM template vs MPI (managed identity): not related — templates are IaC.
- Incremental vs complete deployment modes: incremental only adds/changes listed resources; complete deletes resources in the RG not in the template (dangerous — default is incremental).
- Linked/nested templates with
deploymentsresource for modularity. - Exam: recognize template JSON anatomy and that it’s declarative + idempotent.
Related
Path MOC · bicep · azure-cli · azure-vm
📘 Source: Microsoft Learn — Arm Template
Azure region
What it is
An Azure region is a set of data centers deployed within a latency-defined perimeter, connected by a dedicated low-latency network. Each region is the unit of geography where resources live (e.g. eastus, westeurope, uksouth).
Why it exists
You deploy resources to a particular region to control latency (near your users) and compliance/residency (data stays where the law allows). A resource is always created in one region; a single subscription can hold resources in many regions.
Key ideas
- Region pair — most regions are paired with another region for disaster recovery (e.g. EastUS ↔ WestUS); paired regions are updated/serviced one at a time and provide cross-region replication.
- Latency domain — resources in the same region communicate over Azure’s backbone, not the public internet.
- Sovereign clouds — separate deployments like Azure Government or Azure China are physically isolated from the public regions.
- Geographies — a grouping of regions (e.g. Americas, Europe) that satisfies data-residency boundaries.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: reliability/availability-zones-overview
Exam notes
- A resource is created in exactly one region; you pick it at deploy time and it’s immutable afterwards.
- Region pairs are the AZ-104 DR concept: most regions have a designated pair.
- Not all services are in all regions — some are regional, some global, some multi-region.
Related
availability-zones · subscription · resource-group
📘 Source: Microsoft Learn — Azure Region
Availability zones
What it is
Availability zones are physically separate datacenters within an Azure region — each zone has independent power, cooling, and networking. By placing VMs (or a scale set) in multiple zones, you survive a whole-zone failure. Zonal isolation is the strongest availability option within a region.
Why it exists
Fault/update domains protect against rack-level loss; a zone failure (entire datacenter in a region) is a bigger blast radius. Zones give you 99.99% availability and true regional-disaster tolerance inside one region for the workloads that can afford the cost.
Key ideas
- Usually a region has 3 zones. Resources are tagged zone 1/2/3 or use zone-redundant placement.
- Zone-redundant services (LB, storage, App Service plans) replicate automatically across zones.
- For VMs: distribute replicas across the zones via zonal deployment or a zone-redundant scale set.
- Zone-redundant storage (ZRS) and zone-redundant managed disks keep data available when a zone fails.
- Zones are available in select regions only — not every Azure region exposes zones (exam checks this).
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: availability-zones/az-overview
Exam notes
- Zones ⊄ availability sets: you choose either the wider failover (zones) or the rack-level spread (set), per VM/scale set — not both for the same deployment.
- Zone-redundant options exist for Azure Load Balancer (Standard), App Service plans, and storage — AZ-104 asks which services are zone-redundant.
- Only launch into zones if the region supports them; check
Get-AzLocation/ docs. - Zonal vs regional: AZ-104 wants you to pick zones when you need datacenter-level redundancy.
Related
Path MOC · azure-vm · availability-set · virtual-machine-scale-set · managed-disks
📘 Source: Microsoft Learn — Availability Zones
Azure portal
What it is
The Azure portal is the web-based GUI (portal.azure.com) for managing Azure. It’s one of several front doors to the management plane, alongside the CLI, PowerShell, and REST/ARM.
Why it exists
Not everyone works in a terminal. The portal gives a visual, point-and-click way to create, browse, and manage resources — ideal for learning, inspection, and one-off tasks. Behind the scenes it makes the same ARM REST calls the CLI does.
Key ideas
- Home/dashboard — customizable landing page with tiles, pinned resources, and observability widgets.
- Cloud Shell — an in-browser shell (cloud-shell) available from the portal toolbar.
- Search bar — global search across all subscriptions and resources.
- Activity log access and quick navigation to monitors/alerts.
- Trusts the same RBAC authorizations as every other tool.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: azure/portal/azure-portal-overview
Exam notes
- The portal is a client, not a service: it’s a convenience over ARM.
- Dashboards and pinned tiles are commonly tested portal features.
- You can audit who did what via the Activity log regardless of which tool made the change.
Related
azure-cli · cloud-shell · arm · subscription
📘 Source: Microsoft Learn — Azure Portal
Azure Cloud Shell
What it is
Azure Cloud Shell is an interactive, authenticated shell you run in the browser (from the Azure portal). It offers both Bash and PowerShell and is powered by a temporary container on Azure infrastructure.
Why it exists
It gives you a zero-setup, always-authenticated CLI experience — no local install, it persists your profile (dotfiles) and storage, and it’s already logged in to your subscription with your current RBAC rights.
Key ideas
- Authenticated by default — no
az loginneeded; it inherits your portal session. - Persistent storage — a small file share (5 GB default) backed by storage you attach; your
$HOMEsurvives sessions. - Two interpreters — choose Bash (uses
az) or PowerShell (usesAz). - Browser-based — runs on Azure, safe to use from locked-down workstations.
How it fits (diagram)
Exam notes
- Great for demos/exams: it’s pre-configured, authenticated, and has
azpre-installed. - It uses an Azure file share, which links it conceptually to the Storage path.
Related
azure-cli · azure-portal · arm
📘 Source: Microsoft Learn — Cloud Shell
Scope
What it is
Scope is the level/hierarchy at which a control or assignment applies. In Azure governance there is a single hierarchy:
Management group → Subscription → Resource group → Resource
Why it exists
Scoping lets you delegate permissions and apply policies once, high in the hierarchy, and have them inherit down. It avoids repeating the same rule/allowance for every resource and gives administrators flexible, least-privilege control.
Key ideas
- RBAC scope — a role assignment made at a higher scope (e.g. subscription) applies to everything below it, unless overridden closer to the resource.
- Policy scope — an Azure Policy initiative applied to a management group affects all child subscriptions/resources.
- More-specific wins — an assignment/deny closer to the resource generally takes precedence over a broader one.
- Inheritance is the crucial mental model for both RBAC and Policy.
How it fits (diagram)
Exam notes
- Always consider scope when evaluating an RBAC or Policy scenario — the exam loves “which assignment applies here?”-type questions.
- Assign privileges at the highest scope that still grants least privilege, usually a resource group or subscription.
Related
management-groups · subscription · resource-group · role-assignment · azure-policy
📘 Source: Microsoft Learn — Scope