Automation & ARM
Automate Azure with ARM/Bicep templates, the CLI, and Automation runbooks.
Everything in Azure goes through Azure Resource Manager (ARM) — the control plane that receives deployment requests. You can declare resources in ARM templates (JSON) or the friendlier Bicep language, which compiles to ARM. Declarative deployments are idempotent: re-deploying converges to the desired state.
For operational automation (scheduled tasks, remediation), Azure Automation runs runbooks (PowerShell/Python). And the Azure CLI / PowerShell Az module script ad-hoc and pipeline operations.
// main.bicep — declare a storage account
param location string = resourceGroup().location
resource sa 'Microsoft.Storage/storageAccounts@2023-01-01' = {
name: 'stdemo${uniqueString(resourceGroup().id)}'
location: location
sku: { name: 'Standard_LRS' }
kind: 'StorageV2'
}az deployment group what-if -g rg-demo -f main.bicep # preview changes
az deployment group create -g rg-demo -f main.bicep # apply- Explain what makes an ARM/Bicep deployment idempotent.
- Use
what-if(in words) to preview a deployment before applying. - Describe a use case for an Azure Automation runbook.
- Convert “create a storage account” from CLI commands to a declarative template idea.
Cheat Sheet▾
| Tool | Use |
|---|---|
| ARM templates | Declarative JSON deployments |
| Bicep | Readable DSL → compiles to ARM |
what-if | Preview deployment changes |
| Azure CLI / Az | Scripting + pipelines |
| Automation runbooks | Scheduled ops tasks |
| Idempotent | Re-deploy converges to desired state |
Common Interview Questions▾
What is Azure Resource Manager?
The control plane for Azure: every create/update/delete request goes through ARM, which handles authentication, authorization, and orchestrating the deployment.
Why use Bicep instead of ARM JSON?
Bicep is more concise and readable, supports modules and reuse, and offers better tooling — yet compiles to standard ARM templates, so there’s no runtime difference.