Infrastructure as Code

Infrastructure as Code treats infrastructure configuration as a managed software artifact. Engineers describe desired resources, relationships, and settings in files that an IaC tool interprets to create or modify an environment. The approach can cover a single virtual machine or an entire multi-region platform, including identity, networking, storage, observability, and managed services.¹

The normal workflow stores these definitions in a version-control system, reviews proposed changes, and applies them through a repeatable command or delivery pipeline. This creates an auditable history and reduces dependence on undocumented manual steps. IaC is closely associated with DevOps, but it is also used by infrastructure, security, data-platform, and research-computing teams.

• Provisioning: creating infrastructure and its dependencies.
• Configuration: setting operating-system, application, or service parameters.
• Orchestration: coordinating resources across providers and environments.

IaC tools either describe the desired end state or prescribe the steps needed to reach it. A declarative configuration states that specified resources, properties, and relationships should exist; the tool compares that model with the real environment and calculates changes. Terraform and OpenTofu are prominent examples of this model, although many platforms combine declarative files with procedural hooks.¹⁵

Imperative approaches instead encode an ordered sequence of actions, often through scripts or general-purpose programming languages. They can express complex control flow, but repeated execution requires careful handling of partial failure and idempotence. Declarative systems do not eliminate procedural logic: providers, modules, startup scripts, and configuration-management tools may still perform imperative work inside a broader desired-state workflow.

Templates and modules add reuse, while variables and environment-specific inputs allow one definition to serve development, testing, and production without copying entire configurations.

Reliable IaC depends on an accurate representation of both intended and actual infrastructure. Many declarative tools maintain a state file or comparable inventory that maps configuration objects to provider resources; it helps determine whether an object must be created, updated, replaced, or removed.¹

When someone changes a resource outside the IaC workflow, the environment can develop configuration drift. A plan or reconciliation step can expose that divergence, but teams must decide whether to adopt the manual change, revert it, or revise the source configuration. Shared state requires access control, encryption, backups, and locking where supported. Secrets should generally be supplied through dedicated secret-management systems rather than committed to repositories.

Production delivery commonly separates planning from approval and applies changes through automated pipelines. Policy checks, static analysis, isolated test environments, and staged rollouts reduce the risk of destructive or overly broad changes.²³

IaC is also a governance and recovery practice, not merely a faster provisioning method. A complete repository can document dependencies, expose ownership, support reproducible disaster recovery, and make the differences between environments visible. Cloud teams may use policy as code to reject disallowed regions, public storage, weak encryption, or excessive permissions before deployment.

Several edge cases require special treatment. Import workflows bring pre-existing, manually created resources under management; replacement operations can cause downtime or data loss; and provider version changes can alter defaults or resource behavior. Ephemeral environments created for a branch or pull request can shorten testing cycles, but they need automated expiration to prevent cost accumulation. IaC can also manage hybrid estates that combine cloud services, on-premises systems, SaaS resources, and Kubernetes objects, although different tools may be needed for each layer.²⁴

The boundary between IaC and GitOps is not fixed: GitOps emphasizes reconciliation from a version-controlled source, while IaC more broadly includes any code-centered definition and automation of infrastructure.

Declarative configuration

A description of the desired infrastructure state, leaving the tool to determine the operations required to reach it.

Drift

A difference between infrastructure recorded or intended by IaC and the configuration that actually exists.

Provider

A plugin or integration that lets an IaC tool manage resources exposed by a cloud, platform, or service.

State file

A stored mapping between IaC configuration objects and the real resources they represent.

Policy as code

Machine-readable rules that evaluate or restrict infrastructure configurations and deployment plans.