Azure Portal, CLI, and PowerShell

Azure offers multiple interfaces to interact with its cloud resources. The business problem is simple: different tasks require different levels of control, automation, and user expertise. A junior admin might prefer a visual dashboard for occasional tasks, while a DevOps engineer needs scriptable tools for repeatable deployments. Azure provides three primary management tools: the Azure Portal (GUI), Azure CLI (command-line interface), and Azure PowerShell (scripting environment). All three use the Azure Resource Manager (ARM) API underneath, ensuring consistency.

All three tools communicate with Azure's Resource Manager, a REST API that handles all create, read, update, and delete (CRUD) operations. When you click 'Create VM' in the portal, it sends an HTTP request to ARM. When you run az vm create in CLI, it sends the same type of request. When you run New-AzVm in PowerShell, same thing. ARM then validates the request, checks permissions via Azure RBAC, and provisions the resource. This means changes made in one tool are instantly visible in others—there's no synchronization delay.

The Azure Portal is a web-based GUI accessible at portal.azure.com. It provides a dashboard with tiles, search bar, and navigation menus. It's ideal for:

Key components: - Dashboard: Customizable landing page with resource tiles - All Services: Menu listing every Azure service - Search Bar: Find resources or services quickly - Resource Groups: Logical containers for resources

Limitations:

Azure CLI is a cross-platform command-line tool (installable on Windows, macOS, Linux) that uses az commands. It's designed for:

Key commands: - az login – authenticate to Azure - az group create --name MyRG --location eastus – create a resource group - az vm create --resource-group MyRG --name MyVM --image UbuntuLTS --admin-username azureuser --generate-ssh-keys – create a VM

Azure CLI outputs JSON by default, making it easy to parse with tools like jq. It supports both interactive and non-interactive modes.

Azure PowerShell is a module for PowerShell (Windows, macOS, Linux) that provides cmdlets for Azure management. It's ideal for:

Key cmdlets: - Connect-AzAccount – authenticate - New-AzResourceGroup -Name MyRG -Location eastus – create a resource group - New-AzVm -ResourceGroupName MyRG -Name MyVM -Image UbuntuLTS -Credential (Get-Credential) – create a VM

Azure PowerShell outputs .NET objects, which can be piped to other cmdlets for further processing.

| Tool | Best For | Not Ideal For | |------|----------|---------------| | Portal | Visual tasks, learning, one-off changes | Automation, bulk operations | | CLI | Quick tasks, cross-platform scripting | Complex logic, Windows-only environments | | PowerShell | Complex automation, Windows integration | Linux-only users unfamiliar with PowerShell |

All three tools are free to use. You only pay for the Azure resources you create. There are no transaction fees for management operations. However, there are Azure subscription limits (e.g., 250 storage accounts per region per subscription) that apply regardless of tool choice.

In an on-premises datacenter, you might use:

Azure's tools are analogous but centralized: all resources are managed through ARM, providing a single pane of glass regardless of where resources are located globally.

Scenario 1: DevOps CI/CD Pipeline A software company uses Azure DevOps to deploy a web app every time code is pushed to GitHub. The deployment script uses Azure CLI to create a resource group, App Service plan, and web app, then deploys the code via az webapp deployment source config-zip. The CLI commands are embedded in a YAML pipeline. The team chose CLI over PowerShell because the build agents are Linux-based. They use az login --service-principal for non-interactive authentication. Cost is minimal—only the App Service plan is billed. A common mistake is forgetting to set the --sku parameter, leading to a higher-tier plan than needed. If the script fails due to a typo, the entire pipeline fails, requiring manual cleanup. To mitigate, they use --only-show-errors and idempotent commands (e.g., az group create --exists-ok).

Scenario 2: IT Operations Monitoring A large enterprise's IT team uses the Azure Portal daily to monitor resource health, review cost reports, and troubleshoot incidents. They rely on the portal's dashboards to visualize metrics like CPU usage and error rates. For example, when a VM goes down, they navigate to the VM's blade, check 'Metrics' for CPU spikes, and review 'Boot diagnostics' screenshots. The portal's rich GUI allows them to quickly drill down without scripting. However, when they need to restart 50 VMs after a patch, they use a PowerShell script: Get-AzVM -ResourceGroupName Prod | Restart-AzVM. This avoids clicking 50 times. The team uses Azure RBAC to grant read-only access to junior staff via the portal, while senior engineers have contributor rights. A common pitfall is that junior staff might accidentally delete resources if not properly restricted. They use Azure Policy to prevent deletion of critical resources.

Scenario 3: Cloud Migration A startup migrating from on-premises to Azure uses ARM templates (JSON) to define their entire infrastructure as code. They deploy templates using both CLI and PowerShell interchangeably. For example, they run az deployment group create --resource-group MyRG --template-file template.json to create a VNet, subnets, and VMs. This ensures repeatability and version control. They also use Azure CLI to export existing resources: az resource list --resource-group MyRG --export-template > template.json. This helps them document their environment. Cost considerations: they use Azure Pricing Calculator to estimate costs before deployment. A common error is hardcoding secrets in templates; they use Azure Key Vault references instead. If a deployment fails due to a quota limit, they see an error message and must request a quota increase via the portal.