Infrastructure as Code (IaC) with Terraform: audit, implementation, CI/CD

Manual configuration vs Terraform: what breaks at scale

While infrastructure is three servers, everything rests on the engineer's memory: they remember where they brought up the reverse proxy, which parameter they changed in the config, why one node has a nonstandard connection limit.

Terraform changes the model itself: state is described in code and stored in a state file, not in someone's head or in chat. As soon as machines number in the dozens, manual server configuration stops being reproducible — and this shows up at the most inconvenient moment.

A typical breakdown looks mundane. The environment was updated according to a checklist, some steps were skipped — and within a week the environments diverge: different dependency versions, different load balancer rules, a different set of utility scripts.

Errors during environment updates surface only in production, because no one measures or compares configuration discrepancies.

Rollback in such a scheme is also manual. There is no artifact from which the previous state is brought up — there is a disk snapshot of unknown freshness and the hope that it matches reality.

Recovery after a failure stretches into hours: the engineer repeats step by step what a colleague once configured, and each step is a new point for error.

Scaling infrastructure multiplies the cost of these discrepancies: what was fixed on three nodes with two commands turns into a separate stream of tasks and late-night troubleshooting on thirty.

We will break down how this is addressed with a declarative description, what exactly is translated into code, and why Terraform here is not a fad but a way to remove manual operations from the change process.

What infrastructure as code provides: measurable effects

Infrastructure described as code stops being a set of manual settings: servers, networks, load balancers, and access rights are created from files in the repository.

The same description deploys identical environments — test, pre-production, and production differ only in parameters, not in the set of forgotten commands. This is reproducibility: the environment stops depending on who assembled it and in what order.

Recovery time for a lost environment is reduced from days to hours: the description has already been reviewed and tested, and state is brought to the recorded one with a single Terraform operation.

Configuration drift goes away — unaccounted changes through the control panel no longer accumulate, because any change passes through the repository and review.

Rollback of changes becomes predictable: the previous version of the description is deployed just as routinely as the new one, and the edit history shows who changed what.

The share of incidents due to manual edits falls — typical causes such as “the setting was fixed on only one server” disappear along with the method of editing itself.

A new environment for an urgent project or a load test run is brought up in hours, not weeks of manual assembly and approvals.

The result is managed infrastructure: changes are planned in advance, applied reproducibly, and rolled back without emergencies, while the number of failures decreases with each release.

Comparison of approaches to infrastructure description in Terraform

The declarative approach in Terraform describes not a sequence of actions but a target state: the engineer records which resources should exist and how they are connected, and the tool itself calculates the difference with the actual configuration.

This determines whether an environment is reproducible from scratch, whether a change can be rolled back, and whether the cause of a discrepancy between stands is clear.

Automation limitations almost always grow out of the last two rows of the table: where state is not described in code, any run requires manual intervention.

In practice, the declarative base covers the network, clusters, and access, while scripts remain only for what has not yet been migrated. How this unfolds step by step is covered in the implementation practice below.

How implementation proceeds: stages of engineering work

Terraform implementation is a sequence where each stage ends with a verifiable artifact: a resource map, a module schema, a report on a run against a copy of the environment.

The order is fundamental — without an audit, the schema will remain theory, and without acceptance checks, the first run in production will turn into an experiment.

1. Infrastructure audit. Compare the actual state according to provider data with what is described in code and recorded in state. Record discrepancies, manual edits, and unmanaged resources — these are exactly what derail the first run.
2. Schema design. Split the description into modules by domains: network, compute, storage, access. Define state boundaries so that an edit in one domain does not affect the others, and unified naming rules.
3. Environment setup. Set up shared state storage with locking, separate configurations for each environment, and move secrets out of code. Import existing resources — without recreating them.
4. Acceptance checks on a copy of the environment. Deploy the environment from scratch and check a re-run: it should not change anything. Separately review recovery, rollback, and behavior when removing a dependency.
5. Embedding into the pipeline. A change passes format and plan validation before apply, and apply happens after a colleague approves. Policies block irreversible operations, and edit history remains in the version control system.
6. Handover to operations. Hand over modules, the change procedure, and troubleshooting for typical failures, and train the team. We guide the first changes together until the engineer can perform them independently.

What remains with the customer: configurations, schemas, procedures

Infrastructure described in Terraform code delivers value only when your team can read and change it without us. That is why we hand over not a “working repository” but an engineering package: description, structure, rules, and the change workflow. Below is what exactly remains in your hands.

• Infrastructure module structure. What is reused, what is a wrapper for a specific environment, which parameters are required, and what the module depends on.
• Environment structure. How many there are, how they differ, in what order a change passes through them, and which values are overridden in place.
• Access policies. Who plans changes, who approves apply, how secrets are issued, and who reads state files.
• Network and connectivity schema. Subnets, routes, entry points, and filtering rules: which service talks to which and why.
• Change procedure. The path of an edit from branch to production: plan review, approval, apply window, and rollback to the previous state.
• Infrastructure documentation. How to bring up an environment from scratch, where variables are stored, and what to check before merging a change.
• Recovery procedure. Actions in case of state loss or erroneous resource deletion — with decision points where a human makes the call.

The description is updated together with the code: an edit without a documentation change does not pass review. That is why six months later the schema matches reality, not the original intention.

Case: moving manual infrastructure under code management

The customer is a product team with three environments: development, test, production. Stands were assembled manually according to an internal instruction: an engineer configured the network, load balancing, databases, and access rights in sequence.

A new environment for a task took two to three days to bring up, and the result depended on who exactly performed the steps.

We described the infrastructure as code in Terraform: networks, machines, databases, access policies, and connections between them.

Manual actions were replaced with descriptions in the repository, changes pass review and are applied according to a plan — before apply, you can see exactly what will change.

Edit history is preserved, and rollback is performed by reverting to the previous version of the description.

What changed

Environment deployment was reduced from two or three days to 30–40 minutes, and the same result is obtained regardless of who runs the build. Discrepancies between test and production environments stopped accumulating: the configuration is described once and reused.

Metrics before and after

• Environment build: 2–3 days → 30–40 minutes
• Incidents due to configuration discrepancies: several per month → isolated per quarter
• Environment recovery after a failure: hours of manual work → applying the description in tens of minutes

Reviewing changes before apply closes a class of errors that used to be found already in production.

What to do if the infrastructure is already configured manually?

Manual infrastructure does not need to be recreated: running resources are described declaratively and connected to Terraform state, so nodes, networks, load balancers, and access rules remain in service, and their configuration becomes reproducible.

After that, changes go only through the description, and discrepancies between the described and actual state are detected by regular checks, not at the moment of failure.

The choice of strategy depends on the number of environments and the amount of time available for revision.

They usually start with what changes rarely and is expensive: network, access rights, storage, routing rules.

Having described them, the team gets a reproducible framework, on top of which it adds applications and services, while manual edits are gradually displaced by drift checks.

This order reduces risk: each step is reversible, and the result is visible in the reduction of unplanned changes.

In projects where part of the infrastructure remained manual, our first step was to collect a resource inventory and compare it with the actual state — this gave the scope of work before migration began. Describe your environments, and we will come back with an estimate and a migration plan.

Common technical questions about implementation and support

Before starting, customers ask the same questions: what to do if the Terraform description has diverged from the actual state, whether implementation can be done without stopping services, who is responsible for changes, and what will happen to infrastructure support after handover. Below are short answers to technical concerns.

Can implementation be done without stopping services?

Yes. Resources are created alongside running ones, switching is managed and reversible, and state is recorded before and after. Downtime is needed only where the service itself requires it.

How is responsibility for changes divided?

Edits go through an agreed procedure: description, change review, apply. Who prepares, who approves, and what counts as a rollback are fixed before the start.

What will happen to support if we are left without a contractor?

The description, access roles, and release procedure remain with you in working form — they can be handed over to your team or another contractor without rewriting from scratch.

How is the security of edits verified?

Changes pass review before apply, access is granted by role, and actions are logged. It is visible who changed what and on what basis.

Let's discuss your task and come back with a work plan

To come back with a plan rather than generalities, we need one conversation and access to the current state of the infrastructure. Describe what already works and what hurts: manual edits in the console, discrepancies between environments, slow releases, lack of change history. Then we proceed step by step — the result is visible at each stage, and the scope can be adjusted.

• We clarify the environments: environments, providers, critical services, and boundaries that must not be crossed.
• We conduct an audit of the current state — how resources are created, where the description is maintained manually, what discrepancies have already accumulated.
• We assemble a target infrastructure schema: reusable modules, separation by environment, state storage, access rules.
• We prepare a scope estimate: how many configurations to describe, what is migrated as is, and what requires rework.
• We agree on a phased implementation plan, with control points and a clear order of service migration.
• We define rollback: how to return the previous state if a stage goes wrong and something breaks in production.
• We launch the first stage and connect checks into the release process — after that, changes go only through code.

Describe your task in a convenient format — we will come back with an estimate, scope of work, and plan.

The first conversation is devoted to technical matters: it is important for us to understand your constraints and how releases are structured today, not to sell a cooperation format.

In this conversation, Terraform is a tool, not an end in itself: if there is no point in describing some environments with code, we will say so directly.