Infrastructure as code (IaC) means that servers, networks and permissions are not created by clicking in an admin console, but through a text file that describes what should exist. A tool reads this file and produces the described state [1]. The file is therefore both at once: the instruction and the documentation.

A construction plan helps make a design reviewable and repeatable. Similarly, IaC describes the intended structure of a cloud environment. Whether the running environment matches that plan, and whether it can be recovered in an emergency, still require separate checks.

This article explains the concept and the two terms everything hinges on in practice: state and drift. Product names appear only in the second-to-last section.

What the problem was: the environment nobody can rebuild

Manual provisioning creates servers, firewall rules and permissions individually. Without consistent documentation, it becomes hard to reconstruct which settings belong together and why they were chosen.

A typical case. A team runs a test environment and a production environment. Both were built by hand, a year apart, by different people. A bug occurs only in production. The question of how the two environments differ is one nobody can answer, and exactly that answer would be half the debugging. A code comparison reveals intended differences. Deviations in the running environments still need to be detected separately.

During recovery, a versioned description reduces dependence on memory and manual instructions. IaC can reprovision infrastructure. Operational data, secrets and external dependencies additionally require appropriate backups and tested recovery procedures.

Declarative and imperative

There are two ways of thinking about describing infrastructure. Imperative means: a sequence of commands. Create a server, then open the port, then install the package. Declarative means: a description of the goal. There should be a server with an open port and an installed package.

Many common tools work declaratively [2], reconciling the environment with the described target. The important property is repeatable execution without unwanted duplicate effects. Command sequences can also be designed for this; the notation alone does not guarantee that behaviour.

State: connecting code and resources

How a tool manages state varies: some maintain a separate state file, while others use state held by the cloud service. A state file connects the description with the actual resources [3].

For a tool with a separate state file, access control, backups and enabled locking matter. Losing the file can require recovery or re-importing resources; uncoordinated writes can corrupt state. The file may also contain sensitive values. Terraform for teams explains the team workflow.

Drift: when reality deviates

Drift happens when someone changes things past the description: a quick move in the admin console, a fast fix in an emergency. The environment and its description then tell different stories.

Such deviations can go unnoticed if code is assumed to reflect the current environment without checking it. Routine changes should go through code. Emergency changes are documented and reconciled afterwards; recurring checks report detected deviations [4].

What can be reviewed before anything happens

An important checkpoint lies between describing and applying a change. A preview shows planned actions, such as creating or replacing a resource. Its coverage depends on the tool and the properties it tracks; tests and review of the plan actually executed remain necessary.

Teams put the plan into the merge request: a second person sees that the change would delete a database before it does. Automated rules check the same plan for violations, such as a storage share open to the internet. These checks complement security controls in the running environment.

Example: Terraform, OpenTofu, Bicep and AWS CDK

Terraform supports many cloud providers through providers. OpenTofu is an open-source fork with a related configuration language [5]; versions and provider compatibility need checking when switching. Bicep describes Azure resources whose state Azure manages. AWS CDK generates CloudFormation templates from languages such as TypeScript or Python.

Choose based on the target platform, required resources, team knowledge and operating model. Shared principles are versioned code, controlled changes and review before execution. State management, importing resources and change previews differ between tools.

Key takeaway

Infrastructure as code describes infrastructure and automates its provisioning. Versioning and reviews make changes traceable. Recovery also requires data backups and tested restoration procedures.

What you can decide afterwards

  • Whether an existing environment built by hand should be captured as code or rebuilt.
  • How routine and emergency changes remain traceable and drift is detected.
  • Which platform, resource and team requirements determine your tool choice.

Frequently asked questions

Is infrastructure as code the same as GitOps?

No, but they build on each other. IaC describes the infrastructure as a file. GitOps makes the repository with these files the single source of truth and continuously reconciles the environment against it.

Does it pay off for small environments too?

Yes. Small environments also benefit from traceable settings and repeatable changes. Clear documentation, controlled access and a recovery plan help prevent operations from depending on a single person.

Can I capture an existing environment as code after the fact?

Often, yes. Import capabilities and supported resources vary by tool and provider. Before the first apply, review the captured configuration and planned changes to avoid unintended modifications or recreation.

Sources

Read on

Engineering practice Terraform for teams: state, modules, review Fundamentals What is GitOps? Engineering practice Azure Landing Zone: building blocks, decisions, mistakes Service Cloud Engineering at Hueskotech