This chapter covers Azure Resource Groups, a fundamental concept in Azure's resource management hierarchy. Resource groups are a core part of the Azure Architecture Services domain, which carries approximately 30-35% weight on the AZ-900 exam. Understanding resource groups is critical because they are the primary mechanism for organizing, securing, and managing resources in Azure. This chapter will explain what resource groups are, how they work, best practices, and exactly what you need to know for the exam.
Jump to a section
Imagine you run a global logistics company. Each shipment (Azure resource) needs to be organized, tracked, and managed. Instead of scattering boxes across a warehouse, you use standard shipping containers (resource groups). Each container holds related items—say, all parts for a single customer order (an application). You can set rules on the container (policies, tags, access controls) that apply to everything inside. The container itself has a location (region) but can hold items from anywhere. When you're done with an order, you can remove the entire container at once, ensuring nothing is left behind. If you need to track costs, you tag the container and see the total for that order. Importantly, a container cannot be inside another container—resource groups cannot be nested. Also, each item can only be in one container at a time. Azure uses this container model to let you manage resources as a single unit, apply common policies, and control access collectively. If you move a container to a different warehouse (region), the items inside move with it, but the container's home region stays the same. This is exactly how Azure resource groups work: they are logical containers that hold related resources, enabling unified management, security, and cost tracking.
What is an Azure Resource Group?
An Azure resource group is a logical container that holds related resources for an Azure solution. Think of it as a folder or a project folder that groups together all the components of an application—virtual machines, databases, storage accounts, virtual networks, etc. Resource groups are a fundamental building block of Azure's resource management hierarchy. They allow you to manage a set of resources as a single unit, applying policies, permissions, and tags collectively.
The Business Problem Resource Groups Solve
Before cloud computing, managing infrastructure meant dealing with physical servers, each with its own configuration, security, and lifecycle. When you needed to deploy an application, you had to provision, configure, and manage each component individually. This was time-consuming, error-prone, and made it hard to track costs or apply consistent policies.
Azure resource groups solve this by providing a logical container that groups resources that share the same lifecycle. For example, if you have a web application that uses a virtual machine, a database, and a storage account, you can put all three in the same resource group. When you need to update the application, you can update the whole group. When you need to delete the application, you can delete the entire resource group, and all resources within it are removed automatically (if you choose). This simplifies management, improves consistency, and reduces operational overhead.
How Resource Groups Work
Every Azure resource must belong to exactly one resource group. You cannot have a resource without a resource group. When you create a resource, you must specify which resource group it will reside in. The resource group itself is a resource that exists in a specific Azure region (location). However, the resources inside the resource group can be in different regions. For example, you could have a resource group located in East US, but the virtual machines inside it could be in West Europe and the databases in Southeast Asia.
Resource groups are not containers in the sense of a folder hierarchy; they are logical groupings. You cannot nest resource groups—a resource group cannot contain another resource group. Also, a resource can only belong to one resource group at a time. If you need to move a resource to another group, you can use the Azure portal, CLI, or PowerShell to do so, as long as the resource supports move operations (most do, but some have limitations).
Key Components and Limits
Resource Group Name: Must be unique within a subscription, but can be reused across subscriptions. Naming rules: 1-90 characters, alphanumeric, underscores, periods, hyphens, and parentheses. Cannot end with a period.
Location: The region where the resource group's metadata is stored. This is not the same as the resources' locations.
Tags: Key-value pairs that you can apply to resource groups and resources for categorization and cost tracking.
Policies: Azure Policy can be assigned at the resource group scope to enforce compliance rules.
Role-Based Access Control (RBAC): Permissions can be assigned at the resource group level, applying to all resources within.
Resource Locks: You can apply a lock (ReadOnly or CanNotDelete) to a resource group to prevent accidental deletion or modification of all resources in the group.
Limits: A subscription can have up to 980 resource groups. Each resource group can contain up to 800 resources per resource type. For example, you can have up to 800 virtual machines in one resource group, but also up to 800 storage accounts, etc.
Comparison to On-Premises
In on-premises environments, you might organize servers by application in different folders or VLANs, but there is no built-in mechanism to manage them as a single unit with common policies. You would need to configure each server individually. With resource groups, you can apply RBAC, policies, and tags at the group level, and all resources inherit them. This is more efficient and reduces configuration drift.
Azure Portal and CLI Touchpoints
Azure Portal: Navigate to "Resource groups" to view, create, or manage them. You can filter by subscription, tag, or name.
Azure CLI: Use az group create --name MyGroup --location eastus to create a resource group. Use az group delete --name MyGroup to delete it and all resources inside (with --yes to skip confirmation).
PowerShell: New-AzResourceGroup -Name MyGroup -Location eastus.
ARM Templates: Resource groups are defined in the template's resources section with type: "Microsoft.Resources/resourceGroups".
Best Practices
Group by lifecycle: Place resources that share the same lifecycle (e.g., development, testing, production) in the same resource group. This allows you to deploy, update, and delete them together.
Use consistent naming conventions: Include the environment, application, and region in the name, e.g., rg-webapp-prod-eastus.
Apply tags: Use tags for cost allocation, ownership, and environment identification.
Use resource group scoped RBAC: Grant permissions at the resource group level to simplify access management.
Lock critical resource groups: Apply a delete lock to prevent accidental deletion.
Avoid mixing long-lived and short-lived resources: If a resource has a different lifecycle, consider placing it in a separate resource group.
Pricing
Resource groups themselves are free. You only pay for the resources inside them. However, there are limits as mentioned above, and exceeding them may require you to request a quota increase.
Create a Resource Group
Navigate to the Azure portal and search for 'Resource groups' in the top search bar. Click 'Create' to open the creation blade. You will need to provide a Subscription (select from your available subscriptions), a Resource group name (e.g., 'rg-webapp-prod'), and a Region (the location where the resource group's metadata will be stored, not the resources). You can also add Tags (key-value pairs) for organization. Once you click 'Review + Create' and then 'Create', Azure provisions the resource group. Behind the scenes, Azure registers the resource group in its resource manager, creating a logical container with a unique ID. This process takes only a few seconds. The resource group is now ready to host resources. You can also create a resource group using Azure CLI: `az group create --name rg-webapp-prod --location eastus`.
Add Resources to the Group
When creating a new resource (e.g., a virtual machine), you must specify the resource group it will belong to. In the creation wizard, there is a 'Resource group' dropdown where you can select an existing group or create a new one. Once you select the group and complete the resource creation, Azure adds the resource to that group. Alternatively, you can move an existing resource into a different resource group using the 'Move' action in the resource's overview page. However, not all resources support move operations—for example, Azure AD resources or some networking resources may have restrictions. When you add a resource, the resource group's RBAC permissions, policies, and tags are inherited by the resource (unless overridden at the resource level).
Apply Tags and Policies
After creating a resource group, you can apply tags and policies to manage resources collectively. To add tags, go to the resource group's 'Tags' blade and enter key-value pairs. These tags are inherited by all resources in the group, but you can also set tags at the resource level. For policies, navigate to 'Policies' under the resource group and assign built-in or custom policy definitions. For example, you can enforce that only certain VM sizes are allowed. Policies assigned at the resource group scope apply to all resources within that group. Azure Policy evaluates resources continuously and can flag non-compliant resources. Tags are especially useful for cost reporting—you can filter costs by tag in Azure Cost Management.
Manage Access with RBAC
To control who can manage resources within a resource group, use Role-Based Access Control (RBAC). In the resource group's 'Access control (IAM)' blade, you can add role assignments. For example, assign the 'Contributor' role to a user to allow them to create and manage resources in that group. Assign 'Reader' for read-only access. These permissions are inherited by all resources inside the group. This is more efficient than assigning permissions to each resource individually. Common roles include Owner, Contributor, Reader, and custom roles. Note that RBAC assignments at the resource group level can be overridden by higher-level assignments (e.g., subscription scope) or more specific assignments at the resource level.
Delete a Resource Group
When you no longer need the resources in a resource group, you can delete the entire group. In the Azure portal, navigate to the resource group and click 'Delete resource group'. You must type the resource group name to confirm. Azure will then delete all resources inside the group in a specific order (dependencies first). This is a powerful operation—it removes everything at once, preventing orphaned resources. However, be cautious: if any resource has a delete lock, the deletion will fail. Also, if the resource group contains resources that are not deletable (e.g., some networking resources), the deletion may partially succeed or fail. Always ensure you have backups or that the resources are expendable. Use Azure CLI: `az group delete --name rg-webapp-prod --yes --no-wait`.
Scenario 1: E-commerce Application Deployment
A retail company is deploying a new e-commerce application on Azure. The application consists of multiple Azure resources: a virtual machine for the web server, an Azure SQL Database for product data, an Azure Storage account for product images, and an Azure Load Balancer for traffic distribution. The development team decides to place all these resources in a single resource group named 'rg-ecommerce-prod' located in 'East US'. This allows them to manage the entire application as a single unit. They apply tags like 'Environment=Production' and 'Application=Ecommerce' for cost tracking. They also assign the 'Contributor' role to the DevOps team at the resource group level, so they can deploy updates. When a new version of the application is ready, they can update the entire group. If they need to decommission the application, they delete the resource group, and all resources are removed cleanly. This avoids leaving behind unused resources that incur costs.
Scenario 2: Multi-Environment Development
A software company uses Azure to develop a mobile app backend. They have three environments: development, testing, and production. They create three resource groups: 'rg-mobileapp-dev', 'rg-mobileapp-test', and 'rg-mobileapp-prod'. Each group contains identical resources (e.g., App Service, Cosmos DB, Functions). The development group has less restrictive policies (e.g., lower cost SKUs), while the production group has strict policies (e.g., geo-redundancy, high availability). Each group has its own RBAC assignments: developers have Contributor access only to the dev group, testers have Contributor to the test group, and only senior engineers have Contributor to the prod group. This isolation prevents accidental changes to production. Tags are used to track costs per environment. The company can easily tear down the dev environment by deleting the dev resource group, saving costs overnight.
Scenario 3: Cost Allocation for Departments
A large enterprise has multiple departments sharing an Azure subscription. Each department runs its own applications. To allocate costs correctly, they create a resource group for each department, e.g., 'rg-marketing', 'rg-sales', 'rg-engineering'. All resources for a department are placed in its respective group. They apply a tag 'Department' with the department name. Azure Cost Management can then generate reports that show costs by department based on resource group. This enables chargeback. If a department's resources are accidentally placed in the wrong group, costs are misattributed, leading to budget disputes. Therefore, they enforce policies that require a specific tag on all resource groups. Without proper resource group organization, cost tracking becomes a manual, error-prone process.
Exactly What AZ-900 Tests
AZ-900 objective "Describe how to create and manage resource groups" falls under Domain 2: Azure Architecture and Services. The exam expects you to understand:
The purpose of resource groups (logical container for related resources)
That each resource must belong to exactly one resource group
That resource groups cannot be nested
That resource groups can contain resources in different regions
That you can apply RBAC, policies, and tags at the resource group level
That deleting a resource group deletes all resources within it (unless locked)
The default limit of 980 resource groups per subscription
The concept of resource group location (metadata storage location)
Common Wrong Answers and Why Candidates Choose Them
"Resource groups are used to group resources by region." – Wrong. Resource groups are logical, not geographical. Resources within a group can be in different regions. Candidates confuse resource group location (where metadata is stored) with the actual resource locations.
"A resource can belong to multiple resource groups." – Wrong. Each resource belongs to exactly one resource group. Candidates might think of tags, which can be multiple, but resource group membership is exclusive.
"Resource groups can contain other resource groups." – Wrong. Resource groups cannot be nested. Candidates may think of folder hierarchies.
"Resource groups are used to manage costs by grouping resources with similar costs." – While resource groups help with cost management, the primary purpose is logical organization and lifecycle management. Cost management is a use case, not the definition.
Specific Terms and Values
Resource group name: 1-90 characters, alphanumeric, underscores, periods, hyphens, parentheses, no trailing period.
Maximum resource groups per subscription: 980 (soft limit, can be increased by request).
Maximum resources per resource group: 800 per resource type.
Resource group location: The region where the resource group's metadata is stored, e.g., 'East US'.
RBAC roles: Owner, Contributor, Reader are the most common.
Lock types: CanNotDelete and ReadOnly.
Edge Cases and Tricky Distinctions
Resource group location vs. resource location: The exam may ask where the resource group's metadata is stored. It is stored in the region you specify when creating the group. However, resources inside can be in any region.
Moving resources: Some resources cannot be moved (e.g., Azure AD resources, some networking resources). The exam may test that not all resources support move operations.
Deleting a resource group with locks: If a resource group has a CanNotDelete lock, you cannot delete the group. You must remove the lock first. The exam may present a scenario where deletion fails.
Resource group deletion behavior: When you delete a resource group, all resources inside are deleted. However, if a resource cannot be deleted (e.g., due to a lock), the deletion fails, and the group remains.
Memory Trick
"One resource, one group, no nests, all regions." – This reminds you that each resource belongs to one resource group, resource groups cannot contain other resource groups, and resources in a group can be in any region. For the exam, also remember the 980 group limit and the 800 resources per type limit.
A resource group is a logical container for related Azure resources that share the same lifecycle.
Every Azure resource must belong to exactly one resource group.
Resource groups cannot be nested.
Resources in a resource group can be in different Azure regions.
You can apply RBAC permissions, policies, and tags at the resource group level, and they are inherited by all resources in the group.
Deleting a resource group deletes all resources within it (unless locks are applied).
The default maximum number of resource groups per subscription is 980.
Each resource group can contain up to 800 resources per resource type.
Resource groups are free; you only pay for the resources inside.
Resource group names must be 1-90 characters, alphanumeric, with underscores, periods, hyphens, and parentheses, and cannot end with a period.
These come up on the exam all the time. Here's how to tell them apart.
Resource Group
Logical container for resources that share a lifecycle.
Can contain resources from multiple regions.
Cannot be nested.
RBAC, policies, and tags apply at this scope.
Max 980 per subscription.
Subscription
Billing boundary and management boundary.
Contains all resources for an organization or department.
Can contain multiple resource groups.
RBAC, policies, and tags can be applied at subscription scope (inherited by resource groups).
Each subscription has a default quota of 980 resource groups.
Mistake
Resource groups are used to group resources by region.
Correct
Resource groups are logical containers; resources within a group can be in different regions. The resource group itself has a location (where metadata is stored), but that is not related to the resources' locations.
Mistake
A resource can belong to multiple resource groups.
Correct
Each Azure resource belongs to exactly one resource group. You cannot assign a resource to multiple groups. If you need to organize resources across groups, use tags.
Mistake
Resource groups can be nested like folders.
Correct
Resource groups cannot be nested. You cannot have a resource group inside another resource group. The hierarchy is flat within a subscription.
Mistake
Deleting a resource group deletes only the group, not the resources.
Correct
Deleting a resource group deletes all resources inside it (unless they have locks). This is a key feature: it allows you to clean up an entire application at once.
Mistake
Resource groups are free, but they have a cost associated with them.
Correct
Resource groups themselves are free. You only pay for the resources (VMs, storage, etc.) inside them. There is no charge for the group itself.
Yes, you can move most Azure resources between resource groups using the Azure portal, CLI, or PowerShell. However, some resources have limitations. For example, you cannot move Azure AD resources, virtual machines with managed disks (in some cases), or resources that are in a different region than the target resource group? Actually, resources can be moved to a resource group in a different region? No, the move operation is within the same subscription or between subscriptions, but the resource group's location does not restrict the resource's location. The key is that the resource must support the move operation. Always check the documentation for specific resource types. For the exam, know that moving resources is possible but not for all resources.
If a resource group has a lock (CanNotDelete or ReadOnly), you cannot delete the resource group. You must first remove the lock. The lock prevents deletion of the group and all resources inside. This is a safety feature. For example, if you have a production resource group, you should apply a CanNotDelete lock to prevent accidental deletion. The exam may test that locks must be removed before deletion.
Yes, you can have an empty resource group. It is a logical container that can exist without any resources. This is useful for planning or as a placeholder. However, you are not charged for an empty resource group since the group itself is free.
A resource group is a container for resources that share a lifecycle, while a management group is a container for subscriptions. Management groups allow you to apply governance (policies, RBAC) across multiple subscriptions. Resource groups are within a subscription. Management groups are above subscriptions in the hierarchy. For AZ-900, know that management groups are for organizing subscriptions, not resources.
No, you cannot change the location (region) of a resource group after it is created. The location is set at creation time and stores the resource group's metadata. If you need a different location, you must create a new resource group and move resources to it.
The default limit is 980 resource groups per subscription. This is a soft limit, meaning you can request an increase by opening a support ticket. However, for the exam, remember 980 as the default.
Yes, you can assign custom RBAC roles at the resource group scope. Custom roles are defined at the subscription or management group level but can be assigned at any scope, including resource groups. This allows fine-grained permissions.
You've just covered Azure Resource Groups — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?