Sign in, organize everything into resource groups, and control who can do what with Microsoft Entra ID and role-based access control (RBAC) — including service principals and managed identities for apps.
A "subscription" is the billing-and-boundary container for everything you build in Azure. Why first: every command runs against one subscription, so you sign in and choose it before doing anything else. The az CLI is how you drive Azure from a terminal.
Sign in (opens a browser) and list the subscriptions you can use
az loginSee which subscription is currently active
az account show --output tableSwitch the active subscription if you have more than one
az account set --subscription "My Subscription"A resource group is a named container that holds related resources (VMs, databases, networks) and lets you manage them as a unit. Why it matters: every resource belongs to exactly one group, and deleting the group deletes everything in it — the easiest way to clean up an experiment.
Create a resource group in a region (location)
az group create --name learn-rg --location eastusList your resource groups
az group list --output tableWhen you're done experimenting, this deletes the group AND everything in it az group delete --name learn-rg --yes
Entra ID (formerly Azure Active Directory) is Azure's identity service — the directory of users, groups, and apps. Why: signing in and being granted permissions both flow through Entra ID. It answers "who are you," while RBAC (next) answers "what may you do."
Who am I signed in as?
az ad signed-in-user show --query '{name:displayName, upn:userPrincipalName}'List users in the directory
az ad user list --query '[].{name:displayName, upn:userPrincipalName}' \
--output tableAzure controls access with RBAC: you assign a role (a bundle of permissions like "Reader" or "Contributor") to an identity, at a scope (a subscription, a resource group, or one resource). Why scope matters: granting "Contributor" on one resource group lets someone manage just that group — least privilege in action.
List the built-in roles available
az role definition list --query '[].roleName' --output tsv | sort | headGrant a user the Reader role, scoped to just one resource group
az role assignment create \
--assignee user@example.com \
--role "Reader" \
--resource-group learn-rgA service principal is a non-human identity an app, CI pipeline, or script uses to sign in to Azure. Why: you never put a person's password in automation — you create a service principal with exactly the roles it needs. It is Azure's equivalent of an app credential.
Create a service principal with Contributor on one resource group
az ad sp create-for-rbac \
--name my-ci-deployer \
--role Contributor \
--scopes /subscriptions/SUB_ID/resourceGroups/learn-rgThe output's appId + password + tenant are the credentials your pipeline uses with: az login --service-principal ...
A managed identity is an automatic identity Azure gives a resource (a VM, a Function) so it can call other Azure services with no secrets in code. Why: like AWS IAM roles, the credentials are issued and rotated by Azure behind the scenes — the single biggest security win. You enable it, then grant it roles.
Turn on a system-assigned managed identity for a VM
az vm identity assign --name my-vm --resource-group learn-rgGrant that identity read access to a storage account
PRINCIPAL_ID=$(az vm show --name my-vm --resource-group learn-rg \
--query 'identity.principalId' --output tsv)az role assignment create --assignee $PRINCIPAL_ID \
--role "Storage Blob Data Reader" \
--scope /subscriptions/SUB_ID/resourceGroups/learn-rg