The Az Module and Authentication
The Az module is Microsoft's current cross-platform PowerShell module for managing Azure resources, replacing the older, Windows-only AzureRM module which reached end of life in 2024. Connect-AzAccount authenticates a session interactively via browser, or non-interactively using a service principal with -ServicePrincipal -Credential for automation scenarios like CI/CD pipelines. Because a single Azure tenant can contain many subscriptions, Get-AzSubscription and Set-AzContext are used to list and switch the active subscription context that subsequent cmdlets operate against.
Cricket analogy: Connect-AzAccount is like a player badge-scanning into a stadium's central accreditation system before they can access any specific ground, and Set-AzContext is like selecting which ground's facilities they're currently authorized to use.
# Interactive login
Connect-AzAccount
# Non-interactive service principal login for automation
$securePwd = ConvertTo-SecureString $env:SP_SECRET -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential($env:SP_APP_ID, $securePwd)
Connect-AzAccount -ServicePrincipal -Credential $cred -Tenant $env:AZ_TENANT_ID
# List and switch subscription context
Get-AzSubscription | Format-Table Name, Id, State
Set-AzContext -SubscriptionId '11111111-2222-3333-4444-555555555555'Provisioning Resources
Az cmdlets follow a consistent Verb-AzNoun pattern per service: New-AzResourceGroup creates a logical container, New-AzVM provisions a virtual machine, New-AzStorageAccount creates storage, and so on, with hundreds of resource-specific cmdlets across Az submodules (Az.Compute, Az.Storage, Az.Network). For anything beyond trivial single-resource scripts, most teams instead call New-AzResourceGroupDeployment to deploy a Bicep or ARM template, since templates capture complex multi-resource dependency graphs more reliably than sequential imperative cmdlet calls, while PowerShell orchestrates the deployment pipeline and post-deployment configuration around it.
Cricket analogy: Calling individual New-Az* cmdlets one resource at a time is like setting up a match ground piece by piece manually, whereas a Bicep template deployment is like handing the entire ground-readiness checklist to a certified curator who executes it as one coordinated job.
New-AzResourceGroupDeployment supports -WhatIf, which performs a what-if analysis against ARM/Bicep templates showing exactly which resources would be created, modified, or deleted before you commit to the deployment.
New-AzResourceGroup -Name 'rg-webapp-prod' -Location 'eastus'
New-AzResourceGroupDeployment -ResourceGroupName 'rg-webapp-prod' `
-TemplateFile .\main.bicep `
-TemplateParameterFile .\main.parameters.json `
-WhatIfAutomating with Runbooks and Scheduled Tasks
Azure Automation Runbooks let you host and schedule Az PowerShell scripts in the cloud without maintaining a dedicated VM, authenticating via a managed identity assigned to the Automation Account rather than embedding credentials. Common patterns include nightly scripts that stop dev/test VMs to save cost using Stop-AzVM, scheduled certificate rotation, or periodic compliance scans that use Get-AzPolicyState to check resources against assigned Azure Policy definitions. Runbooks can be triggered on a schedule, by a webhook, or in response to an Azure Monitor alert action group, making PowerShell a first-class citizen in event-driven cloud operations.
Cricket analogy: An Azure Runbook auto-stopping dev/test VMs overnight is like a stadium's automated system switching off floodlights every night after the last match, without needing a groundskeeper to manually flip the switch.
Runbooks authenticating via a system-assigned managed identity require the identity to be explicitly granted RBAC roles (e.g. Contributor) on the target subscription or resource group — a common source of 'Authorization failed' errors is forgetting this role assignment step.
- The Az module is the current cross-platform Azure PowerShell module; AzureRM is retired.
- Connect-AzAccount authenticates interactively or via a service principal for automation scenarios.
- Get-AzSubscription and Set-AzContext manage which subscription subsequent cmdlets target.
- Individual New-Az* cmdlets suit simple single-resource tasks; Bicep/ARM via New-AzResourceGroupDeployment suits complex multi-resource deployments.
- -WhatIf on deployment cmdlets previews resource changes before committing them.
- Azure Automation Runbooks host and schedule Az scripts in the cloud, authenticating via managed identity.
- Managed identities used by Runbooks need explicit RBAC role assignments to act on target resources.
Practice what you learned
1. Which module is the current, actively supported PowerShell module for managing Azure resources?
2. Which cmdlet is used to switch the active subscription context in a multi-subscription tenant?
3. Why do teams often prefer Bicep/ARM templates over sequential New-Az* cmdlets for complex deployments?
4. What does adding -WhatIf to New-AzResourceGroupDeployment do?
5. What is a common cause of 'Authorization failed' errors in Azure Automation Runbooks using managed identity?
Was this page helpful?
You May Also Like
Modules and the PowerShell Gallery
Learn how PowerShell packages reusable code into modules and how to discover, install, and publish them via the PowerShell Gallery.
PowerShell and REST APIs
Use Invoke-RestMethod and Invoke-WebRequest to consume, authenticate against, and automate workflows around HTTP REST APIs.
Desired State Configuration (DSC)
Learn how PowerShell DSC declaratively defines and enforces the configuration state of servers and services.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics