What Is Azure? Accounts, Subscriptions, Regions & Resource Groups

If you have never touched a cloud platform before, Azure can feel like an ocean of unfamiliar words — tenant, subscription, resource group, region, ARM. This lesson is the map. By the end you will understand what “the cloud” and Microsoft Azure actually are, how Azure organises everything you create into a clean nested hierarchy, where your resources physically live, who is responsible for what, and how the bill is calculated — and you will have run real commands and created (then deleted) your first piece of Azure infrastructure.

This is the first lesson in the Azure Zero-to-Hero course, so we assume zero prior cloud experience and define every term the first time it appears — but we go deeper than a typical intro. Where most introductions narrate, this one enumerates: every service model, every layer of the hierarchy, every region concept, every billing lever, every beginner failure mode is laid out as a scannable table you can return to. Everything here maps directly to the AZ-900: Azure Fundamentals certification, and lays groundwork for AZ-104 (Administrator).

A note on how to read this lesson: read the prose once to build the mental model, then keep the tables open as your reference. The single most valuable habit you can form on day one is knowing which layer a problem lives in — a billing surprise lives at the subscription, a “can’t reach the database” lives in the network (not the resource group), a “deploy was denied” lives in RBAC or Policy. The tables below are organised so you can find the right layer in seconds.

What problem this solves

Before the cloud, standing up a new application meant a procurement cycle: size the hardware, raise a purchase order, wait weeks for servers to arrive, rack them, cable them, install an operating system, and hope you sized it right — because if you under-provisioned you were stuck, and if you over-provisioned you had paid for idle metal. Scaling for a sale meant buying for the peak and wasting it the other 360 days. A failed disk at 3 a.m. was your problem. Disaster recovery meant a second data centre you also paid for and rarely tested.

Azure removes that entire category of pain. You rent computing on demand: ask for a server, a database, or storage; it appears in minutes; you pay only while you use it; you give it back when you are done. But trading hardware ownership for a rented global platform introduces a new set of things a beginner must understand or get burned by — where does a resource live and bill, who is allowed to create it, what keeps it running when a data centre fails, and whose job is security now. Get the mental model wrong and the classic beginner incidents follow: charges landing in the wrong place, a forgotten VM quietly running up a bill, a deploy denied with a cryptic AuthorizationFailed, or a storage account left open to the internet.

Who hits this: literally everyone starting on Azure. The hierarchy, regions, ARM and the shared-responsibility split are not optional trivia — they are the load-bearing concepts every later lesson assumes. This article exists so that when you create your first real resource, you know exactly which subscription it bills to, which region it sits in, why deleting a resource group is the cleanest way to stop charges, and which security duties just became yours.

To frame the whole field before the deep dive, here is every concept this article covers, the beginner question it answers, and where it sits:

Learning objectives

By the end of this lesson you can:

• Explain in plain English what cloud computing is, and tell the difference between IaaS, PaaS, and SaaS — and pick the right one for a given workload.
• Describe Azure’s organisational hierarchy: Microsoft Entra tenant → management groups → subscriptions → resource groups → resources — and say what each layer is for, what it bounds, and what it does not bound.
• Choose a region sensibly and explain how region pairs and availability zones protect your workloads against different kinds of failure.
• Explain what the Azure Resource Manager (ARM) control plane does on every deployment, and distinguish the control plane from the data plane.
• Read an Azure bill at a high level, name the levers that drive and reduce it, and state who is responsible for what under the shared responsibility model.
• Create, tag, query, and delete a resource group from Azure Cloud Shell using the az CLI — and diagnose the five most common beginner errors.

Prerequisites & where this fits

You need only basic IT literacy — you know what a file, a network, and a terminal are. No prior cloud experience is required. For the hands-on lab you need a free Azure account (the free tier or trial credit is more than enough; the lab itself costs nothing). This lesson is Lesson 1 of Module 1 — Foundations in the Azure Zero-to-Hero course. It builds the vocabulary and mental model that every later lesson assumes, so it is worth getting comfortable here before moving on.

Here is exactly what you should already know, what this lesson teaches, and where each thread continues — so you can see the shape of the journey:

What is “the cloud”, and what is Azure?

“The cloud” is a marketing word for a simple idea: instead of buying, racking, and maintaining your own computers, you rent computing on demand from a provider who runs enormous data centres for you. You ask for a server, a database, or storage; it appears in minutes over the internet; you pay only while you use it; and you give it back when you are done. No purchase orders, no waiting weeks for hardware, no replacing failed disks at 3 a.m.

Microsoft Azure is one of the three big public-cloud providers (alongside Amazon Web Services and Google Cloud): a global collection of data centres plus a catalogue of services — virtual machines, databases, storage, networking, AI, and hundreds more — that you provision and control through a web portal, a command line, or code.

The cloud is described by a handful of essential characteristics that distinguish it from a rented server in a colocation cage. These are worth pinning down because each maps to a concrete benefit you will use:

There are also three deployment models — where the cloud lives — which you should be able to name even though this course focuses on public cloud:

The classic way to describe how much of the stack the provider manages for you is the three service models — how much of the meal you cook yourself versus how much the restaurant handles:

The trade-off is control vs. effort: IaaS gives you the most of both, SaaS the least, and most real systems mix all three. To make the choice concrete rather than abstract, here is the same spectrum read as a decision aid — what each model gives and takes:

A useful instinct to build early: prefer the highest-level (most managed) option that still meets your requirements, because every layer you hand to Microsoft is a layer you no longer have to patch, scale, or page someone about. Concretely:

Core concepts

Five mental models make everything later in this lesson — and the whole course — fall into place. Read these once; the rest of the article is elaboration.

Azure is a hierarchy of nested scopes. Everything you create lives inside a clean ladder: tenant → management group → subscription → resource group → resource. Governance (policy, access) flows down this ladder by inheritance; billing rolls up it. Knowing which scope a thing belongs to tells you who can manage it, where it bills, and what rules apply.

A subscription is the billing-and-isolation boundary; a resource group is a lifecycle folder. These two are the most-used scopes and the most-confused. The subscription collects costs into one invoice and enforces quotas. The resource group is a logical folder for resources that share a lifecycle, so you deploy and delete them as a unit. Critically, a resource group is not a network or security boundary — a common beginner trap.

Every resource physically lives in a region, optionally spread across zones. A region is a geography with data centres; an availability zone is a physically separate building inside that region. Region choice drives latency, residency and cost; zones give you high availability; region pairs give you disaster recovery.

One control plane — ARM — fronts everything. Portal, CLI, PowerShell and code all call Azure Resource Manager. ARM authenticates you, authorises against your RBAC, enforces Azure Policy, routes to the right resource provider, and logs the action. Because they all funnel through ARM, the tools are interchangeable and deployments are declarative and idempotent.

Security is shared, and identity + data are always yours. Moving to the cloud does not make security entirely Microsoft’s problem. The split shifts with the service model, but your data, your identities and access, and your configuration are always on your side of the line — and that is where most cloud incidents actually happen.

The vocabulary in one table

Before the deep sections, pin down every moving part. The glossary at the end repeats these for lookup; this table is the mental model side by side:

How Azure organises everything: the hierarchy

The single most important mental model in this lesson is how Azure structures what you create. Everything you ever build sits inside a clean, nested hierarchy. From the top down:

• Microsoft Entra tenant — your organisation’s identity boundary. Microsoft Entra ID (formerly Azure Active Directory, or “Azure AD”) is Azure’s identity service: the directory of users, groups, and apps that can sign in. A tenant is one dedicated instance of that directory — effectively “your company’s account” in Azure. It is the trust anchor for everything below it, and one tenant can contain many subscriptions.
• Management groups — optional containers for organising subscriptions. If you have several (common in larger organisations), you arrange them in a tree so you can apply governance — policies (rules) and RBAC (access permissions) — to many subscriptions at once. Anything set on a management group is inherited beneath it. There is a single root management group at the top; you can nest up to 6 levels deep (excluding root and subscriptions). Small projects often skip this layer.
• Subscription — the billing boundary and the primary scope of management. A subscription holds resources, accumulates their costs into one invoice, and enforces quotas (limits, e.g. how many VMs of a family you may create). It is also a natural isolation boundary: many teams give each environment — production, development, test — its own subscription so billing, access, and quotas are cleanly separated. Every resource lives in exactly one subscription.
• Resource group — a logical folder for resources that share a lifecycle. You typically put everything for one application or environment into a single group — web app, database, storage — so you can deploy, manage, secure, and delete them as a unit. A resource group lives in exactly one subscription, every resource belongs to exactly one resource group, and resources can talk to each other across groups.
• Resource — the actual thing you use: a virtual machine, storage account, database, or virtual network. Each has a type (e.g. Microsoft.Storage/storageAccounts) provided by a resource provider (e.g. Microsoft.Storage).

Here is the full ladder as a reference — what each layer is for, who typically owns it, and what governance you attach there:

A crucial property of this ladder is inheritance: governance set high up flows down and is additive for access. The table below makes explicit what flows and what does not — this is where beginners build wrong intuitions:

The resource group deserves special emphasis because it is the scope you will touch most, and the one most misunderstood:

One nuance beginners often miss, restated because it matters: a resource group is a management and lifecycle boundary, not a security or network boundary. Sharing a resource group does not let two resources reach each other on the network, and separate groups do not isolate them. Network reachability is controlled by virtual networks and firewalls (covered in Azure Virtual Network Basics), and access by RBAC.

Where your resources live: regions, region pairs, and availability zones

When you create a resource, you choose a region — a geographic location where Azure has data centres, such as Central India, West Europe, or East US. Region choice matters for several reasons, each of which becomes a design constraint later:

Within most regions, Azure offers availability zones (AZs): physically separate locations inside the same region, each with independent power, cooling, and networking, connected by a fast low-latency link. Spreading a workload across Zone 1, Zone 2, and Zone 3 means that if one zone has an outage — a power failure or flood in one building — your application keeps running in the others. This is the standard way to achieve high availability within a region.

Azure also groups most regions into region pairs — two regions in the same geography (for example Central India paired with South India) used for disaster recovery. Some services replicate data to the paired region, and Microsoft rolls planned platform updates out to one region of a pair at a time to reduce risk. The pairing gives you a far-away copy to fail over to if an entire region is lost.

A quick way to remember the difference — the two concepts protect against different scales of failure:

It also helps to name the related grouping concepts you will meet later, so the vocabulary is not new when it arrives:

For your very first resources none of this costs extra to understand, but it shapes every serious design: zones for staying up, pairs for surviving a regional disaster. This is covered exhaustively in Azure Global Infrastructure: Regions, Zones, Fault & Update Domains.

The control plane: Azure Resource Manager (ARM)

Here is something that confuses many newcomers. When you click “Create” in the portal, run an az command, or apply infrastructure-as-code, all of those paths talk to the same service underneath: Azure Resource Manager (ARM). ARM is Azure’s control plane — the single front door for creating, reading, updating, and deleting resources.

Every request becomes a call to the ARM REST API. ARM then performs a fixed sequence of steps. Knowing this sequence tells you exactly where a failed deploy went wrong:

Two consequences matter from day one. First, because portal, CLI, PowerShell, and code all funnel through ARM, they are interchangeable — create something in the portal, then manage it from the CLI without issue. The table below shows the four ways to drive ARM and when each shines:

Second, with templates ARM is declarative and idempotent: you describe the desired end state, ARM converges to it, and re-running the same deployment is safe. That is the foundation of infrastructure as code, which the course returns to later.

It is also worth distinguishing the control plane (managing a resource — create/delete the database, via ARM) from the data plane (using it — run a query against the database, handled by the service directly). This distinction governs which permissions matter where:

That last row trips up almost everyone once: being Owner of a storage account lets you delete it, but does not by itself let you read its blobs — you need a data-plane role like Storage Blob Data Reader. Control plane and data plane are governed separately by design.

How billing works

Azure billing follows the rented-computing idea: you mostly pay consumption-based (pay-as-you-go) prices — per second, per hour, per gigabyte stored, per million requests, or per transaction, depending on the service. There is no upfront hardware cost; you pay for what you use and stop paying when you delete the resource.

Different services meter on different units. Knowing the unit tells you how to control the cost:

The hierarchy maps neatly onto billing, and a small set of tools and constructs do the cost management:

Beyond pay-as-you-go, the commitment and licensing levers below cut steady-state cost substantially — they are optimisation topics for later (see Azure Cost: Reservations, Savings Plans & Hybrid Benefit), but worth knowing they exist:

The key beginner habit is simpler than any of these: anything you create costs money until you delete it — which is exactly why every lab in this course ends with a cleanup step. Cost is explored in depth in Azure Cloud Economics: Pricing, TCO, SLA & Support and the FinOps cost-engineering guide.

The shared responsibility model

Moving to the cloud does not make security entirely Microsoft’s problem. Responsibility is shared, and the split depends on the service model:

• Microsoft is always responsible for the physical security of data centres, the host infrastructure, and the network backbone.
• You are always responsible for your data, your identities and access (who can sign in and what they can do), and how you configure what you deploy.
• The middle layers — operating system, patching, network controls, application code — shift between you and Microsoft depending on whether you chose IaaS, PaaS, or SaaS.

The single biggest takeaway for beginners: identity and data are always yours to protect. The most common cloud incidents are not Microsoft’s data centre failing — they are configuration and identity mistakes that sit squarely on your side of the line. Here are the classic ones and where they live:

Identity (Lesson 3, Microsoft Entra ID Fundamentals) gets heavy treatment in this course precisely because so much of the responsibility — and so many of the incidents — live there.

Architecture at a glance

Now put it together. The diagram below traces the life of a single deployment left to right, across the five layers this lesson has built up — and that is the most useful way to hold Azure in your head: not as a list of services, but as a path every az group create or portal click travels. Start at IDENTITY: you sign in (portal, CLI, or IaC) and Azure authenticates you against your Entra tenant, the one directory that says who you are. That identity then carries into GOVERNANCE, where your request is scoped by the management group → subscription hierarchy that decides where it bills, what quota it draws on, and which policies apply by inheritance.

The request lands at the CONTROL PLANE — Azure Resource Manager — which is the single front door for everything: it authorises you against RBAC, runs your request past Azure Policy (for example an “allowed regions” guardrail), records the action in the Activity Log, and only then routes the work to the right resource provider. ARM provisions into the WORKLOAD zone: your resource group (the lifecycle folder, e.g. rg-shop-prod) and the resources inside it. Finally those resources are placed into the PHYSICAL zone — a region like Central India, ideally spread across availability zones 1/2/3 for high availability, with a region pair standing by for disaster recovery. The five numbered badges mark exactly where a beginner’s first deployment tends to break — wrong tenant, charges in the wrong subscription, a policy/authorisation denial, the resource-group-is-not-a-network trap, and a single-zone deploy with no redundancy — each of which reappears in the troubleshooting section with the exact command to confirm and fix it.

The whole method of operating Azure follows this picture: when something goes wrong, locate which zone it lives in. A billing surprise is a GOVERNANCE/subscription question; a denied deploy is a CONTROL-PLANE authorisation/policy question; a “can’t reach the database” is a WORKLOAD/network question (never the resource group itself); an outage that should have been survivable is a PHYSICAL/zone question. Naming the zone first is what turns a vague problem into a one-command diagnosis.

Real-world scenario

Saffron Mart, a fictional but representative mid-sized Indian retailer, is moving from a single on-prem server to Azure. Their first month is a perfect catalogue of the mistakes this lesson prevents — and how the right mental model fixes each.

The team is three developers and one ops engineer, no prior cloud experience, with a target of running their checkout web app and its SQL database in Azure within a quarter, under a ₹40,000/month budget. They sign up for a free account, get trial credit, and start clicking.

Week 1 — the “where did it go?” problem. A developer creates a VM to test the app. It works. A second developer creates a database — but in a different subscription, because the portal happened to default there. Now the app VM and the database are in separate subscriptions, billed separately, and nobody can find the database in the cost view they were watching. The fix was conceptual, not technical: they learned that every resource lives in exactly one subscription, ran az account show to see which one was active, standardised on a single Saffron-Prod subscription, and recreated the database there. Lesson: pin your subscription context before you create anything.

Week 2 — the “they can’t talk to each other” trap. With everything now in one subscription, they put the web app and database in the same resource group, assuming that would let them communicate. The app still couldn’t reach the database. They spent half a day convinced Azure was broken. The truth: a resource group is a lifecycle folder, not a network boundary. Reachability is a virtual network concern. Once they put both into a VNet (and opened the right rule), it worked. Lesson: the RG groups for management and billing; the VNet connects.

Week 3 — the denied deploy. A junior developer tried to create a resource and hit AuthorizationFailed. The ops engineer had given them Reader on the subscription. They learned that ARM authorises every request against RBAC, that Reader can look but not create, and that Contributor (scoped to the dev resource group, not the whole subscription) was the least-privilege fix. Lesson: errors like this live at the control plane, and the fix is a scoped role.

Week 4 — the forgotten VM. The Week-1 test VM was never deleted. It quietly ran for three weeks and ate ₹6,000 of credit. The ops engineer set a budget with an alert at ₹30,000 in Cost Management, tagged everything with owner and env, and adopted the rule that every experiment goes in a disposable resource group you delete in one command. Lesson: anything you create costs money until you delete it; budgets and a cleanup discipline are not optional.

By the end of the month Saffron Mart was running the checkout app on App Service (PaaS) rather than a self-managed VM (no OS to patch), the database on Azure SQL, both in one resource group inside the Saffron-Prod subscription in Central India with zone redundancy, fronted by a budget alert, at about ₹22,000/month — comfortably under target. Every one of their four early incidents maps to exactly one concept in this lesson. The incident log, because the pattern is the lesson:

Advantages and disadvantages

The cloud model — and Azure’s particular shape of it — is overwhelmingly worth it for most workloads, but a beginner should weigh it honestly rather than treat it as magic:

When does each side matter? The advantages dominate for new applications, spiky or seasonal workloads, startups avoiding capital expense, and any team that would rather ship features than rack servers. The disadvantages bite hardest for teams that lift-and-shift without learning the model (they recreate on-prem habits and get surprised by the bill), for highly regulated data with strict residency, and for workloads needing absolute control of the OS/kernel. The honest summary: the downsides are all manageable with knowledge — which is precisely why this lesson exists.

Hands-on lab

You will open Azure Cloud Shell — a full command-line environment that runs in your browser, pre-authenticated, with the az CLI already installed (nothing to install locally) — and create, inspect, tag, and delete your first resource group. A resource group is the safest possible “hello world”: it is free, and deleting it cleanly removes everything inside it.

Prerequisite: a free Azure account. If you do not have one, go to https://azure.microsoft.com/free and sign up (you need a Microsoft account and a card for identity verification — the free tier and trial credit mean this lab costs nothing), then sign in at https://portal.azure.com.

Step 1 — Open Cloud Shell

In the portal, click the Cloud Shell icon (>_) in the top toolbar, or browse to https://shell.azure.com. When prompted, choose Bash. The first time, Azure offers to create a small storage account to persist your shell files — accept the default (a few pennies a month) or pick the ephemeral option for none. You will land at a prompt already signed in as you.

Step 2 — Confirm your context

Check which subscription you are working in. Everything you create lands here and is billed here. This single command prevents the Week-1 mistake from the scenario above.

az account show --output table

Expected output (your values will differ):

Name                  CloudName    SubscriptionId                        State    IsDefault
--------------------  -----------  ------------------------------------  -------  ----------
Azure subscription 1  AzureCloud   00000000-0000-0000-0000-000000000000  Enabled  True

If you have more than one subscription, list them and select the right one before continuing:

az account list --output table
az account set --subscription "<your-subscription-name-or-id>"

Step 3 — Pick a region (optional but instructive)

List the regions available to you and note one close to you (for example centralindia or westeurope):

az account list-locations --query "[].name" --output tsv | sort

Step 4 — Create a resource group

Create a resource group named rg-kloudvin-lab in your chosen region. This is the same operation the portal performs when you click Create a resource group — both go through ARM.

az group create --name rg-kloudvin-lab --location centralindia

The equivalent in Bicep (infrastructure as code) — note that a resource group is deployed at subscription scope:

targetScope = 'subscription'

param location string = 'centralindia'

resource rg 'Microsoft.Resources/resourceGroups@2024-03-01' = {
  name: 'rg-kloudvin-lab'
  location: location
  tags: {
    env: 'learning'
    owner: 'your-name'
  }
}

Expected output (trimmed JSON) from the az command:

{
  "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-kloudvin-lab",
  "location": "centralindia",
  "name": "rg-kloudvin-lab",
  "properties": {
    "provisioningState": "Succeeded"
  }
}

The id is the resource group’s resource ID — notice it literally encodes the hierarchy: subscriptions/<id>/resourceGroups/<name>. Every resource in Azure has an ID in this shape. Decoding that ID is a skill worth having on day one:

"provisioningState": "Succeeded" confirms ARM completed the request.

Step 5 — Tag it for cost attribution

Add tags so this group can be sliced in Cost Management later — building the habit early:

az group update --name rg-kloudvin-lab \
  --set tags.env=learning tags.owner="$(az account show --query user.name -o tsv)"

Step 6 — Validate

Confirm the resource group exists and inspect it:

az group list --output table
az group show --name rg-kloudvin-lab --output table

You should see rg-kloudvin-lab with Location centralindia and ProvisioningState Succeeded. That is your validation: the resource group is real, in the region you chose, in your subscription. (It is empty — a resource group can exist with nothing inside it, which is perfectly normal.)

Step 7 — Cleanup

Always clean up. Deleting the resource group deletes everything inside it in one action — the core reason resource groups are so useful.

az group delete --name rg-kloudvin-lab --yes --no-wait

--yes skips the confirmation prompt; --no-wait returns immediately while Azure deletes in the background. Verify it is gone (it will briefly show Deleting, then disappear):

az group list --output table

The lab steps mapped to the concept each one proves:

Cost note: An empty resource group is free — you are charged for resources, not for the folder that holds them. This entire lab costs nothing beyond, at most, a few pennies for the optional Cloud Shell storage account (which you can also delete from the portal afterwards if you used it).

Common mistakes & troubleshooting

This is the part you bookmark. Every beginner hits some of these in their first week; each maps to exactly one of the concepts above, and each has a precise way to confirm the cause and fix it. First the scannable playbook table, then the expanded reasoning for the ones that bite hardest.

The error-string reference — the exact codes you’ll see and what each means on Azure, since the message alone is often cryptic:

And the decision table for “I see X, it’s probably Y, do Z” — the fastest path from a symptom to the right layer:

Expanded reasoning for the three that cause the most lost hours:

2. Resources or charges show up in the “wrong place.” Root cause: a different subscription is the active default in your CLI/portal session, so everything you create lands and bills there. Confirm: az account show --query "{name:name, id:id}" -o table. Fix: set the intended subscription before creating anything — az account set --subscription "<name-or-id>" — and make az account show the first command in any script. This is the single most common beginner billing mistake.

7. Two resources in the same resource group still can’t talk to each other. Root cause: the belief that a resource group is a network boundary. It is a lifecycle and management boundary only. Confirm: check whether each resource is in a virtual network (az network vnet list, and the resource’s networking blade). Fix: reachability comes from a virtual network (and the right NSG/firewall rules), never from co-locating in a resource group. Conversely, resources in different RGs can absolutely communicate if they share a VNet.

4 & 9. AuthorizationFailed vs RequestDisallowedByPolicy. Both block a deploy at the control plane, but they are different layers and have different fixes. AuthorizationFailed means RBAC — you don’t have permission; the fix is a scoped role (prefer Contributor on the resource group, not Owner on the subscription). RequestDisallowedByPolicy means Azure Policy — a governance rule forbids what you asked (an unapproved region, an oversized SKU, an untagged resource); the fix is to comply with the rule (deploy in an allowed region, add the required tag) or request an exemption from whoever owns the policy. Confuse the two and you’ll grant a broad role that still doesn’t unblock the deploy.

Best practices

• Pin your subscription context first. Make az account show the first line of any session or script. Most beginner billing surprises start with creating in the wrong subscription.
• Use resource groups per application and environment. Group resources that share a lifecycle (e.g. rg-shop-prod, rg-shop-dev) so you can deploy and delete them as a unit and read per-app cost easily.
• Adopt a naming convention from day one. A predictable scheme like rg-<workload>-<env>-<region> makes resources self-documenting and scriptable. Inconsistent names are painful to fix later.
• Tag everything. At minimum tag owner, env, and costCenter. Tags are how you make sense of the bill and find who owns a resource months later. Enforce them with Azure Policy once you’re comfortable.
• Choose regions deliberately for latency, data residency, availability-zone support, and service availability — not just “whatever was default.”
• Design for availability explicitly. Use zones for high availability and the region pair for disaster recovery; the defaults are not always HA.
• Apply least privilege with scoped roles. Grant Contributor on a resource group, not Owner on a subscription, unless the job genuinely needs the wider scope.
• Set a budget and a cost alert early in Cost Management so a forgotten resource can never quietly run up a bill.
• Always include a cleanup path for anything experimental — ideally one resource group you can delete in a single command, exactly as in this lab.
• Prefer the highest-level managed service that fits — PaaS over IaaS where you can — to shed patching and scaling toil.
• Treat the subscription as a blast-radius boundary. Separate production into its own subscription to limit the damage of a mistake or compromise.
• Manage infrastructure as code (Bicep/Terraform) as you grow so deployments are repeatable, reviewed, and idempotent.

Security notes

• Identity is the perimeter. Your Microsoft Entra sign-ins and the RBAC roles you grant are your most important controls. Enable multi-factor authentication (MFA) on your account before anything else.
• Apply least privilege. Grant the narrowest role at the narrowest scope that gets the job done (a resource group, not the whole subscription). Covered in depth in Microsoft Entra ID Fundamentals.
• Treat the subscription as a blast-radius boundary. Separating production into its own subscription limits the damage a mistake or compromise can do.
• Remember the shared responsibility line. Misconfiguration — an open storage account, an over-broad role — is the most common cause of cloud incidents, and it sits on your side. Configure deliberately.
• Never put secrets in scripts, tags, or source control. Tags and command history are not secret stores; use Azure Key Vault with a managed identity (Key Vault: Secret Rotation & Managed Identity).
• Use resource locks on critical groups. A CanNotDelete lock on a production resource group prevents an accidental one-command deletion of everything.
• Distinguish control-plane from data-plane access. Being able to manage a resource (RBAC) is not the same as being able to read its data — grant data-plane roles explicitly and sparingly.

The security-control quick reference — what protects against what at this beginner stage:

Cost & sizing

What drives the bill, and how a beginner keeps it under control:

• You pay for resources, not for the folders. Subscriptions, management groups, resource groups and tags are all free organising constructs. The charges come from the resources — compute, storage, networking, data transfer.
• Compute and egress dominate most early bills. A running VM bills per hour whether or not it’s doing work (stop/deallocate it when idle); outbound data transfer (egress out of Azure) is metered per GB while inbound is free.
• “Stopped” is not always “free.” A deallocated VM stops compute charges but you still pay for its disks and any reserved public IP. Deleting the resource group is the only way to stop all charges.
• Free tier and trial credit cover this course. New accounts get trial credit plus a set of always-free services; the labs here are designed to cost nothing.

The free-account essentials — what you get and the limits to watch:

Rough monthly figures for a first real workload (INR/USD, illustrative — prices vary by region and change over time):

The right-sizing rules of thumb for a beginner — and the deeper treatment in Azure Cloud Economics:

Interview & exam questions

1. Explain the Azure resource hierarchy from top to bottom. An Entra tenant is the identity boundary (who can sign in); management groups organise subscriptions for governance at scale; a subscription is the billing/quota boundary and primary management scope; a resource group is a lifecycle container; resources are the individual services. Governance and access flow down via inheritance; cost rolls up.

2. Is a resource group a security or network boundary? No. It is a logical lifecycle container and an RBAC-assignment scope that lets you deploy, manage, delete, and cost-roll-up related resources as a unit — but not a network or implicit security boundary. Reachability is a virtual-network concern; access is configured explicitly via RBAC.

3. What is Azure Resource Manager and why does it matter? The control plane and single API front door. Portal, CLI, PowerShell, and IaC all call ARM, which authenticates, authorises via RBAC, validates, enforces Azure Policy, routes to resource providers, and logs to the Activity Log — enabling idempotent, declarative deployments and making the tools interchangeable.

4. Availability zones vs region pairs — which protects against what? Use availability zones to survive a single data-centre/building failure within a region (high availability). Use the region pair for disaster recovery — a distant copy in the same geography to fail over to if the whole region is lost.

5. How does shared responsibility change across IaaS, PaaS and SaaS? Moving IaaS → PaaS → SaaS, Microsoft takes on more (OS, patching, runtime, then the whole app) and you take on less — but data, identity/access, and configuration remain yours at every level, which is where most incidents occur.

6. Distinguish the control plane from the data plane with an example. The control plane (ARM, governed by RBAC) manages resources — create/delete a storage account. The data plane (the service endpoint, governed by keys/SAS/data-plane roles) uses them — read a blob. Being Owner (control plane) does not by itself grant data access; you need a data-plane role like Storage Blob Data Reader.

7. Name three things that are always your responsibility regardless of service model. Your data, your identities and access, and your configuration/endpoints. (Application code is also yours in IaaS and PaaS.)

8. How would a beginner keep cloud costs under control? Delete what you’re not using (charges accrue until deletion), tag resources for attribution, group them so per-app cost is visible, and set budgets and alerts in Cost Management. For steady workloads later, use Reservations or Savings Plans; prefer PaaS/serverless for spiky load.

9. What are IaaS, PaaS and SaaS, with an Azure example of each? IaaS = rent infrastructure, you manage the OS up (Azure Virtual Machines). PaaS = rent a managed platform, you bring just app + data (Azure App Service). SaaS = rent a finished application (Microsoft 365). The trade-off is control vs. operational effort; prefer the most-managed option that meets your needs.

10. A junior gets AuthorizationFailed deploying a VM. What’s wrong and how do you fix it least-privilege? ARM authorised the request against RBAC and they lacked rights at that scope. Grant the narrowest role that works — typically Contributor on the target resource group, not Owner on the subscription. Confirm with az role assignment list.

11. Why might a resource fail to deploy with RequestDisallowedByPolicy, and how is that different from an RBAC failure? An Azure Policy guardrail forbade the request (e.g. a disallowed region or SKU, or a missing required tag) — distinct from RBAC, which is about permission. The fix is to comply with the policy (allowed region/SKU/tag) or get an exemption, not to grant a broader role.

12. What is a region pair, and name one operational benefit beyond DR. Two regions in the same geography linked for disaster recovery. Beyond a replication target, Microsoft applies planned platform updates sequentially — one region of the pair at a time — reducing the risk that an update affects both halves of your DR posture at once.

These map primarily to AZ-900 (Azure Fundamentals) — cloud concepts, service models, regions/zones/pairs, the management hierarchy, ARM, and cost management — and lay groundwork for AZ-104 (Administrator). The compact cert mapping:

Quick check

1. Put these in order from broadest to narrowest, and say what each is for: resource group, resource, subscription, management group, Entra tenant.
2. What is the difference between an availability zone and a region pair, and which protects against which kind of failure?
3. When you run az group create, what service actually receives and processes that request, and name two checks it performs before the resource group is created.
4. Under the shared responsibility model, name two things that are always your responsibility regardless of the service model.
5. True or false: deleting a resource group also deletes the resources inside it. Why does this matter for cost — and why is a resource group not a network boundary?

Answers

1. Entra tenant (your identity/organisation boundary — who can sign in) → management group (groups subscriptions to apply governance at scale) → subscription (billing boundary, quotas, primary management scope) → resource group (lifecycle folder for related resources) → resource (the actual VM, database, etc.). Governance flows down by inheritance; cost rolls up.
2. An availability zone is a physically separate location within one region; spreading across zones protects against a single data-centre/building failure (high availability). A region pair is two regions in the same geography; it protects against an entire region failing (disaster recovery).
3. Azure Resource Manager (ARM), the control plane. Before creating the group it (any two of): authenticates you, authorises via RBAC at that scope, validates the request, enforces Azure Policy, checks quota, routes to the resource provider, and logs to the Activity Log.
4. Any two of: your data, your identities and access, and your configuration/endpoints. (Application code is also yours in IaaS/PaaS.)
5. True. It matters for cost because resources bill for as long as they exist, so deleting the resource group is the cleanest one-step way to stop all charges. It is not a network boundary because reachability is controlled by virtual networks and firewalls — co-locating in an RG does not connect two resources, and separate RGs do not isolate them.

Exercise

In Cloud Shell, create a resource group named rg-kloudvin-exercise in a region different from the one you used in the lab. Then:

1. Attach two tags to it at creation time using --tags, for example --tags env=learning owner=<your-name>.
2. Run az group show --name rg-kloudvin-exercise --output json and find your tags in the output.
3. Run az group list --query "[?tags.env=='learning'].name" --output tsv and confirm your group is returned — this is a first taste of filtering Azure output with JMESPath queries (covered fully in Lesson 2).
4. Delete the resource group when you are done.

If all four steps work, you have created, tagged, queried, and cleaned up Azure infrastructure entirely from the command line — a real, repeatable workflow.

Glossary

• Cloud computing — renting computing resources on demand over the internet and paying only for what you use.
• IaaS / PaaS / SaaS — service models from most to least self-managed: rent infrastructure / rent a managed platform / rent a finished application.
• Public / private / hybrid cloud — deployment models: shared Microsoft data centres / your own infrastructure / a connected mix.
• Microsoft Entra ID — Azure’s cloud identity service (formerly Azure AD); the directory of users, groups, and apps that can sign in.
• Tenant — one dedicated instance of Microsoft Entra ID; effectively your organisation’s identity boundary in Azure.
• Management group — a container for organising multiple subscriptions so governance (policy, RBAC) can be applied and inherited at scale.
• Subscription — the billing boundary and primary management scope; a container that holds resources and accrues their cost and quotas.
• Resource group — a logical container for resources that share a lifecycle, so they can be managed and deleted as a unit (not a network/security boundary).
• Resource — an individual manageable Azure service instance (a VM, storage account, database, etc.).
• Resource ID — the path-shaped unique identifier encoding subscriptions/<id>/resourceGroups/<name>/providers/<type>/<name>.
• Region / availability zone / region pair — a geographic location with data centres / physically separate locations within a region (HA) / two paired regions used for disaster recovery.
• Geography — a discrete market/area (e.g. India, Europe) containing one or more regions; a data-residency boundary.
• Azure Resource Manager (ARM) — Azure’s control plane: the single API that authenticates, authorises, validates, enforces policy, and deploys every resource.
• Control plane vs data plane — managing a resource (via ARM, governed by RBAC) versus using it (via the service endpoint, governed by keys/SAS/data-plane roles).
• RBAC (role-based access control) — granting scoped roles (e.g. Contributor on a resource group) that ARM checks on every request.
• Azure Policy — governance rules enforced at deploy time (e.g. allowed regions/SKUs, required tags); denials show as RequestDisallowedByPolicy.
• Tag — a key–value label on a resource used to attribute cost and ownership (not a security control).
• Shared responsibility model — the division of security duties between Microsoft and you, which shifts with the service model; data, identity and configuration are always yours.
• Cost Management / budget — Azure’s built-in cost-analysis tool and the spending-threshold alerts you set within it.
• Reservation / Savings Plan / Hybrid Benefit — commitment- and licence-based discounts for steady workloads.

Next steps

You now have the vocabulary and the mental model for everything that follows. Next, learn the four ways to actually drive Azure — and when to use each:

• Next lesson: Working with Azure: Portal, CLI, PowerShell & Cloud Shell

Related reading to deepen what you have learned here:

• Microsoft Entra ID Fundamentals: Tenants, Users, Groups & RBAC — the identity layer at the top of the hierarchy, and the RBAC that ARM checks on every deploy.
• Azure Global Infrastructure: Regions, Zones, Fault & Update Domains — how regions, zones and pairs really work under the hood.
• Azure Virtual Network Basics: Subnets, NSGs & Peering — how resources reach each other on the network (the boundary a resource group is not).
• Azure Cloud Economics: Pricing, TCO, SLA & Support — read a bill, model TCO, and choose the right commitment.
• Your First Deploy: A Simple Serverless API on Azure — put a real workload into a resource group and watch ARM provision it.