Two separate questions this lesson answers: which interface do you use to reach into Azure day to day, and which method do you use to actually stand resources up. The exam likes to test the second one as a mindset shift — telling Azure exactly what steps to run, versus telling it what the end state should look like.
One engineer writes a script that runs, in order: create a resource group, then create a VNet inside it, then create a VM inside that. Another engineer writes a file that just states "I want one resource group, one VNet, one VM, configured like this" and hands it to Azure to figure out. Which one is declarative, and which is imperative?
| Interface | Is |
|---|---|
| Azure portal | Web-based graphical UI, cross-platform, customizable dashboards — the default for exploring and one-off changes |
| Azure Cloud Shell | Browser-based command line, your choice of Bash or PowerShell, backed by a persistent file share — no local install needed |
| Azure CLI | Cross-platform command-line tool you install locally, scriptable, command syntax (az ...) |
| Azure PowerShell | A PowerShell module for Azure, cmdlet syntax (New-AzVM, Get-AzResourceGroup), same PowerShell you already know from Windows admin work |
| Azure mobile app | Monitor resource health, receive alerts, and even restart/stop/scale resources or run CLI/PowerShell commands from your phone |
These are all just different doors into the same Azure Resource Manager — none of them is more "real" than another, they're interchangeable based on preference and context.
Azure Arc extends that same management surface to resources outside Azure — on-premises servers, other clouds (AWS, GCP), even Kubernetes clusters anywhere. It projects those non-Azure resources into Azure Resource Manager, so tools you already know — Azure Policy, tags, RBAC — apply to them the same way they'd apply to a native Azure VM, from one control plane.
ARM (Azure Resource Manager) templates are JSON files that declare the resources you want and their configuration — not the steps to create them. Azure's Resource Manager reads the template and figures out the sequence itself. This makes deployments repeatable, version-controllable, and idempotent: redeploying the same template against an environment that already matches it changes nothing.
Declarative — you state the desired end result; the platform works out how to get there. ARM templates (and Bicep, which compiles down to ARM JSON) are declarative.
Imperative — you specify the exact sequence of commands to run, step by step. A CLI or PowerShell script that creates a resource group, then a VNet, then a VM, in that order, is imperative — even though CLI/PowerShell can also just be a wrapper for one-off calls.
Anchor: declarative says "what." Imperative says "how, in order."
Calibration answer: the engineer with the ordered script (create group, then VNet, then VM) is imperative. The engineer with the "I want this end state" file is declarative — that's an ARM template (or Bicep).