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 instead of typing commands you point and click your way through menus, blades, and forms. It is the friendliest place to start because it guides you step by step and shows helpful defaults, validation, and cost estimates as you go.

Beyond creating resources, the portal lets you build dashboards. A dashboard is a customizable home screen where you pin the tiles you care about, such as a virtual machine's health, a storage account's usage, or a chart of recent spending. This gives you an at-a-glance view of the resources that matter to you.

The portal is ideal for learning, exploring, and one-off changes, and it works from any device without installing anything. Its trade-off is that clicking through screens does not scale well: 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 below come in. If an exam question describes a web-based graphical interface to manage Azure, the answer is the Azure portal.

Azure Cloud Shell is a browser-based command-line environment you launch straight from the Azure portal, so you get a working shell without installing anything on your own computer. It is authenticated with your Azure account automatically, which means you are already signed in and ready to run commands the moment it opens.

Cloud Shell gives you a choice of two shell experiences: Bash and PowerShell. Both come preloaded with the tools you need, including the Azure CLI and the Azure PowerShell modules, plus common utilities and text editors. It also provides persistent file storage backed by an Azure file share, so scripts and files you save are still there the next time you open it.

Because Cloud Shell runs in the browser and needs no local setup, it is perfect when you are on a shared or locked-down machine, or when you simply want a ready-to-go environment. Think of Cloud Shell as the place you run commands, while the Azure CLI and Azure PowerShell (covered next) are the command sets you actually type. You can also install those command sets locally on Windows, macOS, or Linux if you prefer working from your own terminal.

The Azure CLI and Azure PowerShell are two command-line tools that do the same job, manage Azure resources by typing commands or running scripts, but they use different styles. Both are cross-platform and run on Windows, macOS, and Linux, and both are available inside Cloud Shell.

The Azure CLI uses simple, space-separated commands that all begin with az, followed by a group and an action. For example, creating a resource group looks like az group create --name MyGroup --location eastus. Its style is clean and reads well in Bash scripts, and it is popular with people who work across many platforms.

The Azure PowerShell tool is a set of PowerShell modules made up of cmdlets, which follow a Verb-Noun naming pattern. The same task looks like New-AzResourceGroup -Name MyGroup -Location eastus. Because it is built on PowerShell, it fits naturally into wider Windows and PowerShell automation and can pass rich objects between commands.

Neither is better; the right choice usually depends on your background and the scripts you already have. Both let you automate repetitive tasks and run the exact same steps every time, which the portal cannot easily do by hand.

The three interactive tools overlap heavily: you can accomplish most everyday tasks 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. Use the portal to learn and to make quick, one-off changes, and use the command-line tools when you want to script, repeat, and automate.

A helpful way to remember it: choose the GUI (portal) for visual, occasional work, and choose a scripting tool (CLI or PowerShell) when you need to do the same thing reliably and repeatedly. Cloud Shell is where you can run either command-line tool from a browser without installing anything.

Azure Arc extends Azure management and governance to resources that do not live in Azure. Many organizations run servers in their own datacenters (on-premises), in other public clouds, or at the edge. Normally those resources are managed separately with their own tools. Azure Arc projects them into Azure so you can see and manage them alongside your native Azure resources, giving you a single control plane.

Once a resource is connected through Arc, you can apply familiar Azure capabilities to it, such as organizing it into resource groups, tagging it, applying governance policies, and viewing it in the Azure portal, even though the resource itself is running somewhere else. Azure Arc supports several resource types, including servers (Windows and Linux machines anywhere), Kubernetes clusters, and certain data services.

This matters most for hybrid and multicloud setups, where you want consistent management without moving everything into Azure first. If an exam question asks how to manage on-premises or multicloud resources from Azure as a single control plane, the answer is Azure Arc. Remember its scope: Arc is about managing non-Azure resources, not about deploying inside Azure, which is the job of the tools above and the templates below.

Infrastructure as code (IaC) is the practice of defining your infrastructure, virtual machines, networks, storage, and more, in files rather than building it by hand. You describe what you want in a configuration file, store it like source code, and deploy it whenever you need. Because the definition is declarative (you state the desired end result and Azure works out how to reach it) and repeatable, you get the exact same environment every time, which reduces mistakes and makes it easy to recreate or copy setups.

Azure Resource Manager (ARM) is the deployment and management service for Azure: every request to create or change a resource goes through ARM, whether it comes from the portal, the CLI, PowerShell, or a template. ARM templates are JSON files that declare the resources you want ARM to deploy.

Bicep is a newer, simpler language that does the same job with much cleaner, more readable syntax. Bicep files compile down to ARM JSON behind the scenes, so you get the same result with far less typing. For the exam, remember that both ARM templates and Bicep give you declarative, repeatable deployments, and Bicep is the friendlier language on top of ARM.

Imagine you run a small company. Some servers sit in your own office (on-premises), and you are starting to build new applications in Azure. You want to manage everything consistently.

First, take the on-premises server. You install the Azure Arc agent on it and connect it to Azure. Now that server appears in the Azure portal like any other resource: you can tag it, place it in a resource group, and apply governance policies, even though the hardware stays in your office. That is Azure Arc giving you a single control plane over a non-Azure machine.

Next, you need to deploy a set of Azure resources, a virtual network, a storage account, and a couple of virtual machines, for a new project, and you will do it again for a second project later. Instead of clicking through the portal each time, you write a Bicep file describing exactly those resources. You deploy it with one command through Azure Resource Manager, and later deploy the very same file for the second project. Every deployment is identical because the definition is declarative and repeatable. For a quick check on the first server's health, you simply open the Azure portal and click into it, no scripting required.

On the exam, most questions in this area are recognition: they describe a need and ask which tool fits. Anchor on each tool's headline purpose. If the scenario is a web-based graphical interface to manage Azure, choose the Azure portal. If it is a browser-based shell that needs no local install, choose Azure Cloud Shell. If it is about typing commands or writing scripts to automate Azure, choose the Azure CLI or Azure PowerShell, remembering that CLI uses az commands and PowerShell uses Verb-Noun cmdlets.

When a scenario mentions managing on-premises or multicloud resources from Azure, the answer is Azure Arc. When it mentions declarative, repeatable deployments defined in files, the answer is infrastructure as code with ARM templates or Bicep, and Bicep is the simpler language that compiles to ARM JSON.

Keep the boundaries clear, too. Controlling and analyzing spend is cost management, and governance features like Azure Policy and resource locks are separate topics. Watching how resources perform and behave is monitoring. This lesson is specifically about the tools you use to manage and deploy Azure resources, so match the scenario to the tool's core job and you will answer quickly and correctly.