The Azure Portal is genuinely good. It is discoverable, it explains what each setting does, and it is perfect for exploring. But building your real infrastructure by clicking through it — "click-ops" — is a habit that quietly wrecks teams, and I think it should stop the moment a resource matters.
Clicks Aren't Reproducible
The core problem: a resource you created by clicking exists only in that subscription. There is no record of how you built it. When you need the same thing in staging, or in a second region, or after someone deletes it, you are reconstructing it from memory. Infrastructure as Code makes the definition the source of truth:
resource storage 'Microsoft.Storage/storageAccounts@2023-01-01' = { name: 'myappstorage' location: resourceGroup().location sku: { name: 'Standard_LRS' } kind: 'StorageAccount' }
That file is the environment. Deploy it anywhere and you get exactly the same result.
Clicks Aren't Reviewable
A portal change lands in production with no diff, no pull request, no second pair of eyes. With Bicep or Terraform, every change is a commit someone can review before it ships:
az deployment group create \ --resource-group my-rg --template-file main.bicep
Now "why is this NSG open to the internet?" has a git-blame answer instead of a shrug.
Clicks Drift
Manual changes accumulate as drift — the real environment slowly diverges from anything documented. Six months in, nobody can say with confidence what is actually deployed. IaC lets you detect and correct drift because the desired state is written down.
Where I Land
Use the portal to explore, to read, and to debug — it is excellent for all three. But the moment a resource is real, define it in Bicep or Terraform and deploy it through a pipeline. Yes, it is slower than clicking the first time. But you get reproducibility, review, and drift control — the three things that separate infrastructure you can trust from infrastructure you merely hope still works. Click to learn; commit to build.