Microsoft Azure — Azure CLI & PowerShell

Clicking through the Azure portal works for a one-off setup. For production, you need automation. Azure CLI and PowerShell are the two primary command-line tools that let you script every aspect of Azure management — from provisioning VMs to configuring network security groups. This article covers both tools in depth: installation, core commands, scripting patterns, error handling, and production automation workflows.

Installing Azure CLI and PowerShell Az Module

Azure CLI can be installed on macOS (brew install azure-cli), Windows (MSI installer), and Linux (apt/dnf). PowerShell Az module installs via Install-Module Az from the PowerShell Gallery. Both tools use Azure AD for authentication. Run 'az login' or 'Connect-AzAccount' to authenticate interactively. For automation, use service principals with certificate or secret-based authentication.

# Install Azure CLI on macOS
brew update && brew install azure-cli

# Authenticate
az login

# Show current subscription
az account show

# Install PowerShell Az module
Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force

Azure CLI Core Commands: Resource Management

Azure CLI organizes commands by Azure resource type. Key command groups include: 'az group' for resource groups, 'az vm' for virtual machines, 'az network' for networking, 'az storage' for storage accounts, and 'az aks' for Kubernetes. Commands follow a consistent pattern: 'az [parameters]'. Use '--output table' for human-readable output, '--output json' for scripting. The '--query' parameter uses JMESPath for filtering.

# Create a resource group
az group create --name my-rg --location eastus

# Create a VM with default settings
az vm create --resource-group my-rg --name my-vm --image UbuntuLTS --generate-ssh-keys

# List all VMs in table format
az vm list --output table

# Query specific fields
az vm list --query "[].{Name:name, Location:location, Size:hardwareProfile.vmSize}" --output table

PowerShell Az Module: Working with Resources

The Az module follows PowerShell conventions with Get-/New-/Remove-/Set- verb-noun patterns. Common cmdlets: 'Get-AzResourceGroup', 'New-AzVM', 'Remove-AzResource'. PowerShell leverages the pipeline for chaining commands. The Az module supports what-if (-WhatIf) and confirm (-Confirm) flags for safe execution. Use 'Set-AzContext' to switch between subscriptions.

# Authenticate and set subscription
Connect-AzAccount
Set-AzContext -SubscriptionId "your-sub-id"

# Create a resource group
New-AzResourceGroup -Name "my-rg" -Location "eastus"

# Get all VMs in a resource group
Get-AzVM -ResourceGroupName "my-rg" | Format-Table Name, Location, VmSize

# Remove a resource (with confirmation)
Remove-AzResourceGroup -Name "my-rg" -Force -AsJob

Service Principal Authentication for Automation

For CI/CD pipelines and unattended scripts, use service principal authentication. Create a service principal with 'az ad sp create-for-rbac' or 'New-AzADServicePrincipal'. Assign RBAC roles at the desired scope. Store credentials in Azure Key Vault or environment variables. For GitHub Actions, use 'azure/login' action with a service principal secret. For Azure DevOps, use Azure Resource Manager service connection.

# Create a service principal with Contributor role
az ad sp create-for-rbac --name my-sp --role Contributor --scopes /subscriptions/your-sub-id

# Output:
{
  "appId": "client-id",
  "displayName": "my-sp",
  "password": "client-secret",
  "tenant": "tenant-id"
}

# Login with service principal (non-interactive)
az login --service-principal -u client-id -p client-secret --tenant tenant-id

# For PowerShell:
$sp = New-AzADServicePrincipal -DisplayName "my-sp" -Role Contributor
$sp.PasswordCredentials.SecretText | ConvertFrom-SecureString

Scripting Patterns: Idempotent Automation

Production scripts must be idempotent — running them multiple times produces the same result. Check resource existence before creating: 'az resource show --name my-resource' and only create if not found. Use '--no-wait' for long-running operations and poll with 'az resource wait'. Use '--only-show-errors' for cleaner output. PowerShell native error handling with try/catch/finally and $ErrorActionPreference='Stop' ensures scripts fail fast on errors.

#!/bin/bash
set -euo pipefail

RG_NAME="my-rg"
LOCATION="eastus"

# Check and create resource group if needed
if ! az group exists --name "$RG_NAME"; then
    az group create --name "$RG_NAME" --location "$LOCATION" --only-show-errors
fi

# Conditional VM creation
VM_EXISTS=$(az vm list --resource-group "$RG_NAME" --query "[?name=='my-vm'] | length(@)" --output tsv)
if [ "$VM_EXISTS" -eq 0 ]; then
    az vm create --resource-group "$RG_NAME" --name my-vm \
        --image UbuntuLTS --generate-ssh-keys --no-wait
fi

Error Handling and Troubleshooting

Azure CLI returns exit code 0 for success, non-zero for failure. Set 'set -e' in bash scripts to stop on first error. Use 'az account show --output tsv --query id || az login' to auto-reauthenticate. For PowerShell, set '$ErrorActionPreference = "Stop"' and implement retry logic with Start-Sleep for throttling (HTTP 429). Use '--debug' flag on CLI commands for verbose output. Enable resource logs and use 'az monitor diagnostic-settings' to capture management operations.

$ErrorActionPreference = "Stop"
$maxRetries = 3
$retryDelay = 10 # seconds

for ($i = 0; $i -lt $maxRetries; $i++) {
    try {
        New-AzResourceGroup -Name "my-rg" -Location "eastus" -ErrorAction Stop
        Write-Host "Resource group created successfully"
        break
    }
    catch {
        if ($i -eq $maxRetries - 1) {
            throw "Failed after $maxRetries attempts: $_"
        }
        Write-Warning "Attempt $($i+1) failed. Retrying in ${retryDelay}s..."
        Start-Sleep -Seconds $retryDelay
    }
}

Azure CLI vs PowerShell: When to Use Each

Azure CLI excels at quick operations, Linux/macOS workflows, and simple scripting. PowerShell Az module shines in complex automation, Windows-native environments, and when working with .NET libraries. For CI/CD pipelines, both work equally well. Many teams use CLI for ad-hoc operations and PowerShell for scheduled automation runbooks. The choice often depends on team expertise — use what your team knows best while maintaining consistent patterns.

Azure CLI Extensions: Dynamic Install and Extension Management

Azure CLI extensions provide access to experimental, preview, and specialized commands not included in the base CLI. Extensions are Python wheels that run as CLI commands. Use az extension list-available to see Microsoft-maintained extensions. Install by name with az extension add --name . Starting with CLI 2.12.0, dynamic install is enabled by default -- when you run an unrecognized command, the CLI auto-installs the required extension. Control this with az config set extension.use_dynamic_install=yes_without_prompt. Key extensions for Azure management include: azure-devops (Azure Boards, Repos, Pipelines from CLI), managementpartner (Azure Partner management), resource-graph (Azure Resource Graph queries), and account (subscription management). Update extensions with az extension update --name . List installed extensions with az extension list. For production scripts, pin extension versions to avoid unexpected breaking changes from auto-updates. Extensions are stored in $HOME/.azure/cliextensions on Linux/macOS. For CI/CD pipelines with restricted outbound access, pre-install required extensions in the agent image. Note that extensions are updated independently from the CLI -- always test extension upgrades in a non-production environment.

# List available extensions
az extension list-available --output table

# Install Azure DevOps extension
az extension add --name azure-devops --allow-preview false

# Configure Azure DevOps CLI
az devops configure --defaults organization=https://dev.azure.com/myorg project=MyProject

# Use it: list pipelines
az pipelines list --output table

# Update an extension
az extension update --name azure-devops

# List installed
az extension list --query "[].{Name:name, Version:version}" --output table

Deploying ARM and Bicep with CLI and PowerShell

Both Azure CLI and PowerShell Az can deploy infrastructure-as-code templates. For CLI, use az deployment group create --template-file main.bicep for resource groups or az deployment sub create for subscriptions. Preview changes with az deployment group what-if. Pass parameters inline (--parameters storageName=mystorage) or via parameter files (--parameters @params.json). For PowerShell, use New-AzResourceGroupDeployment -TemplateFile main.bicep. Bicep files are compiled to ARM JSON automatically during deployment. For CI/CD, store parameter files per environment under version control. Use --no-wait for long-running deployments and poll with az deployment group show. PowerShell supports -WhatIf and -Confirm for safe execution. For subscription-scoped deployments (policy definitions, role assignments), use az deployment sub create. Manage resource lifecycles with deployment stacks: az stack group create to create, az stack group list to detect drift, and az stack group delete --detach-all for cleanup. Always use --output tsv in CLI scripts for machine-parseable results. For PowerShell, use Select-Object -Property to extract specific values.

#!/bin/bash
set -euo pipefail

# What-if preview
az deployment group what-if \
  --resource-group my-rg \
  --template-file main.bicep \
  --parameters env=prod sku=Standard_GRS

# Deploy
az deployment group create \
  --resource-group my-rg \
  --template-file main.bicep \
  --parameters env=prod sku=Standard_GRS

# Get output
storageEndpoint=$(az deployment group show \
  --resource-group my-rg \
  --name main \
  --query properties.outputs.storageEndpoint.value \
  --output tsv)
echo "Storage endpoint: $storageEndpoint"

Advanced PowerShell: Parallel Execution, Modules, and Error Handling Patterns

PowerShell Az supports advanced patterns beyond simple scripts. Use ForEach-Object -Parallel (PowerShell 7+) to run Azure operations concurrently -- critical for bulk operations like starting 50 VMs simultaneously. Create custom PowerShell modules to wrap common Azure management tasks into reusable functions with proper help, parameter validation, and pipeline support. Use #Requires -Modules Az to enforce module availability. For error handling, go beyond try/catch: use trap for global error handling, -ErrorVariable to capture errors without stopping, and $PSItem for rich error inspection. Implement retry with exponential backoff using a custom function or the Microsoft.PowerShell.Utility\Restart-Computer pattern. Use ShouldProcess in advanced functions to support -WhatIf and -Confirm. For long-running operations, use Register-AzResourceProvider and wait with a polling loop. For state management, persist data to Azure Table Storage or a JSON file. Use PowerShell classes for complex state objects. Always validate parameters with ValidateSet, ValidateRange, and ValidateScript attributes. For performance, use -NoWait on Azure cmdlets and poll asynchronously.

#Requires -Modules Az.Compute, Az.Resources

function Start-MyVMs {
    [CmdletBinding(SupportsShouldProcess)]
    param(
        [Parameter(Mandatory, ValueFromPipeline)]
        [string[]]$VMName,
        [string]$ResourceGroupName = "rg-prod"
    )
    process {
        if ($PSCmdlet.ShouldProcess($VMName, "Start VM")) {
            $VMName | ForEach-Object -Parallel {
                $vm = $_
                Write-Output "Starting $vm..."
                Start-AzVM -Name $vm -ResourceGroupName $using:ResourceGroupName -NoWait
            } -ThrottleLimit 10
        }
    }
}

"web-01", "web-02", "web-03" | Start-MyVMs -WhatIf