Academmia

Azure Resources and Resource Groups

az-900•mixed•

Azure architecture and services

Azure Resources and Resource Groups

Short Summary

An Azure resource is a manageable item in Azure, like a Virtual Machine (VM) or a storage account. A resource group is a logical container that helps you manage related resources together. You’ll also learn how Azure Resource Manager (ARM) treats resource groups as a management scope for organizing, controlling access, and applying governance—plus what really happens when a resource group is deleted.

Learning Objectives

By the end of this lesson, you will be able to:

  • Define an Azure resource and give a simple example.
  • Define an Azure resource group and explain why it exists.
  • Outline the management scope hierarchy (management groups, subscriptions, resource groups, resources).
  • Choose a resource group approach based on lifecycle and access needs (for example, dev vs prod).
  • Predict what happens when a resource group is deleted and what to verify first.

Core Concepts

An Azure resource is a manageable item in Azure. If you can create it, configure it, and manage it in Azure (for example, a Virtual Machine (VM) or a storage account), it is a resource.

A resource group is a logical container for related resources within a subscription. You use a resource group to manage a set of resources as a unit: deploy them together, apply access control, monitor them, and clean them up together when they’re no longer needed.

Azure Resource Manager (ARM) is the management layer for Azure. ARM uses management scopes so you can apply settings at a level that affects multiple items. A resource group is a very common scope because it’s “just wide enough” to manage a whole solution’s resources together without affecting everything in the subscription.

A simple scope hierarchy to remember is: Management group → Subscription → Resource group → Resource.

At a resource group scope, you commonly apply things like:

  • Role-Based Access Control (RBAC) (who can do what)
  • Azure Policy (what is allowed to be created/configured)
  • Resource locks (to prevent accidental changes or deletion)

Key rules of thumb:

  1. A resource belongs to one resource group at a time (some resources can be moved to a different resource group, but not every resource type supports every move).
  2. A resource group can contain resources in different Azure regions. The resource group’s location is where its metadata is stored, not a “region lock” for all resources.
  3. Deleting a resource group typically deletes all resources inside it (and resource locks can block deletion until removed).

Practical Understanding

Practical Situation 1: When you see “thing” vs “container”

A team talks about a VM, a storage account, and a database. Another person talks about “a place to put those items so we can manage them together.”

How to think about it: The VM, storage account, and database are resources (individual manageable items). The “place” that holds and organizes related resources for a solution is the resource group.

Common misunderstanding: “Resource group is just another kind of resource.” A resource group is a container (a scope), not a service instance like a VM.

Practical Situation 2: When dev and prod are mixed together

A team puts both development and production components for the same application in one resource group. Later they realize they need different access control and governance for dev versus prod.

How to think about it: Resource groups are often used as a scope for access control and governance. If dev and prod need different Role-Based Access Control (RBAC) rules or policies, separating them into different resource groups keeps those rules clean and reduces the risk of accidental changes.

Common misunderstanding: “I can fix it later with many per-resource exceptions.” You can, but it increases complexity and makes mistakes more likely.

Practical Situation 3: When someone wants to delete “just the container”

A developer wants to remove a development environment and says, “I’ll delete the resource group to clean it up.”

How to think about it: A resource group is a lifecycle boundary. Deleting the group is typically a destructive action that triggers deletion of the resources inside it as well. Before deleting, confirm the group contains only what you intend to remove (for example, only dev resources) and check for resource locks or special deletion behaviors (some services may retain data for a period due to soft delete).

Common misunderstanding: “Deleting a resource group is like deleting a folder on my laptop; the files might still exist elsewhere.” In Azure, deleting the group usually removes the resources in that group (and can break anything that depends on them).

Practical Situation 4: When you see a “location” on a resource group

A resource group shows a location, and someone assumes every resource inside must be in that same Azure region.

How to think about it: Resource groups are primarily a logical management container. The location of the resource group is about where the resource group’s metadata is stored, not a strict rule that forces all contained resources into the same region. Resource location is decided per resource.

Common misunderstanding: “Resource group region forces resource region.” Resource groups don’t work like a “region folder” that locks everything inside to the same region.

Common Pitfalls

  • Mistake: Confusing a resource with a resource group. Correction: A resource is an individual manageable item (like a VM); a resource group is a logical container used to manage related resources together.

  • Mistake: Thinking a resource can belong to multiple resource groups. Correction: A resource belongs to exactly one resource group at a time; use consistent naming and tags for cross-cutting organization.

  • Mistake: Assuming tags applied to a resource group automatically apply to its resources. Correction: Tags are not automatically inherited by contained resources; tag resources explicitly (or use tooling/automation to enforce tagging).

  • Mistake: Treating subscriptions and resource groups as the same scope level. Correction: Subscriptions sit above resource groups; resource groups sit above resources in the hierarchy.

  • Mistake: Assuming all resources in a resource group must be in the same region as the resource group. Correction: The resource group location is for metadata; each resource has its own location decision.

  • Mistake: Mixing unrelated lifecycles (for example, dev and prod) in one resource group. Correction: Group resources that you deploy, manage, and retire together so scope-based access control and governance stay clean.

  • Mistake: Forgetting that deleting a resource group can delete everything in it (or assuming deletion can’t be blocked). Correction: Treat resource group deletion as a full cleanup action; verify contents first and check for resource locks or resource-specific deletion/retention behaviors.

Check Your Understanding

  • Describe the difference between an Azure resource and a resource group using one example of each.
  • Write the scope hierarchy from highest to lowest, and explain why scope matters for governance.
  • Think of an application with a web tier, data tier, and networking. How would you group resources if you have dev and prod environments?
  • Explain why deleting a resource group is a high-impact action, and list two things you would verify before doing it.
  • Explain why the “location” of a resource group does not automatically control the region of every resource inside it.
  • If you apply Role-Based Access Control (RBAC) at a resource group scope, what is the expected effect on resources inside that group?

Further Reading