I'm a senior systems administrator on a small team that has traditionally managed an on-premises environment through the GUI. We're about to move our test and development workloads—roughly a couple hundred virtual machines—into Azure. I've been learning Azure and experimenting with Bicep in a personal tenant, and it seems clear that consistent deployments will become difficult without using infrastructure as code (IaC). The challenge is that I'm currently the only person on the team who is comfortable writing code.
I'm considering creating standardized Bicep templates for resources such as Windows VMs, then exposing only approved choices through a manually triggered GitHub Actions workflow. Administrators could select values such as the VM name, subnet, VM size, and tags, while the template handles the underlying configuration and standards.
Initially, I'm thinking of using IaC mainly for consistent day-one deployments rather than managing the full lifecycle of every VM. This seems like a practical way to introduce automation without requiring the rest of the team to become expert programmers immediately. However, I'm concerned about configuration drift, template maintenance, permissions, workflow safety, and becoming the only person who can fix or update the system.
For teams that have made a similar transition from traditional click-based administration to Azure IaC, what approach worked? Would you recommend Bicep, Terraform, Azure Template Specs, or another platform? What pitfalls should we plan for, and how can we help less code-oriented administrators adopt the process?
5 Answers
For an Azure-only environment, Bicep is a perfectly sensible choice. It avoids the separate state-file management that Terraform requires and integrates directly with Azure. Azure Verified Modules, Template Specs, and the Cloud Adoption Framework can provide useful building blocks and recommended patterns.
You can wrap approved modules in your own simpler modules, hard-code the parts that should never vary, and expose only safe parameters such as name, location, size, subnet, and tags. Bicep parameter metadata can also provide allowed-value lists in deployment interfaces, which makes the experience more approachable for administrators who are not yet comfortable with the code.
Don’t stop at deploy-once templates indefinitely. Azure APIs, resource providers, and VM requirements change, and old templates can eventually stop working even while existing machines continue running. If the template is not also the source of truth, you’ll have to deal with drift and won’t know whether a VM still matches the intended standard.
A gradual approach is fine: start with day-one provisioning, but define how updates, resizing, tagging, extensions, and retirement will eventually be handled. Use pull requests, validation, linting, policy checks, and narrowly scoped deployment identities. Manual changes should be limited to documented exceptions or emergency break-glass access.
That’s my main concern. I want to introduce repeatable deployments without creating a process that only I can maintain, so the initial scope would be deliberately small while the team builds confidence.
Your proposed workflow is a reasonable starting point, but treat it as a bridge rather than the final operating model. Build a small, reusable VM deployment first, document every step, and demonstrate the benefits to the team: repeatability, faster recovery, consistent tagging, and easier auditing. Then gradually add other repeatable activities.
The important part is getting at least one other administrator comfortable editing parameters and making small template changes. If everyone can only click a deployment button while you maintain the code, you become the bottleneck and people will eventually bypass the process with manual portal changes.
IaC is only part of the solution. Establish the Azure operating model first: subscriptions, management groups, network design, identity and RBAC, naming, tagging, logging, budgets, and Azure Policy. Policy can enforce many standards regardless of whether someone deploys through Bicep, a pipeline, or the portal.
A landing-zone approach and verified modules can prevent expensive brownfield cleanup later. Make the pipeline a safe self-service interface, but don’t hide all of the operational knowledge behind it. The team still needs to understand what gets deployed, how to troubleshoot it, and how to change it safely.
Make the first example something people can actually see and use. Build a complete VM pattern with its network interface, disks, monitoring, extensions, security settings, and approved image choices, then provide both deployment and removal procedures. Keep the boring, organization-specific details in the module and expose a short, friendly parameter file.
Run a team workshop where everyone deploys the example in a lab, reviews the output and logs, and makes a small change. Pairing, clear SOPs, and a safe sandbox will usually reduce the fear of coding more effectively than simply handing people training links. Leadership also needs to allocate time for learning; otherwise the process will remain dependent on one enthusiastic person.
Terraform is worth considering if you genuinely expect to manage multiple clouds, but it does not make Azure code automatically portable. You still write provider-specific resources and patterns, and state management adds another operational concern. For an Azure-focused team, Bicep may have the lower barrier to entry.