Infrastructure as code (IaC) describes infrastructure — networks, servers, databases, cloud services and policies — in machine-readable files rather than configuring it by hand. Those files can be reviewed, versioned, tested and reused like application code.
Why it matters
- Consistency: environments are built the same way every time.
- Speed: new environments can be created in minutes.
- Auditability: every change is recorded and reviewed.
- Recovery: infrastructure can be rebuilt from code after an incident.
Declarative and imperative tools
Declarative tools such as Terraform, OpenTofu, AWS CloudFormation and Azure Bicep describe the desired end state and work out the steps. Configuration management tools such as Ansible configure software on servers. Many teams use both.
Good practice
- Store IaC in version control and require pull-request review.
- Run automated validation, security scanning and policy checks in pipelines.
- Keep secrets out of code; use a secrets manager.
- Use reusable modules for common patterns.
- Detect and correct drift between code and reality.
Policy as code
Policy engines can automatically block non-compliant changes — for example, public storage buckets or unencrypted databases — before they reach production.
6 best practices for safe infrastructure as code
- Store everything in version control. Every change should go through pull requests with peer review and an auditable history.
- Use modules. Reusable, versioned modules for networks, clusters and databases encode standards and reduce duplication.
- Separate environments. Keep state and credentials for development, test and production separate to limit the impact of mistakes.
- Plan before you apply. Always review the execution plan, and automate plans in CI so reviewers see the exact changes.
- Scan for policy violations. Policy-as-code tools can block insecure configurations, such as public storage buckets or open firewall rules, before deployment.
- Detect drift. Regularly compare real infrastructure with code and investigate manual changes.
Choosing tools
Declarative provisioning tools manage cloud and infrastructure resources, while configuration management tools handle operating system settings and software. Kubernetes manifests and GitOps controllers extend the same model to application deployment. Pick tools your team can support and that work across your target platforms.
Common mistakes to avoid
- Storing secrets in plain text in repositories.
- Letting state files become corrupted or shared without locking.
- Making emergency changes in the console and never reconciling them.
- Writing large monolithic configurations that are hard to review.
Frequently asked questions
Is infrastructure as code only for cloud?
No. Many tools manage on-premises virtualisation, network devices and storage as well.
How do we start with existing infrastructure?
Import critical resources into code gradually, starting with networks and shared services, and require code for all new resources.
A 90-day action plan
Days 1 to 30: choose a provisioning tool, set up a shared repository with branch protection and remote state with locking, and define naming and tagging standards.
Days 31 to 60: codify a standard network and one common environment, add automated plans to pull requests and introduce policy checks for security basics.
Days 61 to 90: require code for all new resources, import critical existing resources and schedule drift detection reports.
Questions to ask before you scale
- How will secrets be supplied without storing them in repositories?
- Who approves changes to production, and how is that enforced?
- How will reusable modules be versioned and published?
- How will emergency changes be reconciled with code afterwards?
- What training do operations staff need to work this way?
Key terms explained
- Declarative configuration: describing the desired end state rather than the steps to reach it.
- State file: a record of resources a provisioning tool manages.
- Drift: differences between the real environment and its definition in code.
- Policy as code: rules written as code and checked automatically.
- GitOps: using a Git repository as the source of truth for deployments.
The bottom line
Defining infrastructure in version-controlled code brings consistency, speed and auditability to IT operations. The benefits depend on discipline: peer review, reusable modules, separate environments, automated plans, policy checks and drift detection. Start with shared foundations such as networking, require code for new resources and import existing ones gradually. With time, teams spend less effort on manual configuration and more on improving services.
Further reading on infrastructure as code
For authoritative, vendor-neutral guidance on infrastructure as code, see the OpenTofu project. You can also browse our free whitepapers.
