Understanding Azure Resource Groups and Management Hierarchy

Overview and What You Will Learn

In this lab, you will create a proper Resource Group, understand exactly what it does and does not contain, and see how it fits inside the larger Subscription and Management Group hierarchy that every Azure environment is organized around.

Why This Matters in Production

At a growing fintech like Razorpay, a subscription with hundreds of resources and no consistent Resource Group structure becomes impossible to manage - nobody can tell which VM belongs to which project, billing reports become meaningless, and deleting a test environment risks accidentally taking down something in production. Getting the hierarchy right from day one is what makes an Azure environment auditable, billable per team, and safe to clean up.

Core Principles

A Resource Group is a logical container - it holds no physical infrastructure itself, but every single resource you create must belong to exactly one Resource Group. A Subscription is the billing and access boundary that contains many Resource Groups. A Management Group sits above multiple subscriptions, letting you apply policy and access rules across all of them at once.

Permissions and policies applied at a higher level automatically flow down to everything beneath it - a Contributor role granted at the Subscription level applies to every Resource Group and Resource inside it, unless something more specific overrides it lower down.

Remember

Deleting a Resource Group permanently deletes everything inside it. There is no separate confirmation step asking "are you sure this VM should be included" - the entire group goes together.

Detailed Step-by-Step Practical Lab

1. Log into the Azure CLI and confirm your active subscription:

2. Create a Resource Group with a naming convention that signals its purpose and environment:

3. Create a second Resource Group to see how two teams' resources stay isolated from each other:

4. Create a simple resource (a Storage Account) inside the first group to see the parent-child relationship in action:

5. List every Resource Group in your subscription and confirm both groups exist independently:

6. Confirm the Storage Account is correctly scoped inside its own Resource Group and not the other one:

Note

az resource list shows every resource of every type inside a specific Resource Group - this is the fastest way to answer "what actually lives in here" before deleting anything.

7. Clean up both Resource Groups once you have confirmed the hierarchy behaves as expected:

Production Best Practices & Common Pitfalls

Common Mistake

Putting every resource for an entire company into a single Resource Group named something generic like rg-main. This makes it impossible to apply different access controls per team or safely delete one project's resources without risking another team's production workload. Use one Resource Group per application, per environment.

Tip

Adopt a naming convention before creating your first real Resource Group, not after you already have fifty of them named inconsistently. A pattern like rg-<app>-<env>-<region> (e.g. rg-payments-prod-mumbai) makes every resource's purpose obvious at a glance.

• Group by lifecycle, not by resource type. A VM, its NIC, and its disk that all get deleted together belong in the same Resource Group - do not create a separate "all VMs" group and a separate "all disks" group, since that breaks the ability to delete a whole environment cleanly.
• Region of the group is metadata only. The Resource Group's own region setting only affects where its deployment metadata lives - resources inside it can still be deployed to different regions individually if needed.

Quick Reference & Troubleshooting Commands