Where does an Azure resource belong?
Ada opens the portal to investigate the test shop and finds the production shop beside it. Both contain a resource called “storage”. Before she clicks anything, she asks, “Which directory am I signed into, who pays for this subscription, and which group contains the test application?” Those three questions turn a crowded portal into a map. A resource group is a useful project boundary; it does not cancel permissions inherited from its parent.
A resource is something Azure can manage, such as a virtual machine or storage account. Microsoft Entra ID manages identities. A tenant is an organisation's instance of that identity service, containing its directory of users, groups and applications. A subscription trusts one Entra tenant for authentication; one tenant can serve several subscriptions.
- Scope
- The set of Azure resources an assignment applies to. For example, an access role assigned on a resource group covers that group and its resources. The same role at subscription scope applies more widely.
- Management group
- Organises subscriptions so the team can apply shared governance. Management groups can contain other management groups too.
- Subscription
- Organises Azure usage, access and service limits. Think “which subscription will own this test environment?”
- Resource group
- A container for related resources you plan to manage together. For example, the disposable resources for one test.
- Resource
- The actual service instance, such as the test's virtual machine. Most resources you create in these labs belong to one resource group.
Azure role permissions can be inherited from a broader scope. A grant on a management group may therefore affect both production and test subscriptions below it. A grant on just the test resource group has a narrower reach. Tags do not follow this access-inheritance rule. We will separate these ideas below.1
Place the resources, then check access
Our shop has chosen separate production and test subscriptions. Place two resource groups according to that plan. Then inspect a role assigned above both subscriptions. The last decision asks whether separating the subscriptions also removed that inherited access. Drag an item or choose its destination below; read the feedback before pressing Next. On a phone, swipe the board sideways to see both subscriptions.
Who is signing in, and what may they do?
Authentication checks an identity. Authorization checks whether that identity may perform an action. Signing in successfully does not automatically allow someone to create or delete an Azure resource.
Entra ID was previously named Azure Active Directory, or Azure AD. It is a cloud identity service, not simply Windows Server Active Directory Domain Services (AD DS) running on someone else's computer. AD DS manages traditional domains and Group Policy; Entra ID supports cloud identity and application access. They can be integrated, and Windows devices can join Entra ID through a different mechanism. You do not need to memorise their protocols in this class.2
A security group is a membership list
Imagine three engineers joining Storefront-Test-Engineers. That security group represents the team. An administrator can assign an Azure role to the group, instead of repeating an assignment for each person. The group and the resource group are different things: one groups identities; the other groups Azure resources.
A Microsoft 365 group supports collaboration; a security group is a useful choice for our access example. Membership does not grant every possible permission. Access depends on the actual role assignments and the service involved.
Group-based assignments make reviews easier, but removing someone from one group is not a complete offboarding process. They might have direct assignments, other memberships or active sessions. Check their effective access—the permissions they actually have—rather than assuming one membership change removes everything.
Separate environments, then verify the controls
Separate subscriptions can make production and test easier to govern: you can assign different access, examine their costs separately and manage applicable quotas. A quota is a service limit, such as a limit on virtual CPU capacity. Some limits depend on the service, region and subscription.
A subscription is not an automatic firewall. Azure networks can connect across subscriptions, and a shared parent role assignment can grant access to both. Blast radius means the possible impact of a mistake or compromised account. Reducing it requires suitable permissions and network controls, not just a different subscription name.
Cost separation is not the same as separate invoices
You can inspect costs by subscription, but invoice grouping depends on the billing agreement and account structure. For example, a Microsoft Customer Agreement billing profile can include charges for several subscriptions. Avoid promising “one subscription, one invoice.”3
For our shop, document three separate checks: who may change production, what network traffic can reach it, and how its costs will be reviewed. Passing one check does not prove the other two.
Group resources by how you manage them
A lifecycle is the sequence of creating, updating and retiring something. A disposable test VM and its disposable disk may share a lifecycle. A production database that must survive web-server replacements has a different one.
Group by lifecycle; check before deleting.
Our shop might use rg-store-test for a temporary test and keep long-lived shared resources elsewhere. An application can use resources across groups. “One group per application” is a possible design, not a rule that overrides different lifecycles.
For resources managed at resource-group scope, each belongs to one group at a time. Some Azure resource types exist at higher scopes, so “every Azure resource must be inside a resource group” is too broad. A group's selected region records its management metadata; it does not force all of its resources into that region.
Deletion is a real operation, not a filing change
Deleting a group requests deletion of its contents. Locks, dependencies or permissions can prevent completion. Before retiring a real workload, identify shared dependencies, confirm backups and retention requirements, and agree the change with its owner. Check what remains afterwards; related items in other groups are outside that group deletion.
Moving a resource is also a change that needs planning. Supported moves and restrictions vary by resource type, and resource IDs can change. Do not assume every item can be moved to a new group before cleanup. Use Microsoft's move guidance and the resource's support information.4
Describe ownership with names and tags
A name helps someone recognise a resource. rg-store-test tells our team that this is a resource group for storefront testing. Naming rules differ by resource type, so check the supported characters, length and uniqueness requirements before using the same pattern everywhere.
A tag is a key-value label: env=test has key env and value test. We also use owner=store-team and cost-center=training to describe responsibility and reporting.
- No automatic tag inheritance
- Setting a tag on a subscription or group does not automatically copy it to contained resources. Apply tags explicitly or configure a suitable policy.
- Policy effects differ
- An audit reports a problem; a deny can block a matching request; a modify policy can change supported properties such as tags. An audit-only rule does not add tags.
- Existing resources need attention
- Copying a tag with a modify policy requires appropriate configuration. Updating existing resources can require a remediation task and permissions for the policy's managed identity—the identity used to perform those changes.
Azure supports tags on subscriptions, resource groups and supported resources, not management groups. Tag support and limits vary. Tags organise information; a label such as env=prod does not itself change permissions or prevent deletion.5
A plan the next engineer can explain
The shop uses its existing Entra tenant, groups the two subscriptions for shared governance and assigns access according to each team's work. Test engineers should not receive a broad parent grant that unintentionally reaches production. Network connectivity gets a separate review.
Resource groups follow the resources' expected lifecycles. The team records owner, environment and cost centre where tags are supported. It tests the chosen policy effect and reviews existing resources. This is a proposed teaching design; drawing it does not configure any of those controls.
Check the official explanations
Read Resource Manager and management scopes and management groups. Use the diagrams above to explain where your test resources would belong.
Find your tenant and subscription
Use a training account you are authorised to use. If you do not have one, follow Lab setup or sketch the example hierarchy on paper. The inspection steps do not require creating a subscription or a management group.
In the Azure portal, search for Subscriptions. Open the training subscription and record its display name and ID. If nothing is listed, check the directory and ask the account owner about access.
Open Microsoft Entra ID and identify the tenant. Viewing its details may require directory permissions. A permission error is a reason to ask the administrator, not to change tenant settings.
For the command-line exercise, choose Bash in Cloud Shell. An ephemeral session needs no attached storage, but variables and local files disappear when it ends. Persistent Cloud Shell storage can incur charges. Run:
az account show --query '{subscription:name,subscriptionId:id,tenant:tenantId}' --output tableCheck: The displayed subscription must be your approved training subscription before doing Lab 2. If needed, select it with az account set --subscription "YOUR_TRAINING_SUBSCRIPTION_ID" and run the check again.
Your first command. Lab 2 is where this course starts running Bash against Azure. It assumes the terminal warm-up: a line like LAB_SUB=$(...) stores a value and prints nothing, and that silence is success.
Create one empty, tagged group
This exercise creates only a resource-group container. It does not create a VM or storage account. Cloud resources added later can incur charges. Use the same Bash session throughout; stop if any command fails. Choose an allowed region for your training subscription.
Save the selected subscription ID and make a new group name. These variables keep later commands pointed at the same place.
LAB_SUB=$(az account show --query id --output tsv) LAB_RG="rg-campux-class07-$(date -u +%Y%m%d%H%M%S)" LAB_REGION="westeurope" printf 'Subscription: %s\nNew group: %s\n' "$LAB_SUB" "$LAB_RG" az group exists --subscription "$LAB_SUB" --name "$LAB_RG"
Expected: false. If it says true or reports an error, stop and choose a fresh name or resolve the error before creating anything.Create the group with the three example tags:
az group create --subscription "$LAB_SUB" --name "$LAB_RG" \ --location "$LAB_REGION" --tags owner=learner env=lab cost-center=training
Expected: The result names your group and includes those tags. If a policy denies the request, read the reason and ask the training administrator; do not change the policy to complete this lab.Inspect the group and its contents:
az group show --subscription "$LAB_SUB" --name "$LAB_RG" --query tags az resource list --subscription "$LAB_SUB" --resource-group "$LAB_RG" --output table
Expected: Three tags on the group and no resources inside. This confirms the group tags and an empty group. It does not demonstrate tag inheritance on a child resource, because you have not created one.Complete Lab 3 before cleanup. Then list the contents again. If anything is listed or the command fails, stop and identify what is there. Only delete the empty group you just created:
az resource list --subscription "$LAB_SUB" --resource-group "$LAB_RG" --output table az group delete --subscription "$LAB_SUB" --name "$LAB_RG" az group exists --subscription "$LAB_SUB" --name "$LAB_RG"
Check: Read the deletion confirmation carefully. The final existence check should return false after a successful deletion. If the shell session was lost, recover and verify the exact subscription and group in the portal before doing cleanup.
Connect the screen to the hierarchy
Search Resource groups and open the exact group from Lab 2. Overview shows its subscription and location. The location is for group metadata, not a command placing all future resources in one region.
Open Tags and compare the values with the command output. Open Access control (IAM) if permitted and inspect role assignments, including inherited ones. Do not add roles for this exercise.
Open Deployments. This is deployment history, not a record of every change. An empty group created without a template deployment may have no entries. The Activity log is a separate view of management events.
Write a sentence naming the tenant, subscription and resource group you inspected. Return to Lab 2's cleanup step when finished.
Three questions before a change
The hierarchy helps organise work. Check its actual settings before relying on it.
Inspect direct and inherited roles, relevant group memberships and the resource scope. A narrower new assignment does not remove a broader existing one.
A website may depend on a database or network in another group. Map those relationships before moving or deleting resources.
Read the policy's effect and scope. Distinguish reporting a missing tag from adding it or refusing a request.
Describe the plan before creating resources
Ask who will use it, how long it should exist, what it may connect to and who pays. Choose a subscription and resource-group layout that fits those answers. Record the access review and cleanup owner. A diagram makes those decisions discussable; it does not enforce them.
Locate the test shop before changing it
Use the fictional evidence below. This is a desk exercise; it does not provision Azure resources or measure a live service.
Tenant: Campux directory Subscription: Campux training Group: rg-shop-test Resource: test image account Existing grant: Reader at subscription
Draw the four levels in order.
Place the Reader grant and mark the children it reaches.
Open the empty-group lab below; check your active subscription before creation and confirm the group contains no resources before deletion.
Check your reasoning after you finish
The resource sits inside a group, subscription and tenant. Subscription Reader reaches its children but does not supply blob-data read access. A test label does not remove inherited roles or guarantee that deletion is harmless.
Check your understanding
Four graded drills and two unscored situations. Multi-select options shuffle; choose by meaning. Practice preserves your first-attempt score. The game can save progress in this browser.
B. Management groups organise subscriptions; subscriptions contain resource groups; those groups contain the resources in this example. Assigning an Azure role on a shared management group can reach more resources than assigning it on one resource group. The Entra tenant provides identities associated with this structure.
C. Check the requested action, scope and effective permissions, then read any policy or other service error. Authentication and permission to change an Azure resource are different. Creating another tenant is not the default fix for an access error.
Select the statements about the VM's group, deletion checks and policy configuration. Resource-group tags do not automatically copy to children; management groups do not support tags. An audit reports a missing tag without adding it. Deletion can fail or be blocked, so verify the result as well as the intended contents.
TEST-ENVIRONMENT PLAN
1. Use separate subscriptions for this shop's production and test.
2. Assign only the access each team needs for its work.
3. Inspect roles inherited from the shared management group.
4. Assume no network traffic can cross the subscription boundary.Line four. Subscription separation alone does not prove network isolation. Networks can connect across subscriptions. Review the required connections and network rules, separately from reviewing role assignments. The layout is a starting point for those checks.
Start with the teammate’s task. Ask what operation failed and in which subscription and resource group. A portal screenshot of a resource name is not enough to locate the access boundary.
Trace the grant. Check the signed-in tenant, the subscription and both direct and inherited assignments. A resource-group role adds access; it cannot erase a broader parent grant.
Offer a bounded fix. Change the relevant assignment through the owner and verify the original operation. Record an end date for temporary access rather than handing out subscription Owner to clear an error.
Concede the cleanup goal. A retired test application should not keep costing money. First list the resources and ask whether any are shared with a still-running application.
Name the deletion boundary. Deleting a resource group deletes its contained resources; a matching tag is not a protection mechanism. Check dependencies, locks and required retained data before deletion.
Offer evidence of completion. Use a disposable group for practice. In real work, follow the approved retirement plan, verify what disappeared, and record any resources or assignments managed outside that group.
Five checks to carry into the next class
- Find the tenant for identities and the management scope for the resource task.
- Separate sign-in, resource permission, network access and billing arrangements.
- Inspect inherited role assignments; separate subscriptions do not automatically remove them.
- Plan resource groups around lifecycle, then inspect dependencies before deletion or a move.
- Tags do not automatically copy downward. Check the policy effect and how existing resources will be handled.
- Microsoft's Azure RBAC scope guide explains inheritance. Management groups organise subscriptions associated with the directory. ↩
- Compare AD DS and Entra ID, group types and access, and Azure resource roles versus directory roles. ↩
- See cross-subscription network peering and Microsoft Customer Agreement billing. The networking and invoice examples describe capabilities, not an audit of your account. ↩
- Use Resource Manager guidance and the resource-group deletion process. Verify current support before moving or retiring actual resources. ↩
- Read tag support and limitations, policy effects and modify and remediation. ↩
- Lab references: az account, az group, ephemeral Cloud Shell, and the Activity log. Interfaces and permission requirements can change.
Place an Azure resource in the hierarchy, check inherited access, and explain how resource groups and tags help organise it.
Play the lesson above to stamp this class.
Next, how access is granted and revoked without handing over the keys.
Next · RBAC & Azure Policy →