Azure Resource Groups: What They Are and How to Use Them

A resource group is a logical container that holds the related resources for an Azure solution — virtual machines, storage accounts, virtual networks, and anything else you deploy — so they can be managed, secured, and deleted as a single unit. Every Azure resource must live in exactly one resource group, and deleting that group permanently deletes everything inside it. It’s the organizational layer that sits directly beneath your subscription and directly above your individual resources.

The building block underneath: what counts as a “resource”

Before resource groups make sense, it helps to pin down what they’re grouping. In Azure terminology, a resource is any manageable item you create and use on the platform — a virtual machine, a storage account, a virtual network, a database, and so on. Resources are the actual deployed things; everything above them in the hierarchy (resource groups, subscriptions, management groups) exists purely to organize and govern those resources, not to be resources themselves.

The membership rules that define a resource group

Three rules govern how resource groups work, and all three show up repeatedly on the exam:

1. One resource, one resource group. A given resource can belong to exactly one resource group at any moment. It can be moved to a different resource group later, but it can never sit in two at once — not even temporarily, and not even within the same subscription.
2. No nesting. A resource group cannot contain another resource group. The resource-group layer of Azure’s hierarchy is deliberately flat; if you want a deeper organizational structure, that’s what management groups (one level up, above subscriptions) are for instead.
3. The group’s region is just metadata. When you create a resource group, you pick a region for it — but that only determines where the resource group’s own metadata is stored. The resources inside it are free to live in completely different regions. A resource group created in West Europe can happily contain a VM in Southeast Asia and a storage account in East US, as long as everything stays within the same subscription.

What happens when you delete a resource group

Deletion is cascading and total: every resource inside the group is deleted along with it, regardless of what region those resources are physically running in. Azure doesn’t quietly relocate anything to a “default” resource group first, and it doesn’t check whether a resource still holds data you meant to keep — if it’s in the group, it goes. This is precisely why resource groups double as a cleanup mechanism: spinning up a temporary environment in its own resource group means tearing the whole thing down later is a single delete operation, not a manual hunt through dozens of individual resources.

That same cascading behavior is also the biggest way people accidentally lose data — always confirm a resource group’s contents before removing it, or apply a resource lock directly to the group to block deletion outright.

Moving resources without rebuilding them

Reorganizing your environment doesn’t mean starting over. Azure Resource Manager (ARM) supports moving most resource types from one resource group to another — even across subscriptions in many cases — without deleting and recreating them. The resource keeps running, and only its resource ID updates to reflect the new group’s path; its region, configuration, and Availability Zone placement don’t change just because its organizational container did. A handful of resource types carry move restrictions, so it’s worth checking a specific resource type’s move support before planning a large reorganization, but for the vast majority of everyday resources, moving is routine.

Resource groups vs. tags for organizing and reporting

Resource groups and tags both help you organize an Azure environment, but they solve different problems, and mixing them up is a common source of exam trap answers.

	Resource groups	Tags
What it is	A container a resource must belong to	A metadata label attached to a resource
Membership	Exactly one group per resource	A resource can carry many tags at once
Best for	Lifecycle management — deploy, secure, and delete a solution as a unit	Cross-cutting reporting — cost by department, environment, or owner, that cuts across group boundaries
Propagation	N/A	Tags on a resource group do not automatically apply to the resources inside it
Deletion impact	Deletes everything in the group	Has no effect on deletion

A useful mental shortcut: reach for separate resource groups when you need independent lifecycle control (dev, test, and production environments that must be securable and deletable on their own), and reach for tags when you need to slice cost or ownership reporting in a way that doesn’t map cleanly onto your resource group boundaries — like splitting one subscription’s spend between Marketing and Engineering without creating separate groups or subscriptions for each. For a deeper look at how tagging strategy feeds cost reports and billing views, see Azure cost management, billing, and tags.

How the AZ-900 exam tests this

• The “will deleting this hurt something I wanted to keep” trap. A scenario deletes a resource group that contains several resource types and asks what happens to a specific one the team meant to preserve. The correct answer is always that it’s deleted along with everything else — there’s no automatic rescue mechanism.
• The cross-region resource group question. A stem sets a resource group’s region as one place and a contained resource’s region as somewhere else, then asks if that’s valid. It is — the group’s region is only metadata, and this trips up anyone who assumes a resource group is a physical, not logical, boundary.
• The nesting and multi-membership traps. Questions test whether you know resource groups can’t contain other resource groups, and whether a single resource can belong to more than one group at a time (it can’t, ever).
• Environment-isolation scenarios. A company wants dev, test, and production to be independently securable and independently deletable. The answer is separate resource groups per environment — not tags, not Availability Zones, not a single group with naming conventions.
• Cost-splitting without new subscriptions. A scenario wants department-level cost visibility inside one subscription without creating new subscriptions or resource groups. That points to tags, since tags — not resource group membership — are the tool built for cutting reports across existing boundaries.

Quick reference

• A resource group is a logical container for related resources, managed and billed together as a unit.
• Every resource belongs to exactly one resource group at a time — never zero, never more than one.
• Resource groups cannot be nested inside other resource groups.
• A resource group’s own region is metadata only; the resources inside it can span multiple regions.
• Deleting a resource group permanently deletes every resource it contains, regardless of region.
• Most resource types can move between resource groups (and often subscriptions) without being recreated.
• Tags, not resource group structure, are the right tool for cross-cutting cost or ownership reporting.

Resource groups sit right next to subscriptions in Azure’s governance hierarchy — see Azure subscriptions vs. management groups for how the layer above resource groups works, and try AZ-900 practice questions to drill the deletion and membership rules until they’re automatic.