Azure Resources and Management Scope

Playback speed

Swipe, scroll or use ← →

Know the object you actually manage

Everything an Azure administrator does happens to a resource, so the word has to be exact. An Azure resource is a manageable item such as a virtual machine, storage account, web app, database, or virtual network.

A resource is the thing an administrator creates, configures, monitors, moves or removes. It exists, it has settings, and it can be pointed at. That distinguishes it from the two words that surround it in every Azure conversation:

Word	What it is	Example
Resource	A deployed, manageable item	A storage account named `salesdata01`
Resource provider	The service that makes a type available	`Microsoft.Storage`
Resource group	A container for related resources	`rg-sales-prod`

1 / 20

Quick check

Which of these is an Azure resource?
1. AA service that supplies resource types to the platform.
  
  That describes a resource provider, which makes resource types available rather than being a deployed item.
2. BA container that groups resources from several unrelated subscriptions together.
  
  That describes a container, and a resource group holds related resources rather than spanning unrelated subscriptions.
3. CA storage account an administrator creates and configures.
  
  Right. A resource is a manageable item such as a virtual machine, storage account, web app, database or virtual network.
2 / 20
See where the types come from

Resources do not appear from nowhere. Each type is published by a service that knows how to create and operate it.

A resource provider is a service that supplies Azure resource types; for example, Microsoft.Compute supplies virtual machine resources and Microsoft.Storage supplies storage resources. The provider describes which service makes a type available, while the resource is a deployed item of that type.

The naming convention repays a moment of attention, because provider names appear in templates, role definitions and error messages long before anyone explains them:

Provider Supplies

Microsoft.Compute Virtual machine resources

Microsoft.Storage Storage resources

Read it as publisher and product: the provider is the publisher, and your virtual machine is one copy of the product.

3 / 20
Quick check

What does a resource provider such as Microsoft.Compute do?
1. AIt supplies Azure resource types, such as virtual machines.
  
  Right. A resource provider is the service that supplies Azure resource types, and Microsoft.Compute supplies virtual machine resources.
2. BIt copies the tags of a resource group onto every resource inside it.
  
  Tags on a resource group do not propagate to its resources, and propagation is not a provider's job in any case.
3. CIt groups deployed resources that share a lifecycle into one container.
  
  Grouping deployed resources is what a resource group does; a provider makes the types available in the first place.
4 / 20
Put related resources in one container

A solution is rarely one resource. A single web application can involve an app service, a database, a storage account and a virtual network, and managing four unrelated objects is unpleasant.

A resource group is a container for related resources that an organization wants to manage as a group. It is not a separate cloud or a billing account: it is a management boundary inside a subscription.

A resource group also acts as a scope for policies, roles and resource locks, which is why the choice of container is a governance decision and not only a tidiness decision.

5 / 20
Quick check

What is a resource group for?
1. ASupplying resource types such as virtual machines and storage.
  
  Supplying resource types is the job of a resource provider, not of a container.
2. BHolding related resources so that an organization can manage them as a group.
  
  Right. A resource group contains related resources that an organization wants to manage together.
3. CReplacing the subscription as the broadest management scope.
  
  A resource group sits below the subscription in the hierarchy and does not replace it.
6 / 20
Keep your progress in the app

That’s 3 of 10 quick checks. In the app they stay answered, and every lesson remembers where you left off.

Get the app Keep reading here
Understand membership and connectivity

Two rules govern how a resource relates to its container, and they are easy to confuse because they pull in opposite directions.

Each resource can exist in only one resource group, but a resource can connect to resources in other resource groups. Membership is exclusive; connectivity is not.

This lets connected components remain separate when their management lifecycles differ. A web app in rg-app-prod can use a database in rg-data-shared without either resource changing container. Membership answers "what gets deployed, updated and deleted together?", while connectivity answers "what talks to what?" — and the two questions genuinely have different answers.

7 / 20
Quick check

A web app in one resource group must talk to a database in another. What is true about that arrangement?
1. AA resource can belong to several groups when those groups share one subscription.
  
  Membership is exclusive: a resource exists in only one resource group, whatever the subscription arrangement.
2. BEach resource lives in one group, but it can connect to resources in other groups.
  
  Right. A resource exists in a single resource group and can still connect to resources in other groups.
3. CA resource must move to a new provider before it can connect across group boundaries.
  
  Providers supply resource types and have nothing to do with permitting connections between groups.
8 / 20

Provider	Supplies
Microsoft.Compute	Virtual machine resources
Microsoft.Storage	Storage resources

Read the hierarchy from broad to narrow

Management in Azure is layered, and every governance setting is applied at one of those layers.

Azure has four management scopes: management groups, subscriptions, resource groups, and resources. Management groups provide the broadest of these four scopes, and an individual resource is the narrowest. A subscription contains resource groups and resources and establishes a boundary within which those items are managed.

Scope	Reach
Management group	Broadest: can sit above several subscriptions
Subscription	Contains resource groups and resources, and bounds their management
Resource group	Contains related resources
Resource	Narrowest: one manageable item

Memorize the order in that direction, broad to narrow. Questions that shuffle the four terms are testing exactly this sequence.

9 / 20

Quick check

Which sequence orders the Azure management scopes from broadest to narrowest?
1. AManagement group, subscription, resource group, resource.
  
  Right. Management groups are the broadest scope and an individual resource is the narrowest.
2. BSubscription, management group, resource, and then resource group.
  
  A management group is broader than a subscription, so this order inverts the top two levels.
3. CResource group, subscription, management group, then resource provider.
  
  A resource provider is not a management scope at all, and resource groups are not the broadest level.
10 / 20
Choose the scope by the reach you want

The hierarchy is not decoration: it decides how far a setting travels.

A setting applied at a higher scope is inherited by lower scopes beneath it. For example, a policy applied to a subscription reaches its resource groups and resources. A policy applied to one resource group reaches that group and its resources but does not automatically reach another resource group.

Choosing scope is therefore a reach decision: use the highest level that matches the intended audience, without unintentionally affecting unrelated resources. Suppose two subscriptions sit under the same management group and a rule must apply to only one of them. Assigning it at the management group would reach both, and assigning it to a single resource group inside the target would miss the rest of that subscription. The target subscription is the level that matches the audience exactly.

11 / 20
Quick check

A policy is assigned at subscription scope. What happens below it?
1. AEvery subscription in the tenant receives it as well.
  
  Inheritance runs downward from the assigned scope, so a sibling subscription is not affected by it.
2. BOnly the subscription object itself receives the policy.
  
  A setting at a higher scope is inherited by the lower scopes beneath it, so the subscription is not the only object reached.
3. CThe resource groups and the resources inside that subscription inherit it.
  
  Right. A policy applied to a subscription reaches the resource groups and resources it contains.
12 / 20

Group by lifecycle, not by diagram

Once you can draw the hierarchy, the real design question appears: which resources belong in the same group?

A useful resource-group design follows operational life rather than a diagram alone. Resources in a resource group should share a lifecycle so they can be deployed, updated, and deleted together. If two connected resources must be released or retired on different schedules, they should be placed in different resource groups even though they communicate.

Situation	Design
Front end and its configuration ship together every sprint	One resource group
Application is rebuilt often, its database is kept for years	Two resource groups, still connected
A pilot that will be removed whole in three months	One resource group of its own

"They talk to each other" is not a reason to share a container. "They are born and buried together" is.

13 / 20

Quick check

A web app is redeployed and retired often, while the database it uses must be kept for years. How should they be organized?
1. AIn one resource group, because connected resources have to share a container.
  
  Connected resources are not required to share a container, and this one would tie the database to the application's retirement.
2. BIn separate resource groups, because their lifecycles differ; they can still connect.
  
  Right. Resources in a group should share a lifecycle, and a resource can still connect to resources in other groups.
3. CIn separate subscriptions, because resources in different groups cannot communicate at all.
  
  Cross-group communication is supported, so splitting subscriptions is neither required nor the reason given here.
14 / 20
Respect the deletion boundary

The lifecycle rule has a blunt consequence, and it is the one that causes incidents.

Deleting a resource group deletes all resources in that group. This makes the container convenient for retiring an entire solution, but it also makes the boundary consequential: a long-lived database parked in a project group disappears with the project.

Two useful details soften the design. Moving a resource is possible, so an early mistake is not permanent. And resources in a group can be in different regions from the resource group, so geography does not have to dictate grouping.

15 / 20
Quick check

A temporary solution's resources all retire on the same date, and the administrator wants one operation to remove them. Which design supports that?
1. APut them in one lifecycle-aligned group and delete that group.
  
  Right. Deleting a resource group deletes all resources in that group, which is exactly the single operation required.
2. BPlace each resource in several groups, then delete any one of those groups.
  
  A resource exists in only one resource group, so it cannot be placed in several of them.
3. CTag the resource group and rely on the tag reaching every resource inside it.
  
  Tags applied to a resource group are not inherited by its resources, and tagging deletes nothing.
16 / 20

Separate scope from metadata

A resource group can be a scope for policies, roles and resource locks. Tags serve a different purpose: they label and organize resources.

Because policy and access settings inherit down the management hierarchy, it is tempting to assume that every attribute of a parent flows downward. It does not. Tags applied to a resource group are not inherited by the resources in that group.

Applied to a resource group	Reaches the resources inside?
A policy assignment	Yes, by inheritance
A role assignment	Yes, by inheritance
A resource lock	Yes, as a scope for the lock
A tag	No, not automatically

Treat tags as labels you place deliberately, on the objects you actually want labelled — for example when cost reports have to attribute spend per resource.

17 / 20

Quick check

An administrator applies a tag to a resource group. What should the administrator expect?
1. AEvery resource in the subscription picks the tag up at once.
  
  Tags do not propagate downward, and a tag on one group could not reach an entire subscription in any case.
2. BThe tag turns into a policy assignment at subscription scope.
  
  A tag is metadata for labelling and organizing; it does not become a policy assignment at any scope.
3. CThe resources inside the group do not pick that tag up automatically.
  
  Right. Tags applied to a resource group are not inherited by the resources in that group.
18 / 20
Key takeaways

Azure Resource Manager is the deployment and management service that creates, updates, and deletes Azure resources through a consistent management layer. It gives the hierarchy and its controls a common management path, so the same scopes and rules apply whichever tool sends the request.
- A resource is a manageable Azure item, while a resource provider supplies resource types.
- The four management scopes run from management groups to subscriptions, resource groups, and resources.
- Higher-scope settings inherit downward, but the selected scope determines how far they reach.
- Group resources by shared lifecycle, remember that group deletion removes its resources, and do not expect group tags to inherit.
- Membership is exclusive and connectivity is not: one group per resource, connections wherever the solution needs them.
19 / 20
Quick check

Which summary is accurate?
1. AResource providers contain resources, tags inherit downward, and deleting a group leaves its resources running.
  
  Providers supply types rather than containing resources, tags do not inherit, and deleting a group deletes everything in it.
2. BResource Manager is the consistent management layer, scopes inherit downward, and group deletion removes its resources.
  
  Right. Resource Manager creates, updates and deletes resources through one management layer, higher scopes inherit downward, and deleting a group removes its resources.
3. CManagement groups are the narrowest scope, resources belong to several groups, and a policy at one group reaches every other group.
  
  Management groups are the broadest scope, membership is exclusive, and a policy on one group does not automatically reach another.
20 / 20
10 quick checks · then the test

In the app, finishing the quick checks opens this lesson’s 10-question test, and the ones you miss come back exactly when you’re about to forget them.

Take this lesson’s test → Next lesson: Azure Administration End-to-End Workflow Get the app

← Previous Keep your progress · Get the app Next card →

The whole course, on your phone

Lessons you can read, audio you can listen to on the way to work, and practice that remembers what you got wrong.

Get the app

Azure Resources and Management Scope

Know the object you actually manage

See where the types come from

Put related resources in one container

Keep your progress in the app

Understand membership and connectivity

Read the hierarchy from broad to narrow

Choose the scope by the reach you want

Group by lifecycle, not by diagram

Respect the deletion boundary

Separate scope from metadata

Key takeaways

10 quick checks · then the test

The whole course, on your phone