What is an Azure Resource Group? AZ-900 Governance Guide
An Azure Resource Group is a logical container that holds related resources for an Azure solution. It enables efficient lifecycle management, allowing you to deploy, update, and delete a group of resources as a single unit, while providing a centralized point for applying governance, security policies, and Role-Based Access Control (RBAC).
What exactly is an Azure Resource Group?
Think of an Azure Resource Group (RG) as a logical folder for your cloud assets. In the world of Azure, every single resource—whether it's a Virtual Machine, a SQL Database, or a Virtual Network—must belong to exactly one resource group. It's important to understand that the RG itself doesn't 'do' anything technically; it doesn't provide computing power or storage. Instead, it's a management tool that helps you organize your environment so you aren't hunting through a massive list of a thousand disconnected resources.
One common point of confusion for AZ-900 students is the relationship between the RG and the region. While a resource group has a location (where its metadata is stored), the resources inside that group can actually reside in different regions. For example, you could have a Resource Group located in 'East US', but contain a VM in 'West Europe' and a Storage Account in 'Southeast Asia'. This flexibility is key to designing global architectures.
Why are Resource Groups critical for lifecycle management?
In a professional production environment, you rarely deploy a single resource in isolation. You usually deploy a 'stack'—perhaps a web app, a database, and a load balancer. By grouping these into one RG, you achieve streamlined lifecycle management. If you're spinning up a temporary environment for a 2-week sprint, you can simply delete the entire Resource Group when you're done. This ensures that every associated disk, network interface, and IP address is wiped clean, preventing 'zombie resources' from lingering and eating your budget.
From a governance perspective, this allows you to treat your infrastructure as a single unit of deployment. When we look at the AZ-900 objectives, Microsoft wants you to understand that RGs simplify the 'Create, Update, Delete' cycle. Instead of manually tracking 15 different resource IDs, you manage one container. This reduces human error and ensures that your environment remains lean and cost-effective.
How does RBAC work at the Resource Group level?
Role-Based Access Control (RBAC) is where Resource Groups truly shine. Instead of assigning permissions to every individual resource, you can apply a role—like 'Contributor' or 'Reader'—at the Resource Group level. Because of the principle of inheritance, any permission you grant at the RG level automatically trickles down to every resource inside that group. If you make a developer a 'Contributor' on the 'Dev-Web-RG', they automatically have contributor rights to every VM and DB within that group.
This is a massive time-saver for administrators. Imagine having to manually assign permissions to 50 different resources every time a new team member joins. By leveraging RG-level RBAC, you create a security boundary that is easy to audit and manage. Just remember: permissions can be additive. If a user has 'Reader' access at the subscription level but 'Contributor' access at the RG level, their most permissive right wins for the resources in that specific group.
What is the difference between Azure Tags and Resource Locks?
To master Azure governance, you must distinguish between Tags and Locks. Azure Tags are name-value pairs (e.g., 'Environment: Production' or 'Department: Finance') that you apply to resource groups. Tags don't affect the technical behavior of the resource; they are purely for organization and billing. If you want to see exactly how much the 'Marketing' department is spending across five different resource groups, tags are your best friend.
Resource Locks, however, are about protection. There are two types: 'CanNotDelete' and 'ReadOnly'. A 'CanNotDelete' lock allows you to read and modify a resource but prevents anyone—even an owner—from accidentally deleting it. This is a lifesaver for critical production databases. While tags help you find and bill your resources, locks ensure that your most vital infrastructure stays online, regardless of who is clicking around the portal.
How should you organize Resource Groups in a real-world scenario?
There is no one-size-fits-all answer, but most seasoned architects use one of two strategies: environment-based or application-based. In an environment-based approach, you have separate groups for 'Prod', 'Test', and 'Dev'. This makes RBAC simple because you can give developers full access to 'Dev' but zero access to 'Prod'. In an application-based approach, you group everything related to 'App-A' together, regardless of the environment, which is better for tracking the total cost of a specific product.
For the AZ-900 exam, focus on the logic: the goal is to group resources that share the same lifecycle. If you know you will deploy and delete them together, they belong in the same group. If they have different security requirements or billing owners, they should be separated. Establishing a strict naming convention—like rg-project-env-region—is a practical habit that will make you look like a pro during your technical interviews.
How can you effectively prepare for Azure governance questions?
Azure governance—including Resource Groups, Policy, and RBAC—is a significant portion of the AZ-900 exam. The trick is that Microsoft doesn't just ask for definitions; they provide scenarios. You'll be asked which tool to use to prevent accidental deletion or how to organize resources for a specific company structure. Reading the documentation is a start, but you need to apply that knowledge to simulated exam questions to build your 'exam intuition.'
This is exactly why we built Cert Sensei. We provide 1,000 expert-curated practice questions for the AZ-900, specifically designed to mimic the complexity of the real exam. Instead of just getting a 'correct' or 'incorrect' mark, you get detailed expert reasoning for every answer, explaining why the wrong options were incorrect. With our domain-level tracking, you can see if you're struggling specifically with governance and focus your study hours where they actually move the needle on your pass rate.
❓ Frequently Asked Questions
Can a single Azure resource belong to multiple resource groups?
No. A resource can only be a member of one resource group at a time. However, you can move resources between groups if they are in the same subscription and support the move operation.
Does creating a Resource Group cost any money?
No, Resource Groups are free logical containers. You only pay for the actual resources (like VMs or Storage Accounts) that you deploy inside the group.
If I delete a Resource Group, what happens to the resources inside?
Deleting a Resource Group triggers a cascading delete. Every single resource contained within that group will be permanently deleted, which is why Resource Locks are so important for production groups.