Azure Automation Runbooks

Azure Automation Runbooks are collections of PowerShell, PowerShell Workflow, Python, or graphical scripts that execute in the Azure Automation service. They automate processes such as VM start/stop, patching, backup, or responding to alerts. Runbooks run in a sandbox environment (for cloud jobs) or on a Hybrid Runbook Worker (for on-premises or other clouds). The service provides a secure, scalable execution environment with built-in authentication via Run As accounts or managed identities.

Manual administration does not scale. A single administrator can manage dozens of VMs, but hundreds or thousands require automation. Runbooks allow you to define, schedule, and monitor automated workflows without writing complex orchestration code from scratch. They are a key part of Azure's "automation first" philosophy, enabling DevOps practices like infrastructure as code and self-healing systems.

When a runbook is triggered, the Azure Automation service allocates a sandbox — a temporary, isolated environment with a specific set of modules and resources. The sandbox runs on Azure infrastructure and is recycled after the job completes. The runbook code executes within this sandbox, using the modules that are imported into the Automation Account (e.g., Az module, AzureRM module, or custom modules). Authentication is handled via a Run As account (a service principal with Contributor permissions by default) or a managed identity. The runbook can interact with Azure resources via cmdlets or REST APIs. Output, errors, and verbose logs are streamed to the job record, which you can view in the Azure portal or retrieve via PowerShell.

- Automation Account: The container for runbooks, modules, schedules, webhooks, and credentials. You must create one before using runbooks. - Runbook Types: - PowerShell: Standard PowerShell script (.ps1). Most common for simple automation. - PowerShell Workflow: Based on Windows Workflow Foundation (.ps1), supports checkpointing and parallel execution. Deprecated but still supported. - Python 2/3: Python scripts (.py). Useful for cross-platform or Linux-oriented automation. - Graphical: Drag-and-drop authoring in Azure portal. Generates PowerShell code behind the scenes. Good for beginners but limited for complex logic. - Execution Environments: - Azure Sandbox: Default for cloud jobs. Max 3 hours execution time. No persistent storage. Modules must be imported into the Automation Account. - Hybrid Runbook Worker: Runs on a Windows or Linux machine in your on-premises or other cloud environment. Can access local resources and run longer than 3 hours. Requires the worker to be installed and registered with the Automation Account. - Triggers: - Schedule: Start runbook at a specific time or recurring interval (e.g., every hour, daily at 2 AM). - Webhook: HTTP POST request triggers the runbook. Useful for external systems (e.g., ServiceNow, GitHub). - Azure Monitor Alert: Runbook responds to a metric or log alert. - Child Runbook: Called by another runbook. - Modules: PowerShell modules (e.g., Az, AzureRM, custom) must be imported into the Automation Account. The sandbox preloads some default modules, but you may need to import others. - Assets: Credentials, variables, connections, certificates used by runbooks. Stored encrypted in the Automation Account.

To create a runbook using Azure PowerShell:

New-AzAutomationRunbook -AutomationAccountName "myAutomationAccount" `
    -Name "Start-StopVMs" `
    -Type PowerShell `
    -ResourceGroupName "myRG" `
    -Description "Start or stop VMs based on tag"

To import a script:

Import-AzAutomationRunbook -AutomationAccountName "myAutomationAccount" `
    -Name "Start-StopVMs" `
    -Path ".\Start-StopVMs.ps1" `
    -ResourceGroupName "myRG" `
    -Type PowerShell `
    -Force

To publish a runbook (draft to published):

Publish-AzAutomationRunbook -AutomationAccountName "myAutomationAccount" `
    -Name "Start-StopVMs" `
    -ResourceGroupName "myRG"

To start a runbook:

Start-AzAutomationRunbook -AutomationAccountName "myAutomationAccount" `
    -Name "Start-StopVMs" `
    -ResourceGroupName "myRG"

To check job status:

Get-AzAutomationJob -AutomationAccountName "myAutomationAccount" `
    -ResourceGroupName "myRG" `
    -RunbookName "Start-StopVMs"

The sandbox has a maximum execution time of 3 hours (180 minutes) for cloud jobs. If a runbook exceeds this, it is suspended. To run longer, use a Hybrid Runbook Worker. The sandbox is shared among many jobs, so you must not rely on local state. Modules are loaded from the Automation Account's module gallery. The Run As account is created with a self-signed certificate that expires after one year; you must renew it manually or use a managed identity. Managed identities are recommended for newer deployments because they avoid certificate management.

Runbooks can use try/catch blocks in PowerShell. The $ErrorActionPreference variable controls behavior on non-terminating errors. Use -ErrorAction Stop to make cmdlets throw terminating errors. The Write-Output, Write-Error, Write-Warning, and Write-Verbose cmdlets write to the job stream. The job record stores all streams for up to 30 days by default (configurable).

A large enterprise runs hundreds of development and test VMs that are only needed during business hours. Manually starting and stopping them is error-prone and wastes money. The solution: Create two PowerShell runbooks — one to start VMs with a specific tag (e.g., 'AutoStart=true') and one to stop them. Schedule the start runbook at 7:00 AM and the stop runbook at 7:00 PM every weekday. The runbooks use the Run As account to authenticate and iterate through VMs in the subscription. In production, you must handle time zones, ensure the schedule is in UTC, and account for VMs that are already running or stopped. A common problem is that the Run As account certificate expires after one year, causing the runbook to fail. To avoid this, use a managed identity or set up a reminder to renew the certificate. Also, the 3-hour sandbox limit is not an issue here because the job finishes quickly. This scenario is a frequent exam topic: you must choose runbooks over other automation methods (like Logic Apps) because runbooks can run PowerShell cmdlets natively.

An organization uses Azure Policy to enforce that all storage accounts have HTTPS traffic only. If a non-compliant storage account is created, a remediation task can trigger a runbook to update the property. The runbook uses Azure Policy's 'DeployIfNotExists' effect to associate a runbook with the policy. The runbook is passed the resource ID of the non-compliant resource. In production, you must ensure the runbook has permissions to modify the resource — the Run As account must have the appropriate RBAC role. A common mistake is to forget that the runbook must be published and that the policy assignment must have a managed identity. The exam may ask you to identify the correct way to auto-remediate using runbooks, and the trap answer is to use an Azure Function instead, but runbooks are the native choice for Policy remediation.

A company has a hybrid environment with on-premises SQL Server databases that need nightly maintenance. Cloud-only runbooks cannot access on-premises resources. Solution: Install the Hybrid Runbook Worker on a Windows server in the on-premises network. Register the worker with the Automation Account. Create a PowerShell runbook that uses SQL Server modules to perform maintenance. The runbook runs on the worker, which has access to the local network. In production, you must ensure the worker has the necessary modules installed and that the Run As account has permissions to access the SQL Server. A common problem is network connectivity: the worker must be able to reach Azure over HTTPS (port 443). The exam sometimes tests that Hybrid Runbook Workers are required for on-premises resources and that they can run longer than 3 hours.