The Azure Portal Is Not the Problem
The Azure portal is useful.
It is excellent for learning a service, inspecting configuration, troubleshooting, testing an idea, and understanding how Azure resources behave.
The problem begins when important production infrastructure exists only because someone remembers which buttons they clicked.
A manual deployment can work perfectly.
But six months later, can another engineer answer:
- Why was this resource configured this way?
- Which settings are intentional?
- Which settings changed after deployment?
- Can we reproduce the same environment?
- Can we create another region or subscription consistently?
- Can we review the infrastructure change before it happens?
- Can we identify configuration drift?
- Can we rebuild after a serious failure?
Infrastructure as Code helps turn those questions into an operating model rather than a memory exercise.
Microsoft currently recommends an Infrastructure-as-Code approach for Azure platform landing zones and supports both Bicep and Terraform through Azure Verified Modules and the Azure Landing Zones IaC Accelerator. Microsoft Learn: Deploy Azure landing zones with Infrastructure as Code
That does not mean every organization must deploy a complete enterprise landing zone before its first workload.
It means Microsoft’s direction reinforces a broader principle:
Repeatable Azure foundations are easier to govern than manually reconstructed ones.
What Infrastructure as Code Actually Gives You
Infrastructure as Code is sometimes described simply as “automating deployments.”
That is incomplete.
Automation is useful, but the bigger benefits are definition, review, repeatability, and change control.
A useful IaC practice can provide:
A defined target state
The intended infrastructure exists in files that people can inspect.
Version history
Teams can see what changed and why.
Peer review
Important changes can be reviewed before they reach Azure.
Repeatability
The same pattern can be deployed again without relying on memory.
Environment consistency
Development, test, and production environments can share a common architecture while still using different parameters.
Reusable standards
Networking, logging, tagging, security settings, and governance can be incorporated into approved patterns.
Recovery context
If infrastructure must be rebuilt, the code provides a much stronger starting point than screenshots and tribal knowledge.
The counterintuitive point is that the greatest IaC value often appears after the first deployment.
The first manual deployment may genuinely be faster.
The fifth environment, third engineer, second region, or first major recovery event changes the economics.
A Day-One Decision Is Not the Same as Day-One Automation
This distinction prevents unnecessary overengineering.
| Maturity level | What it means |
|---|---|
| Manual exploration | Engineers use the portal or CLI to understand Azure services |
| Defined infrastructure | Important repeatable infrastructure is represented as code |
| Controlled code | Code is versioned, reviewed, and treated as the preferred source of change |
| Automated delivery | Approved infrastructure changes run through deployment pipelines |
A small Azure environment may begin between the first and second stages.
That can be entirely reasonable.
You do not need a sophisticated pipeline before anyone understands the architecture.
You do need to decide whether infrastructure that becomes production-critical will eventually be managed through code.
That decision affects how engineers work from the beginning.
If the organization knows that production infrastructure belongs in code, a portal-created proof of concept can be treated as temporary.
If nobody makes that decision, temporary manual deployment often becomes permanent architecture.
What Should Go Into Code First?
Do not begin by asking:
“How do we put every Azure resource into Terraform or Bicep?”
Start with infrastructure where inconsistency would create the greatest long-term problem.
Network foundations
Virtual networks, subnets, routing, shared connectivity, DNS-related resources, and network controls benefit from repeatability because many workloads may depend on them.
A manually changed network can create consequences far beyond the resource being edited.
Governance foundations
Management-group structure, policy assignments, role patterns, diagnostic settings, and other shared controls are strong candidates because their value depends on consistent application.
Subscription onboarding
As subscription count grows, repeatable subscription configuration becomes increasingly valuable.
A new subscription should not require someone to remember a checklist of twenty portal actions.
Microsoft’s current landing-zone guidance includes Bicep and Terraform subscription-vending options for repeatable application landing-zone provisioning. Microsoft Learn: Azure landing zone deployment options
Shared platform services
Central monitoring, connectivity, security, identity integration, and other shared services often benefit from code because changes affect multiple workloads.
Repeatable workload patterns
If multiple application teams repeatedly need the same architectural pattern, Infrastructure as Code can turn that pattern into a reusable starting point.
The decision rule is simple:
Code the infrastructure whose inconsistency, loss, or manual recreation would create material operational risk.
What Can Wait?
Not everything deserves immediate automation.
A short-lived sandbox resource may not.
A service being evaluated for an afternoon may not.
A temporary experiment whose entire purpose is to learn how the service behaves may not.
A one-off portal deployment can be appropriate when:
- the resource is disposable;
- nobody else depends on it;
- the configuration is still being explored;
- recreating it is trivial;
- it will not become an undocumented production dependency.
The important boundary is what happens when the experiment becomes real.
There should be a point at which the team says:
“This is becoming an approved environment. Its infrastructure now needs to follow the production deployment model.”
Without that transition, proof-of-concept infrastructure quietly becomes production infrastructure.
Bicep or Terraform?
For an Azure-focused organization, both are credible options.
Microsoft supports both Bicep and Terraform for Azure platform landing-zone deployments and provides Azure Verified Modules for both approaches. Microsoft Learn: Azure landing zone deployment options
The decision should therefore be based on the organization’s operating model rather than a generic claim that one tool is always better.
Bicep can fit well when:
- the environment is primarily or exclusively Azure;
- teams want tight alignment with Azure Resource Manager;
- engineers prefer an Azure-native declarative language;
- avoiding a separately managed IaC state file is valuable;
- the organization wants direct access to new Azure resource capabilities through the ARM model.
Microsoft describes Bicep as Azure-specific and notes that Azure maintains resource state, so Bicep does not require a separate state file. Microsoft Learn: Bicep overview
Terraform can fit well when:
- the organization already has Terraform skills and practices;
- teams manage infrastructure across Azure and other providers;
- a common IaC workflow across multiple platforms matters;
- existing Terraform modules or operating standards are already established;
- the team is prepared to manage Terraform state correctly.
Microsoft’s comparison guidance describes Terraform as provider-based and suitable for Azure as well as multicloud, on-premises, and other infrastructure targets. Microsoft Learn: Comparing Terraform and Bicep
The practical question is not:
“Which tool wins?”
It is:
“Which tool can this organization operate consistently for the next several years?”
Do Not Choose the Tool Based on One Engineer’s Résumé
This is a surprisingly important governance issue.
If the entire Azure deployment model depends on the preferred tool of one engineer, the platform has a personnel dependency.
Ask instead:
- Who will maintain this code?
- Who can review it?
- Where will modules live?
- How are versions controlled?
- How will engineers learn the standard?
- Who owns failures in deployment pipelines?
- How will tooling upgrades be tested?
- Can another team operate the environment if the original author leaves?
IaC is supposed to reduce reliance on individual memory.
Do not recreate that dependency in the codebase.
Terraform State Is Part of the Platform
If Terraform is selected, state management is not a small implementation detail.
Terraform uses state to map its configuration to deployed infrastructure.
Microsoft notes that local Terraform state is not ideal for collaborative environments, can contain sensitive information, and is vulnerable to accidental loss. Microsoft documents using remote Azure Storage for shared state, locking, and encryption. Microsoft Learn: Store Terraform state in Azure Storage
Before Terraform becomes production infrastructure, decide:
- Where is state stored?
- Who can read it?
- Who can modify it?
- How is access authenticated?
- Is the state storage protected from public access where appropriate?
- How is it backed up or protected from accidental deletion?
- How are separate environments isolated?
- How are state-lock conflicts handled?
- Who owns recovery if state and deployed resources diverge?
A strong Terraform repository with poorly protected state is not a mature deployment model.
The state backend should be designed as part of the platform.
Define the Rule for Out-of-Band Changes
Infrastructure as Code does not prevent someone with permissions from changing Azure through the portal, CLI, PowerShell, or another automation path.
That means every organization using IaC eventually needs an answer to:
“What happens when someone changes a code-managed resource manually?”
There are several legitimate policies.
One organization may prohibit manual production changes except for emergency remediation.
Another may permit them but require the change to be reflected back into code immediately.
Another may allow specific operational properties to be changed outside IaC.
The exact rule can vary.
The absence of a rule is the problem.
Otherwise the organization develops two versions of reality:
The infrastructure the repository says exists.
And:
The infrastructure Azure actually contains.
Microsoft’s landing-zone guidance on IaC updates specifically addresses drift between deployed resources and configuration and the need to reconcile the environment with the defined state. Microsoft Learn: Infrastructure as Code updates
Decide which source is authoritative and how drift is handled before drift becomes routine.
Reusable Modules Are Useful—But Do Not Build an Internal Cloud Product Too Early
Reusable modules can create enormous value.
They can standardize:
- naming;
- tags;
- diagnostic settings;
- network configuration;
- security defaults;
- role assignments;
- common service options.
Microsoft’s Azure Verified Modules provide reusable Bicep and Terraform building blocks and are used in Microsoft’s current platform landing-zone deployment approach. Microsoft Learn: Azure landing zone implementation options
But a new Azure team can overcorrect.
It may spend weeks creating a complex internal module framework for resources it has deployed only once.
That is premature abstraction.
A better sequence is:
- Deploy a pattern.
- Understand the real variation.
- Repeat it.
- Identify what should be standardized.
- Build or adopt the reusable module.
- Version it.
- Document how consumers should use it.
A module should remove repeated complexity.
It should not create a new layer of complexity nobody needed.
Put IaC in Version Control Before You Build an Elaborate Pipeline
Teams sometimes jump immediately to sophisticated CI/CD.
Multiple environments.
Approval gates.
Reusable pipeline templates.
Automated testing.
Security scanning.
Release workflows.
Those can all be valuable.
But the first maturity step is simpler:
Put the infrastructure definition somewhere controlled and reviewable.
A minimum version-control practice should provide:
- a central repository;
- branch or review expectations;
- ownership;
- commit history;
- documented deployment instructions;
- separation of configuration from secrets.
Then improve automation according to risk and deployment frequency.
The sequence matters because a pipeline does not make unclear infrastructure good.
It only makes unclear infrastructure deploy faster.
Infrastructure as Code Does Not Replace Architecture
A badly designed network expressed perfectly in Terraform is still a badly designed network.
An excessive Owner assignment deployed through Bicep is still excessive privilege.
A poorly scoped policy deployed automatically is still a poorly scoped policy.
IaC makes decisions repeatable.
It does not make the decisions correct.
Architecture still has to answer:
- What should exist?
- Why?
- At what scope?
- Who owns it?
- Which security requirement applies?
- Which failure modes matter?
- What is the cost implication?
- How will it be operated?
Then Infrastructure as Code can make those answers consistently deployable.
This is one reason BI Cloud Tech separates architecture review from implementation: a repeatable deployment process is most valuable when the underlying architecture is intentional.
A Minimum Day-One IaC Standard
An organization starting Azure does not need maximum automation.
A practical early standard can be small.
For production-bound shared infrastructure:
1. Choose the IaC direction.
Decide whether Bicep, Terraform, or another approved approach is the default.
2. Establish version control.
Store infrastructure definitions in an owned repository.
3. Define the production boundary.
Decide which infrastructure must be represented as code.
4. Establish ownership.
Know who maintains modules, repositories, deployment processes, and state where applicable.
5. Define manual-change behavior.
Document how out-of-band changes are handled.
6. Protect credentials and state.
Do not allow deployment automation to become a new secret-management weakness.
7. Start reusable patterns where repetition is real.
Do not abstract hypothetical future requirements.
8. Add CI/CD as deployment frequency and risk justify it.
This is enough to establish direction without turning a three-resource Azure environment into a platform-engineering program.
Warning Signs
Review the IaC model if you hear:
“We build production through the portal because it is faster.”
“The Terraform state is on someone’s laptop.”
“Only one person understands the modules.”
“Nobody is allowed to touch anything because the pipeline might break.”
“We created our own module for every Azure resource before deploying any workloads.”
“The repository says one thing, but Azure has been changed manually for months.”
“We have IaC, so the architecture is standardized.”
“We need a six-stage pipeline before we can deploy our first test resource.”
These statements point to opposite problems: too little control or too much process.
Good IaC practice sits between them.
A Day-One Infrastructure as Code Checklist
Before Azure production adoption accelerates, ask:
- Have we selected a preferred Infrastructure-as-Code approach?
- Do the people who will operate it have the required skills?
- Is production-bound infrastructure stored in version control?
- Have we defined which resources must be code-managed?
- Are changes reviewable before deployment?
- Do we know when portal-created resources must be converted into code?
- If using Terraform, is remote state secured and owned?
- Are deployment identities protected and least-privileged?
- Do we have a rule for manual changes to code-managed infrastructure?
- Are modules based on real reusable patterns rather than hypothetical ones?
- Can another engineer reproduce the environment?
- Can another engineer understand why the configuration exists?
- Is CI/CD complexity proportional to actual deployment needs?
- Does architecture review still occur independently of deployment automation?
If several answers are unclear, the issue is not necessarily that more automation is required.
The issue is that the organization has not yet defined its infrastructure-management model.
Infrastructure as Code Is a Platform Decision Before It Is an Automation Project
Infrastructure as Code should not be adopted because automation sounds modern.
It should be adopted where repeatability, reviewability, recoverability, and consistency matter.
Use the portal to learn.
Use experimentation to understand Azure services.
Do not force every disposable resource into a production pipeline.
But once infrastructure becomes part of the platform or a production workload, decide how it will be represented, reviewed, changed, and reproduced.
BI Cloud Tech’s Infrastructure as Code and Terraform expertise, Azure Landing Zone expertise, Landing Zone Implementation, and Architecture Review are relevant resources for organizations defining or improving that operating model.
The goal is simple:
You do not need maximum automation on day one. You do need to avoid making manual infrastructure the permanent design.
