Cloud Techby Victor
DevOpsBeginner

Azure Fundamentals

How Azure management groups, subscriptions, resource groups, and Resource Manager fit together, with practical deployment troubleshooting.

Reviewed Jul 28, 2026Victor Nwoke7 min read

Written and maintained by Victor Nwoke. Technical behavior is reviewed against the primary references listed on this page.

On this page

Overview

Azure organizes everything you create into a hierarchy, management groups, subscriptions, resource groups, and individual resources, and understanding that hierarchy matters more than understanding any single resource type, because it's where access control, policy enforcement, and cost management actually happen. Every operation, regardless of whether it comes from the Portal, CLI, or an infrastructure-as-code tool, goes through Azure Resource Manager (ARM), which is what makes that hierarchy consistently enforceable no matter how a change was made.

Quick Reference

LevelPurposeDeleting it
Management groupGovernance (policy, RBAC) across multiple subscriptionsDoesn't delete subscriptions, just removes grouping
SubscriptionBilling and access-management boundaryRequires explicit cancellation, resources first
Resource groupLogical container for resources sharing a lifecycleDeletes every resource inside it
ResourceAn individual manageable object (VM, storage account...)Deletes just that resource

The commands below are grouped by resource type, not an exhaustive reference (see the official Azure CLI reference for every flag), but the set that covers nearly all day-to-day az CLI work.

CommandDescriptionCopy
az loginSign in interactively, via the browser.
az account showShow the currently active subscription.
az account listList every subscription available to the signed-in account.
az account set --subscription <id>Switch the active subscription for subsequent commands.

Syntax

bash
az group create --name rg-app-prod --location eastus

az deployment group what-if \
  --resource-group rg-app-prod \
  --template-file main.bicep

az deployment group create \
  --resource-group rg-app-prod \
  --template-file main.bicep

Examples

bicep
// main.bicep, declarative resource definition, deployed
// through Azure Resource Manager like every other Azure change.
resource storage 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'appuploadsprod'
  location: resourceGroup().location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}

Deleting a resource group deletes everything in it

There's no confirmation beyond the initial prompt, and it cascades to every resource the group contains. Treat resource-group deletion with the same care as a destructive database operation.

Troubleshooting Azure Operations

I start with context, then move from Resource Manager to the resource itself:

  1. Subscription and tenant: run az account show and compare the subscription and tenant IDs with the resource ID. A valid sign-in to the wrong subscription commonly appears as ResourceNotFound.
  2. Template validation: run az deployment group validate and what-if before deployment. Resolve schema, parameter, policy, quota, and permission failures before retrying.
  3. Deployment operations: for a failed deployment, list its operations and inspect the innermost error code, message, target resource, and correlation ID. The top-level DeploymentFailed message is only a wrapper.
  4. Control plane: query the Azure Activity Log for create, update, delete, policy, RBAC, and service-health events. Activity Log covers subscription-level control-plane events; it is not an application's stdout or a storage data-access log.
  5. Data plane and runtime: move to the service's resource logs, metrics, health checks, and dependency telemetry. Diagnostic settings must usually be configured to route resource logs to a destination such as Log Analytics.

For storage data operations, use --auth-mode login and confirm that the signed-in principal has a Blob Data role at the correct scope. Without that option, some Azure CLI storage commands may attempt to retrieve and use an account key, hiding a missing data-plane RBAC assignment.

Visual Diagram

Common Mistakes

  • Putting unrelated resources with different lifecycles into the same resource group, making it impossible to delete or manage one without affecting the others.
  • Managing access at the individual-resource level instead of at the resource-group or subscription level, creating an unmanageable sprawl of one-off role assignments.
  • Ignoring management groups entirely and configuring policy per-subscription, which doesn't scale past a handful of subscriptions and drifts out of consistency over time.
  • Assuming the Portal, CLI, and ARM templates behave differently; they're all just different clients of the same Resource Manager API and produce identical results for identical input.
  • Treating the top-level DeploymentFailed message as the root cause instead of inspecting the failed deployment operation and its inner error.
  • Expecting the Activity Log to contain application or data-plane logs, even though resource logs require their own diagnostic settings.

Performance

  • ARM deployment speed scales with the number of resources and their interdependencies in a single deployment, very large templates benefit from being split into modules deployed independently where dependencies allow.
  • Resource group and subscription structure has no runtime performance impact on the resources themselves; it's purely a management/governance concern, not a latency one.

Best Practices

  • Group resources by lifecycle, not by resource type, everything in a resource group should reasonably be created and deleted together.
  • I use management groups and Azure Policy to enforce organization-wide rules once, rather than per-subscription.
  • Assign RBAC roles at the resource-group or subscription level whenever the access genuinely applies that broadly, instead of per-resource.
  • Adopt a consistent subscription strategy (e.g., separate subscriptions per environment or business unit) before resource sprawl makes retrofitting one expensive.
  • Preview Bicep changes with what-if, preserve deployment names and correlation IDs in CI, and inspect deployment operations before retrying a failed rollout.
  • Continue into Azure Compute, Azure Networking, Azure Storage, Azure Monitoring, and Microsoft Entra ID for service-specific depth.

Interview questions

What is the difference between a resource group and a subscription in Azure?
A subscription is a billing and access-management boundary; it's tied to an agreement with Microsoft, has its own spending limits and quotas, and is typically the unit organizations use to separate environments (production vs. non-production) or business units. A resource group is a logical container inside a subscription that groups related resources (a VM, its disks, its network interface) that share the same lifecycle, created and deleted together. Deleting a resource group deletes everything in it, which makes resource groups the practical unit of "this is one deployable thing," while subscriptions are the practical unit of "this is one billing and governance boundary."
What is Azure Resource Manager (ARM) and why does every Azure operation go through it?
ARM is the deployment and management layer that every Azure operation, whether from the Portal, CLI, PowerShell, or an ARM/Bicep template, ultimately goes through. It provides a consistent API surface, handles authentication and authorization checks against Azure RBAC, and is what enables declarative deployment (submit a template describing desired resources, ARM figures out what to create/update). Because every path converges on ARM, access control and activity logging are consistent regardless of which tool was used to make a change.
How do management groups extend governance above the subscription level?
Management groups let an organization apply policies (via Azure Policy) and role assignments (via Azure RBAC) across multiple subscriptions at once, instead of configuring each subscription independently. They form a hierarchy above subscriptions, a root management group can contain child management groups (e.g., by department or environment type), each containing multiple subscriptions, so a single policy assignment at the right level of that hierarchy can enforce a rule (like "no public IP addresses" or "must use approved regions") across every subscription beneath it.

References

Continue learning

ShareXLinkedInReddit
Was this page helpful?
Suggest an improvement