Azure resource groups are containers that hold all your cloud resources in one logical unit. If Azure is your filing cabinet, a resource group is a drawer inside it. Everything you create in Azure (virtual machines, databases, storage accounts, networks) must belong to a resource group, and getting this right early saves you from chaos later.
This guide walks you through what resource groups actually are, why they matter for your career, and how to use them properly from day one.
A resource group is a logical container that bundles related Azure resources together. Think of it like a project folder on your computer: you wouldn't throw every file you'll ever create into one folder, you'd organise by project, client, or environment.
In Azure, a resource group serves several practical purposes:
The key constraint: a resource can only belong to one resource group at a time. Once you move a resource to a different group, it breaks its tie with the old one. This clarity is exactly why resource groups work.
If you're training for Azure Administrator or moving from healthcare IT into cloud engineering, understanding resource groups is non-negotiable. Here is why:
Azure Administrator roles almost always manage resource groups first. In job interviews, hiring managers expect you to explain how you would organise resources for a multi-team environment. If you fumble this answer, they wonder if you understand Azure at a foundational level.
Cost management is a real business problem. Healthcare organisations moving to Azure (which many NHS trusts are doing) need to track spending by department or project. Mismanaging resource groups means finance teams can't see costs properly, and that reflects badly on you. Organisations today spend an average of £18,000 to £45,000 annually on Azure infrastructure alone, depending on size. If you can't organise that spend properly, you're not solving their problem.
Multi-team projects require clean boundaries. When a dev team, security team, and operations team all touch the same infrastructure, unclear resource groups cause conflicts. You'll be expected to design a resource group strategy that prevents accidental deletions and keeps teams from stepping on each other's toes.
1. Log in to your Azure portal (portal.azure.com).
2. Search for "Resource groups" in the search bar.
3. Click "Create" and fill in the basic details:
- Subscription: Choose which Azure subscription owns this resource group (if you have more than one).
- Resource group name: Use a clear, descriptive name like "rg-healthcare-app-dev" or "rg-finance-prod". Most teams prefix "rg-" to make resource groups easy to spot.
- Region: Select the Azure region closest to your users (for UK users, usually UK South or UK West). Note: the resource group itself is just a management container, but the region you choose affects billing slightly and is used as a default for any resources created inside it.
4. Click "Review and create" then "Create".
That is it. You now have a resource group.
Poor naming leads to confusion fast. Here are conventions used by real Azure teams in 2026:
For real projects, you will have multiple resource groups. Here is a pattern that works:
By environment:
This keeps development work isolated from production. If a developer accidentally deletes something in the dev group, it does not affect live services.
By team or department:
This works for larger organisations where different teams own different applications.
By project with sub-environments:
If you are managing a specific migration (like an NHS trust moving to cloud), grouping by project makes sense.
Putting everything in one resource group. It feels convenient at first, then you have 47 unrelated resources in one place and cannot tell what belongs to what. Start with at least two groups: one for testing and one for anything production-facing.
Not using consistent naming. If your resource groups are called "test", "my-app", "Production-2", and "azure-backup", nobody can tell what is what at a glance. Enforce a naming convention from day one.
Forgetting that deletion is permanent. When you delete a resource group, everything in it is gone forever (within the retention period for certain resources like databases, which may be 7 to 30 days depending on the service). Always double-check before deleting.
Not assigning owners. In a team environment, make it clear who is responsible for each resource group. Use Azure role-based access control (RBAC) to assign the "Owner" or "Contributor" role appropriately.
If you are training for the Azure Administrator certification or moving into that job title, resource groups are foundational. The AZ-104 exam (Azure Administrator) tests your understanding of resource group creation, permissions, and management. More importantly, it is what you will spend time on every single day in the role.
Most Azure Administrators spend roughly 20 to 30 percent of their time managing resource lifecycles, cost tracking, and RBAC across resource groups. If you understand this concept now, you are ahead of 70 percent of beginners entering the field.
Want hands-on practice before sitting the AZ-104 exam or applying for your first Azure role? Join SmoothOps 365's free two-hour live Azure session, where you will build and manage your first resource group in a real lab environment alongside an instructor who spent five years in healthcare IT before moving into cloud engineering.
Yes, you can move most Azure resources between resource groups, though some services (like certain database configurations) have limitations. Moving a resource does not cause downtime if done correctly, but you need to re-apply any RBAC permissions and tags to the new group. Always test this in a development environment first before moving production resources.
If you have not waited longer than the retention period (typically 7 to 30 days depending on the resource type), you can sometimes restore deleted resources using Azure's soft delete features. However, this is not guaranteed. The safest approach is to use resource locks (set via Azure policy) to prevent accidental deletion of critical resource groups, and to use clear naming so you are never unsure what you are deleting.
Resource groups themselves are free to create and maintain. However, the resources inside them (virtual machines, storage, bandwidth, etc.) are what incur charges. Organising resources into separate groups does not increase costs, but it does make it much easier to track and allocate costs by project or department, which is why finance teams care about this.
There is no strict limit, but most teams use between 5 and 20 resource groups depending on organisational size and complexity. Start with two (dev and prod) and expand as your projects grow. The goal is to balance easy management with enough structure that you can track costs, permissions, and lifecycles clearly.
Yes, you can rename a resource group in the Azure Portal or via PowerShell. Renaming does not affect the resources inside it or cause any downtime, but it may affect any scripts or automation that reference the old name, so plan carefully if you are using Infrastructure as Code (IaC).
SmoothOps 365 runs live instructor-led training every Saturday and Sunday. 3 months. 50 contact hours. Keep your job while you train.