What is IaC (infrastructure as code)?
Infrastructure as code (IaC) means describing IT infrastructure such as servers, networks and services in code and provisioning it automatically, rather than clicking it together manually. Infrastructure thereby becomes versionable, reproducible and reviewable — just like application code.
Also known as: infrastructure as code · declarative infrastructure · Bicep · Terraform · ARM templates
Where IaC is used
Instead of creating cloud resources by hand through a console, IaC describes the desired target state in files — often declaratively. Tools such as Bicep, ARM templates or Terraform read this description and create or update the infrastructure accordingly. The result is always the same, regardless of who runs it.
This makes it possible to build environments such as test and production identically, trace changes through version control and restore reproducibly in case of failure. IaC is therefore a central foundation for reliable, automated cloud operating models.
A practical example
A complete Azure environment — including network, services and security components — is described entirely in code. Through a pipeline, this description is rolled out automatically, so a new environment can be built identically to the existing one in a short time. Manual configuration errors are eliminated and every change is documented traceably.
How it relates & how smiit uses it
IaC describes the provisioning of infrastructure, while CI/CD automates the building and shipping of software; both are building blocks of the DevOps way of working and often interlock. For Claimity AG, smiit implemented the entire GDPR-compliant Azure infrastructure as infrastructure as code with DevOps pipelines — the basis for taking the SaaS platform live reproducibly and securely in just six weeks.
Common mistakes & misconceptions
- Infrastructure as Code is often reduced to scripts; what matters is the declarative, versioned and reproducible approach rather than manual one-off commands.
- Many believe IaC code written once stays correct forever; manual changes to the infrastructure quickly cause configuration drift between code and reality.
- People underestimate that IaC definitions must be treated like application code — with reviews, tests and secure handling of secrets.
Frequently asked questions
What is the difference between declarative and imperative IaC?
Declarative IaC describes the desired target state, and the tool works out the necessary steps itself. Imperative IaC explicitly defines the sequence of steps. In the cloud, declarative approaches such as Bicep or Terraform are common.
Why is IaC so important for the cloud?
Cloud environments are complex and change frequently. IaC ensures that environments stay reproducible, traceable and consistent instead of drifting apart through manual intervention.
What is "configuration drift" and how does IaC help against it?
Configuration drift occurs when the actual state of an environment deviates from the documented target due to manual changes. Since IaC captures the target state in code and applies it reproducibly, drift can be detected and the environment brought back to the defined state.
Doesn't IaC increase the initial effort?
At the start the effort is higher, because the infrastructure first has to be described in code. This extra effort pays off as soon as environments are built, changed or restored repeatedly — manual steps are then more error-prone and slower.
Should secrets such as passwords be stored in IaC files?
No. Secrets do not belong in plain text in versioned IaC files, as these would otherwise expose sensitive data. Instead they are referenced through secure vaults or secret management and only resolved at runtime.
Related terms
Sources & further reading
Want to put this topic to work in your company?
Updated · Back to the glossary