How much of an Azure landing zone network do you manage with Terraform?

Terraform can manage the core network resources, including VNets, peerings, route tables, NSGs, and Azure Firewall rules. The harder part is agreeing that the code is the change process, not just an optional copy of what people also edit by hand.

I’d start by defining who owns each layer and limiting routine write access in the portal. Let the deployment identity make changes through an approved pipeline, and keep human access read-only where that fits your operating requirements. If people can still make untracked edits, you’ll need a process for spotting and reconciling drift.

Don’t make the first step “everyone learn Terraform.” Make the safe path easier than a direct edit. For common requests, a small configuration file or a form that creates a reviewable change can hide most of the Terraform details while still keeping the actual deployment in code.

Keep the underlying configuration understandable and have the network team review the plan before it runs. That gives them a way to learn the new workflow without asking them to become Terraform specialists on day one.

Think of this as a governance and ownership change as much as a tooling choice. If the network team is expected to maintain the environment, involve them in the repository layout, review rules, and training early. Otherwise the code can become a bottleneck that people work around.

It can also help to separate responsibilities: a platform team owns shared connectivity and landing-zone foundations, while application teams request or manage only the network pieces they’re allowed to change. The exact repository split is less important than having clear boundaries and one approved path for changes.

Full Terraform management is a reasonable target for the steady-state network, but I wouldn’t promise that every operational event will fit neatly into it. Disaster recovery or other emergency actions can alter resources outside the normal workflow, which may leave Terraform’s state or configuration out of sync.

Document how to handle those cases: what can be changed during an incident, who records it, and how the code and state get reconciled afterward. Test that recovery process before relying on it. That’s not an argument against infrastructure as code, just a reminder to plan for exceptions.