Azure Portal vs. CLI vs. Bicep: Who's in Charge?

When I first landed in the Azure portal, it felt like walking into a trendy coffee shop with 300 types of beans. Everything looked exciting, but I had no idea where to begin. Then came CLI and Bicep — and suddenly I wasn’t just a coffee drinker anymore. I was the barista, the roaster, and the machine technician all at once.

This article is part of my ongoing learning journey from Microsoft 365 expert to Azure explorer. I’ll walk you through the three main ways to interact with Azure, share the mistakes I made as a beginner, and explain why automation isn’t just a nice-to-have — it’s essential for scaling and maintaining your cloud infrastructure.

Three ways to work with Azure — each with its own flavor

1. Azure Portal – the visual interface

The Azure Portal (https://portal.azure.com) is the graphical web interface where you create and manage resources like virtual machines, storage accounts, and networks.

Pros:

• Intuitive and visual
• Great for beginners and quick testing
• No coding required

Cons:

• Not reproducible
• No version control
• Easy to lose track of what you’ve configured

Example: creating a VM via the portal

• Click “Virtual Machine” → “Create”
• Choose or create a resource group
• Select region, size, image (e.g. Ubuntu), authentication, and networking
• Click “Review + Create”

The catch: you won’t remember what you clicked two weeks later — and neither will Azure.

2. Azure CLI – command line with cloud power

Azure CLI is a cross-platform command-line tool you can run locally or in the Azure Cloud Shell. It’s ideal for scripting and automation.

Pros:

• Scriptable and automatable
• Precise control
• Great for DevOps workflows

Cons:

• Requires syntax knowledge
• Less visual feedback
• Easy to make mistakes if you don’t understand the commands

Example: creating a VM via CLI

az group create --name RoestGruppe --location westeurope
az vm create \
  --resource-group RoestGruppe \
  --name EspressoVM \
  --image UbuntuLTS \
  --admin-username ferdi \
  --generate-ssh-keys

Use --output json or --query to extract specific data like public IPs.

3. Bicep – Azure-native infrastructure as code

Bicep is a declarative language from Microsoft for defining Azure resources. It’s clean, readable, and integrates directly with the Azure ecosystem.

Pros:

• Versionable and reusable
• Easy to read and maintain
• Ideal for teams and CI/CD pipelines

Cons:

• Requires an initial learning curve
• Best used from the start, not retroactively

Example: creating a storage account with Bicep

resource storage 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: 'roeststorage'
  location: resourceGroup().location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

Deployment:

az deployment group create \
  --resource-group RoestGruppe \
  --template-file storage.bicep

Terraform – what my research revealed

I’ll be honest: I haven’t used Terraform in practice yet. But based on my research, it’s a powerful alternative to Bicep — especially if you work across multiple cloud platforms.

Terraform is an open-source tool from HashiCorp that supports Azure, AWS, Google Cloud, Kubernetes, and more. It uses HCL (HashiCorp Configuration Language) and manages infrastructure state via a local or remote file.

What stood out to me:

• Multi-cloud support
• Potentially fewer lines of code for some resources
• Requires careful state management

Example from my research:

resource "azurerm_storage_account" "roeststorage" {
  name                     = "roeststorage"
  resource_group_name      = "RoestGruppe"
  location                 = "West Europe"
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

Terraform isn’t a replacement for Bicep — it’s a different tool with a different focus. I plan to test both and write a follow-up: “Bicep vs. Terraform – Espresso for Azure or Multi-Cloud Mocha?”

Beginner mistakes I wish I’d avoided

“I’ll just click around in the portal…”

I created resources manually, thinking I’d remember what I did. I didn’t. No documentation, no reproducibility. It was like brewing espresso without a recipe — every cup tasted different.

“CLI looks cool — let’s copy some commands.”

I copied CLI commands from docs without understanding them. I ended up deploying resources in the wrong region and misconfiguring networks. CLI is powerful, but it doesn’t forgive ignorance.

“Bicep? Sounds like a gym thing.”

I discovered Bicep too late. I had already built a bunch of resources manually and had to reverse-engineer everything into code. It was painful and inefficient.

“Terraform is just like Bicep, right?”

Not quite. Terraform’s state management and multi-cloud capabilities add complexity. Without understanding how the state file works, you risk ending up with infrastructure that doesn’t match your code.

Why automation is essential

Scalability

Need 50 VMs across three regions? Don’t click — script. Automation lets you scale without losing your mind.

Maintainability and security

Code-based deployments are versioned, auditable, and reversible. You know who changed what, when, and why.

Testability

Spin up identical environments for testing, staging, and production. No surprises, no inconsistencies.

Reusability

Write once, use everywhere. Your Bicep modules become your infrastructure cookbook.

My espresso tip for you

Clicking through Azure is fine for learning. But if you want to scale, automate, and sleep well at night, start coding your infrastructure. Your future self (and your IT team) will thank you.