Solved: Azure CLI, Bash, PowerShell or Python – Day-to-Use?

#devops #programming #tutorial #cloud

🚀 Executive Summary

TL;DR: Engineers often struggle to select the appropriate tool among Azure CLI, Bash, PowerShell, or Python for Azure tasks, leading to inefficient or brittle solutions. A senior engineer proposes a tiered framework, guiding tool selection based on task complexity and permanence, from quick interactive fixes to robust, long-term automation. This approach helps reduce cognitive load and ensures the right tool is used for the specific job.

🎯 Key Takeaways

Avoid ‘tool-hammer syndrome’ by choosing the right tool for the specific problem, rather than using a single ‘daily driver’ for all tasks.
Utilize a tiered approach: Bash + Azure CLI + jq for quick, interactive fixes; PowerShell for repeatable scripts leveraging object pipelines; and Python + Azure SDK for robust, long-term automation tools.
Always use jq for parsing JSON output from Azure CLI commands to avoid brittle scripts, instead of text-based tools like grep, awk, or sed.

Stuck choosing between Azure CLI, Bash, PowerShell, or Python? A Senior DevOps Engineer breaks down the real-world use cases for each, helping you pick the right tool for the job, from quick one-liners to robust automation.

Azure CLI, Bash, PowerShell, or Python? A Senior Engineer’s Guide to Winning the Day

I remember it was pushing 10 PM on a Tuesday. A critical deployment was failing, and a junior engineer, bless his heart, was trying to fix a permissions issue by parsing the JSON output from an az role assignment list command with a five-line chain of grep, awk, and sed. It was fragile, unreadable, and about to accidentally grant subscription-owner to the wrong service principal. That’s when I put my hand on his shoulder and said, “Let’s take a walk.” We had to have ‘the talk’ – not about what the tools do, but when and why you reach for each one.

The “Why”: It’s Not a Competition, It’s a Toolbox

The root of this problem isn’t that any of these tools are “bad.” They’re all fantastic. The problem is that we’re often presented with a false choice, as if we have to pick one to be our “daily driver” for everything. This leads to what I call “tool-hammer syndrome,” where you try to solve every problem with the one tool you know best, even if it’s the wrong fit.

The truth is, a seasoned engineer doesn’t have a favorite tool; they have a favorite solution for a given problem. The goal is to reduce cognitive load and use the path of least resistance. Trying to build a robust, testable automation pipeline in pure Bash is just as painful as trying to spin up a quick dev VM with a 100-line Python script. It’s about situational awareness.

My Framework: Choosing Your Weapon

Here’s the mental model I use and teach my team. I break it down into three tiers of complexity and permanence.

Tier 1: The Quick & Dirty Interactive Fix (Bash + Azure CLI + jq)

This is your go-to for interactive, in-the-moment tasks. You’re in the shell, you need an answer now, and you’ll probably never run this exact command again. Think of it as a conversation with the Azure API.

When to use it: “What’s the IP of prod-db-01?”, “Quickly list all VMs in the staging resource group,” “Restart that hung web app.”
The Vibe: Disposable, immediate, exploratory.
Example: Find all running VMs tagged for the ‘Q4-Project’ and get their names and public IP addresses.

az vm list --show-details --query "[?tags.project=='Q4-Project' && powerState=='VM running'].{Name:name, IP:publicIps}" --output tsv

Pro Tip: Learn and love jq. If your Azure CLI command outputs JSON and you’re tempted to pipe it to grep, stop. You’re making a mistake that will cost you time later. jq is the proper tool for slicing and dicing JSON on the command line.

Tier 2: The Repeatable Script (PowerShell)

You’ve moved beyond one-liners. You need a script that can handle some light logic, work with native Azure objects, and will likely be run by you or your team members periodically. This is where PowerShell, especially with the Az module, really shines.

Its strength is the object pipeline. You aren’t just passing text around; you’re passing rich .NET objects with properties and methods. This is a game-changer when you’re deep in the Microsoft ecosystem (Azure AD, M365, Windows Servers).

When to use it: “Create a report of all users in Azure AD with a specific license,” “De-provision a standard set of resources for an employee who is leaving,” “Find all storage accounts without encryption and tag them for review.”
The Vibe: A structured, repeatable task.
Example: Find all Virtual Machines in a resource group and stop them cleanly.

# Get all VMs in the resource group 'Prod-WestUS2-RG'
$vms = Get-AzVM -ResourceGroupName "Prod-WestUS2-RG"

# Loop through each VM object and stop it
foreach ($vm in $vms) {
    Write-Host "Stopping VM: $($vm.Name)..."
    Stop-AzVM -ResourceGroupName $vm.ResourceGroupName -Name $vm.Name -Force
}

Tier 3: The Robust, Long-Term Automation (Python + Azure SDK)

This is the “nuclear option” for when you are building a tool, not just a script. Your code will be version-controlled, have error handling, probably be tested, and run as part of a CI/CD pipeline or a scheduled function. You need to interact with other APIs (Jira, Slack, PagerDuty), handle complex state, and ensure the process is idempotent.

When to use it: Building an automated “Vending Machine” for dev environments, creating a scheduled task to audit security compliance and auto-remediate, orchestrating a complex multi-stage deployment.
The Vibe: Permanent, reliable, “set-it-and-forget-it” automation.
Example: A snippet from a Python script to idempotently create a resource group.

from azure.identity import DefaultAzureCredential
from azure.mgmt.resource import ResourceManagementClient
import os

# Authenticate using environment variables or managed identity
credential = DefaultAzureCredential()
subscription_id = os.environ["AZURE_SUBSCRIPTION_ID"]
resource_client = ResourceManagementClient(credential, subscription_id)

RG_NAME = "prod-automation-rg"
LOCATION = "eastus"

def create_resource_group(rg_name, location):
    try:
        print(f"Checking for resource group: {rg_name}...")
        if not resource_client.resource_groups.check_existence(rg_name):
            print(f"Creating resource group: {rg_name} in {location}...")
            resource_client.resource_groups.create_or_update(rg_name, {"location": location})
            print("Creation successful.")
        else:
            print("Resource group already exists.")
    except Exception as e:
        print(f"An error occurred: {e}")
        # Add real error handling/logging here

create_resource_group(RG_NAME, LOCATION)

Warning: Don’t reach for Python just to run a single az command. The overhead of setting up dependencies and a virtual environment is overkill. Use Python when you need its ecosystem: its robust libraries for testing, error handling, and web requests.

Quick-Reference Showdown

Tool / Stack	Sweet Spot	Biggest “Gotcha”
Bash + Azure CLI	Interactive shell work, simple loops, “fire and forget” commands.	Extremely brittle for complex logic or parsing structured data. Avoid parsing JSON with text tools!
PowerShell	Managing Azure/M365 resources as objects, repeatable scripts for Windows-heavy environments.	Can be verbose. The object-oriented nature is a steep learning curve for those from a pure Linux/Bash world.
Python + SDK	Building long-term, testable, and maintainable automation tools that need to be part of a larger system.	Significant overhead for simple, one-off tasks. It’s bringing a crane to lift a pebble.

So, next time you’re faced with a task in Azure, take a breath. Don’t just reach for the tool you used last. Ask yourself: “How important is this? How often will I run it? Does it need to be bulletproof?” Your answer will point you to the right part of the toolbox every time.