Learn PowerShell - Azure Automation with PowerShell

#Introduction

In episode 26 you described machine state with DSC and enforced it automatically. But there's one scale untouched: the cloud. As your infrastructure grows, creating, changing, and destroying resources can no longer be done by hand through the portal — it must be done through code. And in Azure, PowerShell is one of the primary languages of that code.

Episode 27 brings PowerShell to Azure comprehensively: the Az module as the replacement for AzureRM, authentication with Connect-AzAccount, subscription and resource group management, VM, storage, and network operations, identity management via Microsoft Graph, and Azure Automation — the platform for runbooks, schedules, variables, credentials, and hybrid workers running centralized automation.

#Installing the Az Module

The Az module is the official cmdlet collection for managing Azure. It installs from the PowerShell Gallery:

Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force
Get-Module -ListAvailable Az

Install-Module fetches the Az module and its dependencies. It's a large module — for constrained environments, install per-service such as Az.Compute or Az.Storage. The principle is the same as AWS.Tools in episode 28: bring the modules you use, not the whole shelf.

#Connect-AzAccount and Subscriptions

Every operation starts with authentication:

Connect-AzAccount
Get-AzSubscription
Set-AzContext -Subscription "my-subscription-id"

Connect-AzAccount opens the login flow; Get-AzSubscription shows accessible subscriptions; Set-AzContext locks the session to one subscription — every subsequent Az.* cmdlet works there. In CI/CD, login typically uses a service principal or managed identity, not an interactive account — the same principle as non-interactive credentials in earlier episodes: code never stores secrets.

#Resource Groups

A resource group is the logical container of all Azure resources — imagine it as a folder where all assets of one application are collected. Its basic operations:

New-AzResourceGroup -Name "rg-prod" -Location "southeastasia"
Get-AzResourceGroup -Name "rg-prod"

A resource group gives two important things: cost boundaries (tag all resources inside for reporting) and lifespan boundaries (delete one resource group = delete all its contents). A good habit: name with type and environment prefixes — rg-prod, rg-staging — so your own resource group list reads without documentation.

#VM Management

An Azure VM's lifecycle is controlled by cmdlets whose patterns you've known since the series' early episodes — New, Get, Start, Stop, Remove:

New-AzVM -ResourceGroupName "rg-prod" -Name "web-01" `
    -Location "southeastasia" -Image "Ubuntu2204" `
    -Size "Standard_B1s" -Credential $cred
 
Start-AzVM -ResourceGroupName "rg-prod" -Name "web-01"
Stop-AzVM -ResourceGroupName "rg-prod" -Name "web-01" -Force
Get-AzVM -ResourceGroupName "rg-prod" -Name "web-01"
Remove-AzVM -ResourceGroupName "rg-prod" -Name "web-01"

New-AzVM accepts many parameters — image, size, credentials, network — and can be piped from one cmdlet to another. This object-based automation is what makes operating dozens of VMs a single foreach loop:

Get-AzVM -ResourceGroupName "rg-prod" |
    Start-AzVM

#Storage and Networking

Storage and networking are two infrastructure backbones often created alongside VMs:

New-AzStorageAccount -ResourceGroupName "rg-prod" `
    -Name "storageprod123" -Location "southeastasia" `
    -SkuName "Standard_LRS"
 
Get-AzStorageAccount -ResourceGroupName "rg-prod"

New-AzVirtualNetwork -ResourceGroupName "rg-prod" `
    -Name "vnet-prod" -AddressPrefix "10.0.0.0/16" `
    -Location "southeastasia"
 
Add-AzVirtualNetworkSubnetConfig -Name "subnet-app" `
    -AddressPrefix "10.0.1.0/24" -VirtualNetwork $vnet
 
New-AzPublicIpAddress -ResourceGroupName "rg-prod" `
    -Name "pip-web-01" -Location "southeastasia" `
    -Sku "Standard" -AllocationMethod "Static"

The same pattern repeats everywhere: creating a resource is one cmdlet with descriptive parameters. Once you memorize one cycle — create a resource group, create a resource, read, change, delete — all of Azure opens up, because almost every service follows the same rhythm.

#Identity with Microsoft Graph

Azure identity management — users, groups, applications — has moved from the old AzureAD module to Microsoft Graph PowerShell. The Microsoft.Graph module wraps the Graph API (now the only official way to manage Microsoft identity):

Install-Module -Name Microsoft.Graph -Scope CurrentUser -Force
Connect-MgGraph -Scopes "User.Read.All", "Group.Read.All"

Connect-MgGraph requests permissions (scopes) explicitly — a pattern similar to the least-privilege principle you've held since the early episodes. Once connected:

Get-MgUser -Top 10 | Select-Object DisplayName, UserPrincipalName
New-MgUser -UserPrincipalName "budianto@contoso.com" `
    -DisplayName "Budianto" -PasswordProfile @{ ForceChangePasswordNextSignIn = $true }
 
Get-MgGroup -Filter "displayName eq 'IT Operations'"

Get-MgUser, New-MgUser, Get-MgGroup follow the same cmdlet patterns. Identity data now lives behind a single API in the module — and because everything is objects, Get-MgUser output can be piped straight to Export-Csv for reports or into a loop for bulk operations.

#Azure Automation: Runbooks

Azure Automation is the service for running automation in Azure centrally and on schedule. Its work unit is called a runbook — a PowerShell script running in the cloud. A runbook contains an ordinary script, then is triggered by a schedule or event. Example of a simple runbook that stops VMs outside working hours:

Connect-AzAccount -Identity
 
$rgName = Get-AutomationVariable -Name "ResourceGroupName"
Get-AzVM -ResourceGroupName $rgName |
    Where-Object { $_.Tags.Hours -eq "office" } |
    Stop-AzVM -Force -NoWait

Note three typical runbook elements: Connect-AzAccount -Identity uses a managed identity without storing credentials; Get-AutomationVariable reads variables stored in the Automation account (so configuration stays separate from code); and the script uses the already-familiar Az cmdlets. The same runbook can be scheduled with New-AzAutomationSchedule and linked to run every night.

Credentials are stored encrypted in the Automation account and read with Get-AutomationPSCredential — scripts never touch raw secrets. Hybrid Workers extend runbook reach: they're agents installed on machines outside Azure (on-premises or other clouds), so a single Automation account can run scripts anywhere — in Azure, on-premises, and across your own networks, all from one control panel.

#Conclusion

In this episode 27 you've taken control of Azure with PowerShell: installing the Az module and authenticating with Connect-AzAccount; selecting subscriptions with Set-AzContext; managing resource groups as cost and lifecycle containers; the VM lifecycle with New-AzVM, Start-AzVM, and Stop-AzVM; provisioning storage accounts and virtual networks; managing user and group identity via Microsoft Graph with Connect-MgGraph, Get-MgUser, and Get-MgGroup; and Azure Automation with runbooks, schedules, variables, credentials, and hybrid workers.

Key takeaways:

• Connect-AzAccount once, then all of Azure becomes PowerShell objects.
• A resource group is a lifecycle and cost container — use consistent naming.
• Identity is now managed via Microsoft Graph, not the old module.
• Runbooks use managed identity, variables, and credentials — secret-free code.
• Hybrid workers run one automation from Azure down to local machines.

One cloud done — and the patterns you've mastered turn out to be Azure's alone. In the next episode, episode 28, we open a wider map: AWS & GCP Automation — the AWS.Tools module for EC2, S3, and IAM, the gcloud Cloud SDK for Compute Engine, and when to choose a PowerShell module, CLI, or SDK. See you there!