IaC operations is the day-2 discipline of running infrastructure as code after the code is written: discovering what already exists, validating and policy-checking changes, planning and deploying through approvals, detecting drift, managing remote state, estimating cost, and keeping an audit trail. Writing Terraform or OpenTofu is day-1 work. Operating it safely over time is IaC operations, and it is where most infrastructure risk lives. ops0 is built around this layer across Terraform, OpenTofu, and Oxid.
The phrase maps to the day-0, day-1, day-2 framing many teams use. Day-0 is design. Day-1 is the first build and deploy. Day-2 is everything after: change, drift, audit, cost, and incident response over the life of the infrastructure.
Writing IaC was never the hard part
The industry spent years improving how infrastructure code is written: better languages, modules, and generators. But a clean first apply is not the problem. The problem is the months and years after, when reality drifts away from code, ownership gets fuzzy, policies are checked too late, and nobody can answer simple questions about what is running.
IaC operations is the layer that keeps declared state and live state aligned, and keeps every change reviewable.
What IaC operations covers
The operating loop has a consistent set of stages, regardless of which engine you use:
Discovery. Scan live cloud across providers to find what exists, including resources that were never codified.
Validation. Run terraform validate or tofu validate on every change, plus IaC security scanning, before anything is planned.
Policy. Check changes against security and compliance policy as a gate, not as an afterthought, so unsafe changes are blocked before deploy.
Plan and apply. Produce a readable plan that shows additions, modifications, and destructive changes, then deploy approved plans through governed workflows.
State. Manage remote state on AWS S3, Google Cloud Storage, Azure Blob, or Oracle Object Storage, with locking handled safely.
Drift detection. Compare declared state with live cloud state on a schedule, and surface what diverged, who owns it, and what depends on it.
Cost. Estimate the cost impact of a change before apply, so expensive plans surface during review.
Blast radius and audit. Map dependencies before a change lands, and keep a record of plans, policy results, approvals, and outcomes for later review.
It has to work across engines and clouds
Real estates are not single-engine or single-cloud. IaC operations has to treat Terraform, OpenTofu, and Oxid consistently, and span AWS, GCP, Azure, and OCI. In ops0 the engine is selected per project, policies written for the HCL family apply across Terraform and OpenTofu, and an existing project can be transformed from one cloud provider to another while staying inside the same governed workflow.
That cross-engine, cross-cloud consistency is what separates an operating model from a single-project script.
Queryable state turns operations into answers
Mature IaC operations means you can ask direct questions about your estate instead of clicking through consoles. ops0 connects state from Terraform, OpenTofu, CloudFormation, and Oxid-backed projects so teams can query resources, drift, ownership, cost, and policy risk with repeatable questions rather than one-off investigations.
That is the difference between a static inventory and an operating model: the inventory tells you what existed at scan time, the operating model answers what exists now and what changed.
Why it matters
Incidents, audit findings, and surprise bills almost always trace back to the day-2 gap: a change that was not reviewed in context, drift nobody caught, a resource that was never codified, or a policy that ran too late. IaC operations closes that gap by making the whole life of a change reviewable, not only the first apply.
The bottom line
IaC operations is the discipline of running infrastructure as code safely over time, across engines and clouds. It covers discovery, validation, policy, plan and apply, state, drift, cost, blast radius, and audit as one connected loop. ops0 is built around that loop for Terraform, OpenTofu, and Oxid, so the hard part of infrastructure, the part that comes after the first deploy, stays under control.
What is IaC operations?
IaC operations is the day-2 discipline of running infrastructure as code after it is written: discovering existing resources, validating and policy-checking changes, planning and deploying through approvals, detecting drift, managing state, estimating cost, and keeping an audit trail across Terraform, OpenTofu, and Oxid.
How is IaC operations different from writing Terraform?
Writing Terraform or OpenTofu is day-1 work. IaC operations is everything after the first deploy: keeping declared state aligned with live state, governing changes, detecting drift, controlling cost, and preserving audit evidence over the life of the infrastructure.
What does day-0, day-1, day-2 mean for infrastructure?
Day-0 is design, day-1 is the first build and deploy, and day-2 is ongoing operations: change, drift, cost, audit, and incident response. IaC operations is the day-2 layer.
Does IaC operations work across multiple IaC engines and clouds?
It should. ops0 applies the same operating model across Terraform, OpenTofu, and Oxid, and across AWS, GCP, Azure, and OCI, with the engine selected per project and policies shared across the HCL family.
Why does IaC operations reduce risk?
Most incidents and audit findings come from the day-2 gap: changes reviewed without context, drift nobody caught, or resources never codified. IaC operations makes the full life of a change reviewable, not just the first apply.