Managing Azure: the portal, Cloud Shell, Azure CLI, Azure PowerShell and Azure Arc

Why this matters

There are several ways to tell Azure what to do, and they suit different people and different jobs. A new administrator clicking through a wizard, a developer typing a quick command on a borrowed laptop and an engineer scripting the same change across three hundred machines are all managing Azure, but with different tools. Picking the wrong one wastes hours: nobody wants to make the same change by hand in a browser every week, and nobody wants to install a toolchain just to check one setting.

The second half of this lesson deals with a question managers and salespeople hear constantly: "Most of our servers are not in Azure. Can we still manage them from there?" The answer is Azure Arc, and it is often confused with migration. A junior administrator who understands that every one of these tools goes through the same front door, with the same permission checks, will also stop expecting a script or a shell to get round rules that the portal enforces.

The lesson

The Azure portal

The Azure portal is Azure's web-based, graphical console. It runs in any modern browser on any operating system, so there is nothing to install. An administrator signs in and can create, configure, monitor and delete resources through menus, forms and wizards. It is the natural starting point for someone new to Azure, and it is good for exploring, for one-off tasks and for seeing the state of things at a glance.

Points worth knowing:

• It does real work, not just viewing. The portal can create and change resources as well as display them.
• It is always current. Microsoft updates the portal continuously, and it needs no downtime for maintenance. There is no portal version to install or upgrade.
• Dashboards. A user can build a custom dashboard: a page of pinned tiles, charts and resource views arranged in their own layout. A team lead can put the charts the team checks each morning on one page and share it with colleagues.
• What you see depends on your permissions. Two people signed in to the same portal can see different resources. That is not a different portal or a regional filter. Their Azure role-based access control (RBAC) assignments cover different scopes (lesson 11), and the portal only shows what each person may access. Resource locks (lesson 13) never hide anything; they only stop deletion or change.
• It goes through Azure Resource Manager. Every action in the portal becomes a request to Azure Resource Manager, the management layer described in lesson 15. The portal does not replace Resource Manager; it is one of its clients.

The portal's weakness is repetition. Clicking through the same change on 300 virtual machines every week is slow and error-prone. That is where command-line tools come in.

Azure Cloud Shell, the Azure CLI and Azure PowerShell

Azure has two command-line tools and one hosted place to run them.

The Azure CLI is a cross-platform command-line tool. Its commands start with az, for example az group create or az vm list. It installs on Windows, macOS and Linux and is usually run from Bash, although it also works in other shells. It uses its own command syntax rather than cmdlets.

Azure PowerShell is a set of PowerShell modules, the Az module, that adds cmdlets for managing Azure, such as New-AzResourceGroup or Get-AzVM. An administrator who already writes cmdlet-based scripts for Windows can reuse that skill directly. It is not limited to Windows: through PowerShell 7 it runs on Windows, macOS and Linux as well.

The two tools are functionally equivalent. Each can create, configure, manage and script the same Azure resources. The choice usually comes down to what the person or team already knows. Both are text tools; neither is graphical.

The real advantage of both over the portal is scripting. A change written once as a script can be rerun every week, on every machine, the same way each time. That makes them the right choice for repetitive work across many resources and for automation.

Azure Cloud Shell is an interactive shell that runs in the browser. Key facts:

• Launching it. Open it from the Cloud Shell icon in the Azure portal, or go straight to shell.azure.com in a browser. It works from any operating system.
• Already signed in. It opens authenticated with the user's own Azure account, so there are no credentials to type.
• Bash or PowerShell. The user chooses a Bash or a PowerShell session.
• Tools preinstalled. The Azure CLI and Azure PowerShell both come ready to use, along with common editors and utilities.
• Microsoft hosts it. There is no virtual machine for the user to deploy or maintain. A user can attach an Azure file share so that files persist between sessions.

So for an engineer on a borrowed laptop who needs to run a few Azure CLI commands right now, Cloud Shell is the answer. Do not confuse the names: Cloud Shell is not another name for the Azure CLI. It is the hosted environment, and the CLI is one of the tools inside it. The CLI can also be installed and run on a local computer without Cloud Shell.

Permissions are the same whichever tool you use. Requests from the portal, the Azure CLI, Azure PowerShell and Cloud Shell all reach Azure Resource Manager, which checks RBAC before acting. A script runs with the rights of the identity that signed in, and a Cloud Shell session has exactly the signed-in user's rights. No tool bypasses RBAC, Azure Policy or resource locks. An auditor asking whether permissions depend on the tool can be told plainly: they do not.

Azure Arc: managing resources outside Azure

Many organisations run servers in their own data centres, at edge sites such as shops or factories, and in other cloud providers, alongside what they have in Azure. Managing each environment with its own tools is hard to govern. Azure Arc extends Azure's management to those resources where they already run.

Arc works by projecting non-Azure resources into Azure Resource Manager. Once connected, each server or cluster appears as a resource in Azure, with a resource ID, a resource group and a subscription. From then on it can be handled with the same tools as native Azure resources:

• Azure Policy to audit and enforce configuration settings (lesson 13);
• tags to organise and report on it (lesson 12);
• Azure RBAC to control who may manage it;
• Azure Monitor and Microsoft Defender for Cloud to watch and secure it (lessons 16 and 11);
• the portal, CLI and PowerShell to view and manage it, all from one inventory.

What Arc can bring under Azure management:

• Servers: Windows and Linux machines, physical or virtual, in an on-premises data centre, at the edge or in another cloud. A small agent, the Connected Machine agent, is installed on each one.
• Kubernetes clusters running anywhere. A retailer with clusters in its stores can push configurations to them centrally and apply Azure Policy from Azure.
• Data services, such as SQL Server instances running outside Azure.

What Arc does not do matters as much:

• It does not move anything. The servers keep running on the company's own hardware in its own buildings, so its power and cooling costs do not change. Moving workloads into Azure is Azure Migrate, which assesses servers and migrates them. Shipping large amounts of data offline is Azure Data Box (lesson 9).
• It does not host clusters. Azure Kubernetes Service (AKS) is a managed Kubernetes service that runs clusters inside Azure. Arc-enabled Kubernetes is for clusters that already run somewhere else.
• It is not for users' devices or Microsoft 365. Staff phones are managed with Microsoft Intune, and mailboxes through Microsoft 365. Arc does not manage domain registrations either.
• It is not a network link. A private connection between an office and Azure is VPN Gateway or ExpressRoute (lesson 8).

The relationship between Arc and Resource Manager is a favourite exam point. Resource Manager is the management layer for resources in Azure. Arc extends that same layer to resources outside Azure. Arc does not replace Resource Manager, and neither of them is a migration tool.

What the exam is really asking

• Portal vs command line. The portal is graphical and needs no install; it suits exploring and one-off tasks. The CLI and PowerShell suit repeatable, scripted work across many resources.
• CLI vs PowerShell. They can do the same things. The CLI uses az commands, usually from Bash; PowerShell uses cmdlets. Both run on Windows, macOS and Linux, and both are in Cloud Shell. A question that stresses existing cmdlet skills points to Azure PowerShell.
• Cloud Shell vs the CLI. Cloud Shell is a hosted, already-authenticated browser shell offering Bash or PowerShell. The CLI is a tool that runs inside it or on your own computer. "No time to install anything" points to Cloud Shell.
• Same rules everywhere. Every tool goes through Azure Resource Manager, so RBAC, Policy and locks apply equally. Different views in the portal mean different role assignments.
• Arc vs Migrate vs AKS. Arc manages resources in place outside Azure. Migrate moves them into Azure. AKS runs Kubernetes inside Azure. If the scenario says "keep them where they are", the answer is Arc.
• Arc vs Resource Manager. Arc extends Resource Manager beyond Azure; it is not a replacement for it.