Azure Management and Deployment Tools: Portal, CLI, PowerShell, Arc and IaC

The Azure portal is a web-based graphical user interface (GUI) that you open in any modern browser to create, configure and manage almost every Azure resource. You sign in and point and click through menus, blades and forms instead of typing commands. It guides you step by step with defaults, validation and cost estimates, needs nothing installed, and is the natural place to learn, explore and make one-off changes.

The portal also lets you build dashboards: customizable views where you pin and arrange tiles such as a virtual machine's CPU chart, a storage account's status or a chart of recent spending. A dashboard can mix tiles for resources from different resource groups and services.

• Private or shared. A new dashboard is private to you. When you share it, it is published as an Azure resource in a resource group, so who can view or edit it is controlled by Azure role-based access control (RBAC) like any other resource. A role such as Contributor on that dashboard resource is enough to edit it.
• A view, not a control. A dashboard only displays information. It does not deploy, lock or restrict resources, and filtering a dashboard changes what you see, not what is allowed (rules on resources are Azure Policy, covered in the governance lesson).

The portal's trade-off is that clicking does not scale: repeating the same setup by hand across many resources is slow and easy to get wrong. That is where the command-line and code tools come in.

Azure Cloud Shell is a browser-based command-line environment for managing Azure, so you get a working shell without installing anything. You can open it from the Azure portal or go straight to shell.azure.com. It signs you in automatically with the account you are using, so you are ready to run commands as soon as it opens.

Cloud Shell offers two experiences, Bash and PowerShell. Both come with the Azure CLI and the Azure PowerShell modules preinstalled, plus common utilities and editors. Because it runs in the browser, it suits shared or locked-down machines and tablets where you cannot install software.

Two details matter:

• Storage is optional. Cloud Shell can start an ephemeral session with no storage account; anything you save is discarded when the session ends. If you want scripts and files kept between sessions, you configure Cloud Shell with a storage account, and it mounts an Azure file share that persists your files.
• It runs as you. Commands run with your own identity and permissions. Cloud Shell is not a separate administrator account, so it cannot do anything your role does not already allow.

Think of Cloud Shell as the place you run commands; the Azure CLI and Azure PowerShell are the command sets you type there or on your own computer.

The Azure CLI and Azure PowerShell are two command-line tools that do the same job, managing Azure resources by typing commands or running scripts, in different styles. Both are available in Cloud Shell, and both can be installed locally on Windows, macOS and Linux.

The cross-platform part of Azure PowerShell comes from PowerShell 7, the open-source, cross-platform PowerShell. A team that writes PowerShell and needs its scripts on Linux build servers can keep its syntax by running the Az module on PowerShell 7. Neither tool is better; the choice usually follows your background and the scripts you already have.

The portal, CLI and PowerShell overlap heavily: most everyday tasks can be done with any of them, so the difference is how you work, not what you can do. The portal is a graphical interface for clicking; the CLI and PowerShell are text interfaces for typing and scripting.

Choose the GUI for visual, occasional work, and a script when the same steps must run reliably and identically again and again. Switching tools never changes what you are allowed to do: all of them send their requests to Azure Resource Manager, which applies the same permission checks (see the IaC section).

Azure Arc extends Azure management and governance to resources that run outside Azure, in your own datacenter (on-premises), in other public clouds or at the edge, without moving them. Arc projects each connected resource into Azure as a resource you can see in the portal, so you manage everything from a single control plane.

Once connected, a resource can be placed in a resource group, tagged, governed with Azure Policy and given access through Azure RBAC, even though it keeps running where it is. Arc can connect:

• Servers: Windows and Linux physical or virtual machines anywhere, through the Azure Connected Machine agent.
• Kubernetes clusters running on-premises or in other clouds (Azure Arc-enabled Kubernetes).
• Data services running outside Azure, such as SQL Server on your own servers.
• Virtualization environments such as VMware vSphere and System Center Virtual Machine Manager (SCVMM).

Know its limits, too. Azure VMs and Azure PaaS services such as Azure SQL Database are already native Azure resources, so they never need Arc. And not everything outside Azure can be connected: network appliances such as routers and switches, records inside SaaS applications (for example Salesforce data) and Microsoft 365 mailboxes are not Arc resources.

The key distinction is manage in place (Arc) versus move or host in Azure (Migrate, Site Recovery, AKS).

Infrastructure as code (IaC) is the practice of defining infrastructure, such as virtual networks, virtual machines and storage, in text files kept in source control and deploying from those files instead of building by hand. Every deployment from the same file produces the same environment, which reduces mistakes and makes environments easy to recreate or copy.

There are two styles of writing those definitions:

Both styles automate and both end up as requests to Azure Resource Manager. The difference is that a template states the result, while a script lists the steps. Terraform, from HashiCorp, is a popular third-party declarative IaC tool that also works with Azure; it uses its own language and calls the Azure Resource Manager APIs through its Azure provider rather than producing ARM templates.

Azure Resource Manager (ARM) is the deployment and management service for Azure: every request to create, update or delete a resource passes through it, whether it comes from the portal, the CLI, PowerShell, an SDK or a template. Microsoft Entra ID authenticates the caller; Resource Manager then authorizes the request against Azure RBAC and enforces resource locks and Azure Policy (which can require or add tags) before sending it to the service. Because there is one layer, results are consistent whichever tool you use, and a user who is denied in the portal is also denied in Cloud Shell or a script.

ARM templates are JSON files that declare the resources you want Resource Manager to deploy. Bicep is a simpler language for the same job; Bicep files compile (transpile) to ARM template JSON before deployment, so anything an ARM template can deploy, Bicep can too, with far less syntax. Deploying a template or Bicep file gives you these benefits:

• Repeatable (idempotent). Deploying the same file again gives the same result. By default, resources that already match are left unchanged, missing ones are created, and nothing is duplicated, so redeploying an unchanged file to the same resource group restores a resource deleted by mistake.
• Orchestration. Resource Manager works out the order of dependent resources (a virtual network before the VMs that use it) and deploys independent resources in parallel, so you do not write wait logic yourself.
• Validation first. The template is checked before deployment starts, so many errors are caught before anything changes.
• Modular and reusable. Large deployments can be split into smaller files (linked templates or Bicep modules) and reused across projects.
• Tracked. Each deployment is recorded in the resource group's deployment history.

One thing a template deployment does not do by default is roll back. If a deployment fails partway, resources that were already deployed stay in place; rolling back to an earlier successful deployment happens only when you configure it.

Imagine a small company with some servers in its own office and new applications being built in Azure. It wants to manage everything consistently.

First, the on-premises server. An administrator installs the Azure Connected Machine agent and connects it through Azure Arc. The server now appears in the portal: it can be tagged, placed in a resource group and governed by Azure Policy, while the hardware stays in the office. Nothing was migrated; that would have been a job for Azure Migrate.

Next, the team needs a virtual network, a storage account and two VMs for a new project, and the same set again for a second project later. Rather than clicking through the portal or writing a script that creates each item in order, it writes a Bicep file declaring those resources. Azure Resource Manager validates it, creates the network before the VMs and builds independent resources in parallel. Later, someone deletes the storage account by mistake; redeploying the unchanged file recreates it and leaves everything else as it is. For a quick look at the server's health, the team simply opens a shared portal dashboard.

Most questions in this area describe a need and ask which tool fits, so anchor on each tool's core job:

• Web-based graphical interface, no install, no syntax: the Azure portal; an arranged at-a-glance view inside it is a dashboard.
• Command line in a browser, no install: Azure Cloud Shell; add a storage account if files must persist.
• Scripting and automation: Azure CLI (az commands) or Azure PowerShell (Verb-Noun cmdlets on PowerShell 7 across platforms).
• Manage and govern servers or clusters outside Azure where they run: Azure Arc, not Azure Migrate or AKS.
• Declare resources in files for repeatable deployments: infrastructure as code with ARM templates (JSON) or Bicep (compiles to ARM JSON).
• The service every request passes through and that authorizes it: Azure Resource Manager.

Keep the boundaries clear: controlling spend is cost management, Azure Policy and resource locks are governance, and watching performance is monitoring. Each has its own lesson.