Azure Fundamentals

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

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.

Syntax

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

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

Examples

// 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'
}

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.

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.
• 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.