Infra as Code on Backend Engineering Strategy Tools

Configuration Management — Puppet, Chef, Salt

Wed, 03 Jun 2026 00:00:00 +0000

Before Terraform, before Kubernetes, before immutable infrastructure — configuration management tools were how you kept servers in a known state. Puppet, Chef, and Salt are the main players. All three solve the same core problem: a fleet of servers that should all look a certain way, continuously enforced.

They predate the cloud-native era and show their age in places, but they are still running in a lot of enterprise environments and still the right tool in some specific contexts.

The shared model

All three follow a similar pattern:

You describe the desired state of a system (packages installed, files present, services running, users configured)
An agent runs on each managed node and enforces that state continuously
Changes are made by updating the desired-state declaration, not by SSHing in and running commands

This is fundamentally different from Ansible’s push model — Puppet, Chef, and Salt agents pull or receive configuration rather than waiting for a push. The continuous enforcement is the key property: a manual change to a managed server gets corrected on the next agent run.

Puppet

Model: declarative DSL, agent pulls catalog from Puppet Server on a schedule (default 30 min).

Language: Puppet DSL — a declarative, domain-specific language for describing resources. Not a general programming language.

package { 'nginx':
 ensure => installed,
}

service { 'nginx':
 ensure => running,
 enable => true,
 require => Package['nginx'],
}

file { '/etc/nginx/nginx.conf':
 source => 'puppet:///modules/nginx/nginx.conf',
 notify => Service['nginx'],
}

Puppet Forge: a large community module library — the main reason Puppet still has traction. Many vendors publish official Puppet modules for their software.

Where it lives: large enterprise environments that adopted it early and built significant module libraries around it. The inertia is real — migrating away is a significant project.

Chef

Model: agent-based, Ruby DSL. Configuration is written as cookbooks containing recipes.

Language: Ruby — specifically a DSL built on Ruby. More expressive than Puppet’s DSL, but requires Ruby knowledge and brings the associated complexity.

package 'nginx'

service 'nginx' do
 action [:enable, :start]
end

template '/etc/nginx/nginx.conf' do
 source 'nginx.conf.erb'
 notifies :restart, 'service[nginx]'
end

Chef Solo vs Chef Server: Chef Solo runs without a server — cookbooks live locally or in version control. Chef Server is the full model with a central catalog and reporting. Knife is the CLI for managing Chef infrastructure.

Where it lives: similar story to Puppet — enterprises that adopted it early. Chef introduced the “infrastructure as code” framing before it was a widely used term. Less common in new projects, but still found running in organisations that built their automation around it.

Salt

Model: agent-based (minions), master/minion architecture, ZeroMQ message bus for fast communication. Can also run agentless (SSH mode) like Ansible.

Language: YAML state files (SLS), with Jinja templating. More approachable than Puppet DSL or Chef Ruby.

nginx:
 pkg.installed: []
 service.running:
 - enable: True
 - require:
 - pkg: nginx

/etc/nginx/nginx.conf:
 file.managed:
 - source: salt://nginx/files/nginx.conf
 - watch_in:
 - service: nginx

Speed: the ZeroMQ bus makes Salt significantly faster than Puppet or Chef for large fleets — sending a command to thousands of nodes and getting results back is near-instant.

Event-driven: Salt has a reactor system — events on nodes can trigger automatic responses. More dynamic than Puppet or Chef’s scheduled pull model.

Where it lives: still used in organisations that needed to manage very large fleets efficiently. SaltStack was acquired by VMware, then Broadcom — commercial trajectory uncertain. The open-source Salt project continues.

Comparison

	Puppet	Chef	Salt
Language	Puppet DSL	Ruby	YAML + Jinja
Model	Agent, pull	Agent, pull/push	Agent, push (ZeroMQ)
Learning curve	Medium	High (Ruby)	Medium
Scale	Good	Good	Excellent
Community	Large (Forge)	Medium	Medium
Status	Declining (new projects)	Declining	Uncertain (VMware/Broadcom)

Where they still make sense

Long-lived fleets of traditional VMs or bare metal — if you have thousands of servers that are not containers and are not going away, a continuous enforcement model still makes sense. Terraform provisions them; Puppet/Chef/Salt keeps them configured.

Network devices — see Ansible for this use case; Ansible is the clearer choice, but Salt also has network automation modules.

Legacy enterprise — if the organisation has already built a Puppet or Chef codebase, migrating everything to a new tool is a significant project with real risk. Maintaining the existing automation often makes more sense than rewriting it.

The general direction

New projects in the cloud-native era rarely reach for these tools. Immutable infrastructure (build a new image, replace the server) removes the need for continuous configuration enforcement. Kubernetes handles application configuration. Terraform handles provisioning. The gap these tools filled is smaller now.

That said, not all infrastructure is cloud-native, and “replace everything” is rarely a realistic option in a large organisation. These tools will be running in enterprise environments for years.

Principles

A few rules of thumb that hold regardless of which tool you use:

Only production requirements belong in production. If a package, service, or configuration isn’t needed by the workload, it shouldn’t be there. Every additional component is a potential failure point and a maintenance burden. Configuration management makes it easy to declare everything — resist the temptation.

Separate CI from CD. The pipeline that builds and tests your code is not the pipeline that applies configuration to servers. Keeping them separate means you can change one without touching the other, and failures in one don’t cascade.

KISS — as few moving parts as possible. Configuration management stacks can grow complex fast: roles, profiles, hieradata, environments, external node classifiers. Start with the simplest thing that enforces the state you need. Add complexity only when the simple version demonstrably can’t handle the requirement.

Crossplane

Wed, 03 Jun 2026 00:00:00 +0000

Crossplane is Kubernetes-native infrastructure management. Where Terraform runs as a CLI tool that applies changes and exits, Crossplane runs as a controller inside a Kubernetes cluster and continuously reconciles infrastructure — the same control loop model as Kubernetes itself.

Cloud resources become Kubernetes objects. You kubectl apply an RDS instance the same way you apply a Deployment. Crossplane’s controllers watch those objects and make the API calls to converge actual infrastructure to the desired state.

Core concepts

Providers extend Crossplane with CRDs for a specific cloud. provider-aws adds Kubernetes resources for every AWS service — S3 buckets, RDS instances, VPCs. Apply a provider, get hundreds of new resource types.

Managed Resources (MRs) are the individual cloud resources:

apiVersion: s3.aws.upbound.io/v1beta1
kind: Bucket
metadata:
 name: my-assets
spec:
 forProvider:
 region: eu-central-1
 tags:
 Environment: prod

Crossplane creates this bucket and keeps it in sync. If someone deletes it outside of Crossplane, the controller recreates it.

Composite Resources (XRs) are the powerful part. You define your own CRDs — a Platform or DatabaseCluster — that compose multiple managed resources. A developer applies a DatabaseCluster and gets an RDS instance, a subnet group, a parameter group, and security groups, all wired together, without needing to know any of the details.

XRDs (Composite Resource Definitions) define the schema for composite resources — what fields the developer sees, what defaults apply.

Compositions define how a composite resource maps to managed resources — the implementation behind the abstraction.

The platform engineering model

Crossplane’s real value is as a platform layer. A platform team owns the Compositions — they define what a “compliant database” or “standard app environment” looks like. Dev teams consume the simplified abstractions without touching the underlying cloud resources.

Self-service infrastructure with guardrails baked in.

vs Terraform

Crossplane and Terraform are not direct alternatives — they solve the problem differently.

Terraform is a CLI tool: run plan, review, apply, exit. State is a file. Good for human-in-the-loop workflows and one-off provisioning.

Crossplane is a control plane: always running, always reconciling. Better for continuous enforcement and self-service platforms. More complex to set up and operate.

In practice: Terraform for provisioning foundational infrastructure (clusters, networks, accounts). Crossplane for what runs on top of the cluster — letting application teams provision their own databases, queues, and object storage through Kubernetes-native APIs.

Upbound

The commercial platform behind Crossplane. Managed control plane hosting, a marketplace of providers and compositions, and tooling for building and publishing your own platform APIs. Worth evaluating if you are building a serious internal platform.

Learning curve

Steep. You need to understand Kubernetes controllers, CRDs, and the Crossplane composition model before you can be productive. The payoff is a genuinely powerful platform abstraction — but it is not a beginner tool.

A good framing: Crossplane is a digital twin of your infrastructure. The cluster holds the desired state of everything — cloud resources, application configuration, other tools — and continuously reconciles reality to match it.

Genuinely cool and worth learning if you have a cluster. The provider model has expanded well beyond cloud infrastructure — from v2 onwards Crossplane can manage applications, not just infra. There are also providers for Ansible and Terraform/OpenTofu, which means Crossplane can be the orchestration layer that drives other IaC tools. One control plane to rule them all.

The prerequisite is the cluster itself. If you already run Kubernetes, Crossplane is a natural extension of the same model you already operate. If you do not, it is not the tool to start with.

Infrastructure Testing — Molecule, Test Kitchen, InSpec, Chainsaw

Wed, 03 Jun 2026 00:00:00 +0000

Infrastructure code needs testing like application code does. The tools here cover different layers: role testing, integration testing, compliance checking, and Kubernetes end-to-end testing.

Molecule — Ansible role testing

Molecule is the standard testing framework for Ansible roles and playbooks. It manages the full test lifecycle: spin up instances, apply the role, verify the result, tear everything down.

Stages:

molecule create # spin up test instances (Docker, Podman, EC2, etc.)
molecule converge # apply the role/playbook
molecule verify # run assertions
molecule destroy # clean up
molecule test # full cycle in sequence

Drivers control where instances run — Docker or Podman for local development, EC2 or other cloud providers for closer-to-production testing.

Verifiers run assertions after converge. The default is Ansible itself (run a playbook of assertions), but Testinfra (pytest-based) and Goss are popular alternatives.

A minimal molecule/default/molecule.yml:

driver:
 name: docker

platforms:
 - name: instance
 image: ubuntu:22.04

provisioner:
 name: ansible

verifier:
 name: ansible

Wire into CI: molecule test runs the full cycle and exits non-zero on failure.

Test Kitchen — integration testing for infrastructure

Test Kitchen (kitchen.ci) is an integration testing framework originally built for Chef but now multi-platform. It creates instances, applies configuration, runs a verifier, and destroys.

Drivers: Docker, Vagrant, and cloud providers (EC2, GCP, Azure). Plugins also exist for Ansible (kitchen-ansible) and Terraform (kitchen-terraform).

Verifiers: InSpec (most common), Busser.

A kitchen.yml for a Chef cookbook:

driver:
 name: docker

provisioner:
 name: chef_zero

verifier:
 name: inspec

platforms:
 - name: ubuntu-22.04

suites:
 - name: default
 verifier:
 inspec_tests:
 - test/integration/default

kitchen list # show instance state
kitchen converge # apply provisioner
kitchen verify # run verifier
kitchen test # full cycle

Test Kitchen is less commonly adopted outside Chef shops, but the multi-platform support means it can be useful for testing across providers in one framework.

InSpec — compliance testing as code

InSpec (now Progress Chef InSpec) is a compliance testing framework. You write assertions about the state of a system — packages installed, ports listening, file permissions, user accounts — in a Ruby DSL. InSpec executes them locally, over SSH, against Docker containers, or against cloud APIs.

describe package('nginx') do
 it { should be_installed }
end

describe service('nginx') do
 it { should be_running }
 it { should be_enabled }
end

describe port(80) do
 it { should be_listening }
end

describe file('/etc/nginx/nginx.conf') do
 its('mode') { should cmp '0644' }
end

Profiles are the distributable unit — a collection of controls with metadata. The InSpec community maintains profiles for CIS benchmarks, DISA STIGs, and other compliance standards.

Where it fits: compliance auditing, security baselines, post-deploy verification. Wired into CI as a final gate or run on a schedule against production.

inspec exec path/to/profile --target ssh://user@host
inspec exec path/to/profile --target docker://container-id

Chainsaw — Kubernetes e2e testing

Chainsaw is a declarative end-to-end testing framework for Kubernetes. Originally from the Kyverno project, now standalone. Write test scenarios in YAML — apply manifests, assert on resource state, clean up — without writing Go or any test framework code.

Particularly useful for testing Kubernetes operators, controllers, and admission webhooks: the things that are hard to unit test because they depend on the Kubernetes API.

apiVersion: chainsaw.kyverno.io/v1alpha1
kind: Test
metadata:
 name: basic-deployment
spec:
 steps:
 - name: create deployment
 try:
 - apply:
 resource:
 apiVersion: apps/v1
 kind: Deployment
 metadata:
 name: test-app
 spec:
 replicas: 2
 # ...
 - assert:
 resource:
 apiVersion: apps/v1
 kind: Deployment
 metadata:
 name: test-app
 status:
 readyReplicas: 2
 - name: cleanup
 try:
 - delete:
 ref:
 apiVersion: apps/v1
 kind: Deployment
 name: test-app

chainsaw test ./tests/

vs Terratest for Kubernetes: Terratest requires Go code; Chainsaw is YAML. For testing Kubernetes resources and operators specifically, Chainsaw is simpler to write and maintain.

Terratest — Go-based infrastructure testing

Covered in the Terraform page. The short version: Go tests that deploy real infrastructure, run assertions via cloud SDKs, then tear it down. The most complete integration testing approach for Terraform modules — and the highest cost in setup and test execution time.

Choosing

Tool	Best for	Language
Molecule	Ansible role testing	YAML + Python/Ansible
Test Kitchen	Multi-platform integration testing	YAML + Ruby (InSpec)
InSpec	Compliance assertions, security baselines	Ruby DSL
Chainsaw	Kubernetes operators and controllers	YAML
Terratest	Terraform module integration testing	Go

Pulumi

Wed, 03 Jun 2026 00:00:00 +0000

Pulumi takes the same approach as AWS CDK — use a real programming language to define infrastructure — but without the CloudFormation layer underneath. Pulumi talks directly to cloud APIs, maintains its own state, and supports multiple clouds from a single codebase.

Languages: TypeScript, Python, Go, Java, C#, and YAML. Same language across all supported clouds.

How it works

Write infrastructure as code in your language of choice. Pulumi runs the program, builds a desired-state graph, diffs against current state, and makes the API calls to converge.

import * as aws from "@pulumi/aws";

const bucket = new aws.s3.Bucket("assets", {
 versioning: { enabled: true },
 tags: { Environment: "prod" },
});

export const bucketName = bucket.bucket;

pulumi preview # show planned changes
pulumi up # apply
pulumi destroy # tear down

State

Pulumi manages state like Terraform — a backend stores what resources exist and their current configuration. Options:

Pulumi Cloud — hosted, free tier available, adds secrets management and team features
S3 / GCS / Azure Blob — self-managed, same pattern as Terraform’s remote backend

vs Terraform

The core tradeoff: Pulumi gives you a real programming language (real loops, real functions, real tests) at the cost of a smaller ecosystem and less community tooling than Terraform. HCL is a constraint but also a simplicity — Terraform configurations are declarative and readable without needing to understand the language runtime.

Pulumi is the better choice when infrastructure logic is genuinely complex enough to benefit from a real language. For straightforward cloud resources, Terraform’s declarative HCL is often simpler to read and maintain.

vs AWS CDK

Both use real languages. The difference: CDK generates CloudFormation and inherits all of CloudFormation’s limitations (see the CDK page). Pulumi talks directly to cloud APIs, which means better drift visibility, faster deploys, and support outside AWS.

Testing

Because infrastructure is code, it tests like code:

Unit tests with Jest (TypeScript), pytest (Python), or Go test — test the resource graph without deploying
Integration tests that deploy to an isolated stack and assert against live infrastructure

OpenTofu / Terraform note

After HashiCorp changed Terraform’s licence to BSL in 2023, the community forked it as OpenTofu. If the licence change matters to your organisation, OpenTofu is a drop-in replacement. Pulumi was not affected.

Only explored in POC and lab contexts, not production. The honest take: Pulumi feels like the Gradle of IaC. The real-language argument is compelling in theory — proper loops, functions, tests, abstractions — but in practice it is easy to get wrong, and HCL’s constraint is also its strength. A Terraform configuration is readable by anyone; a Pulumi TypeScript codebase requires understanding the language runtime and the person who wrote it.

The cases where Pulumi wins: complex infrastructure logic that genuinely benefits from a real language, or teams already deep in a single language who want infrastructure to live alongside application code. For standard cloud infrastructure, Terraform is the lower-friction choice.

Ansible

Mon, 01 Jan 2024 00:00:00 +0000

Ansible is an open-source automation tool for configuration management, application deployment, and orchestration. The key selling point: it’s agentless — you push from a control machine over SSH, no daemon running on managed hosts.

Why Ansible

Free and open source — Red Hat maintains it, commercially supported via Ansible Automation Platform (formerly Tower)
Agentless — no software to install on managed nodes; plain SSH is enough
Simple — playbooks are YAML, readable without special knowledge
Flexible — works on servers, cloud platforms, network devices, and bare-metal

What it does

Configuration management — define what state a system should be in; Ansible gets it there and keeps it there.

Application deployment — deploy multi-tier applications with a playbook; let Ansible figure out the ordering and state transitions.

Orchestration — coordinate complex workflows across databases, networks, front-end and back-end services in the right order.

Security and compliance — enforce firewall rules, user policies, and security baselines across all hosts from a single playbook run.

Cloud provisioning — provision infrastructure on AWS, Azure, GCP, OpenStack, or bare-metal with the same tooling.

Architecture

Modules — small programs pushed to nodes over SSH, executed, then removed. Ansible ships with 750+ modules for packages, services, files, cloud APIs, and more.

Plugins — extend Ansible’s core: connection types, callbacks, caching, filtering. Write your own or use community plugins.

Inventory — a file (INI or YAML) listing all managed hosts, their IPs, groups, and variables. Can also pull dynamic inventory from AWS, GCP, Azure, etc.

Playbooks — YAML files describing tasks to run on which hosts. The core unit of work. Each play maps a group of hosts to a set of tasks; each task calls a module.

APIs — extend connection transports beyond SSH (WinRM for Windows, network device APIs, etc.).

Ansible Automation Platform

Red Hat’s commercial wrapper around Ansible. Adds a web UI, RBAC, job scheduling, audit logging, and a workflow editor. Worth it once you have multiple teams running automation.

Where Ansible still excels

Network device configuration is the clearest remaining stronghold. Ansible has mature modules for switches, routers, and firewalls (Cisco IOS, Arista EOS, Juniper JunOS, and many others) and the agentless SSH model works well for network gear that can’t run an agent. For network automation, Ansible is still state of the art.

For server configuration management — the original use case — most teams should consider moving to other models. Terraform manages provisioning, container images handle application configuration (immutable infrastructure), and Kubernetes operators handle runtime state. The gap Ansible used to fill is smaller.

The configuration management landscape

Ansible is one of several tools in this space. The others worth knowing:

Salt (SaltStack) — agent-based, event-driven, fast for large fleets. More complex than Ansible.
Puppet — agent-based, declarative DSL, strong in enterprise. Puppet Forge has a large module library.
Chef — agent-based, Ruby DSL, infrastructure as code before the term was common. Less common now.

See Configuration Management — Puppet, Chef, Salt for a full comparison.

All four predate the Kubernetes era. Ansible has survived best because it is agentless and YAML-based — lower barrier. The others are still found in large enterprise environments with long-lived infrastructure.

Resources

AWS CDK

Mon, 01 Jan 2024 00:00:00 +0000

AWS CDK (Cloud Development Kit) lets you define infrastructure using real programming languages — Java, TypeScript, Python — rather than a DSL. You write code, CDK synthesizes it into a CloudFormation template, and CloudFormation deploys it to AWS.

The appeal is obvious if your team lives in Java: familiar language, familiar tooling, loops and abstractions, unit tests with JUnit. No HCL to learn.

In practice it is slower and more cumbersome than it looks, and the CloudFormation layer underneath causes real problems.

How it works

Write Java (imperative)
mvn package — compile and run unit tests
cdk synth — generate the CloudFormation template
cdk diff — compare deployed stack with current state (optional)
cdk deploy — deploy stack to AWS via CloudFormation
CloudFormation makes the API calls to AWS

The key thing to understand: CDK does not talk to AWS directly. It generates CloudFormation, and CloudFormation does the work. Everything downstream of cdk synth is CloudFormation behaviour, not CDK behaviour.

The CloudFormation problem

CloudFormation does not track changes made outside of stacks. Someone logs into the console and modifies a security group — CloudFormation does not know, your CDK code does not know, and cdk diff will not show it. That is drift, and it accumulates silently until a deployment overrides something that was manually changed in production, or a cdk destroy removes something that was depended on.

CloudFormation does have a drift detection feature, but it is not part of the normal workflow — you trigger it manually from the console, it shows you the diff, and then expects you to go fix it yourself.

Compared to Terraform, which maintains its own state file and surfaces drift explicitly in terraform plan, this is a meaningful operational weakness.

Cross-stack dependencies

Splitting infrastructure into smaller stacks is the right instinct — smaller blast radius, faster deploys, clearer ownership. The problem is how CloudFormation handles values shared between stacks.

When Stack A exports a value (a VPC ID, a security group ARN) and Stack B imports it, CloudFormation creates a hard dependency. You cannot modify or delete that export while any other stack is consuming it. CloudFormation will block the update and leave you stuck — Stack A cannot deploy because the export is in use, and Stack B may be in a broken state because it depends on something that no longer exists as expected. Getting out requires carefully coordinating the removal of the import before you can change the export.

The fix: use SSM Parameter Store instead of CloudFormation exports.

Stack A writes its outputs to SSM:

StringParameter.Builder.create(this, "VpcIdParam")
 .parameterName("/infra/vpc/id")
 .stringValue(vpc.getVpcId())
 .build();

Stack B reads from SSM at deploy time:

String vpcId = StringParameter.valueForStringParameter(this, "/infra/vpc/id");

No CloudFormation export, no hard dependency, no blocked deployments. Stacks can be updated and deployed independently. SSM also gives you a clean place to browse shared infrastructure values and reference them from outside CDK (application config, scripts, other tools).

Testing

Testing in CDK is limited to validating the synthesized CloudFormation template — you are not testing infrastructure behaviour, you are testing that your code generates the JSON you expect:

Unit tests — JUnit assertions against the synthesized template (e.g. “does this stack contain an S3 bucket with versioning enabled”)
Integration tests — deploy to an isolated environment and validate via AWS SDK
No native plan/apply preview; you must deploy to see what actually happens

Pros

Familiar Java constructs — loops, conditionals, reusable classes
Full IDE support, refactoring, type safety
Unit testing with JUnit
Good for teams already invested in Java who want infrastructure close to application code

Cons

Generates CloudFormation — debugging complex stacks means reading generated JSON/YAML
More boilerplate than HCL for straightforward infrastructure
Drift detection relies on CloudFormation, which has no visibility into out-of-band changes
Importing existing infrastructure can be awkward
Smaller community example base compared to Terraform, especially in Java vs TypeScript/Python
Deployments are slower than Terraform’s direct API approach

vs Terraform

For repeatable, standardised infrastructure with a clear plan/apply workflow and reliable drift detection, Terraform is the stronger choice. CDK makes sense when infrastructure is deeply coupled to application code and the team is committed to a single language across both.

Resources

AWS CDK documentation
AWS CDK API reference
CDK Patterns — community example library
AWS CDK GitHub

Terraform

Mon, 01 Jan 2024 00:00:00 +0000

Terraform is HashiCorp’s infrastructure-as-code tool: you declare what infrastructure you want in HCL (HashiCorp Configuration Language), and Terraform figures out how to create, update, or destroy resources to match that declaration. It works across providers — AWS, GCP, Azure, Kubernetes, GitHub, and hundreds more — through a plugin architecture.

Core concepts

Providers are plugins that translate Terraform resources into API calls. Declared in required_providers:

terraform {
 required_providers {
 aws = {
 source = "hashicorp/aws"
 version = "~> 5.0"
 }
 }
}

provider "aws" {
 region = "eu-west-1"
}

Resources are the things you’re managing — an EC2 instance, an S3 bucket, a DNS record:

resource "aws_s3_bucket" "assets" {
 bucket = "my-app-assets"
}

resource "aws_s3_bucket_versioning" "assets" {
 bucket = aws_s3_bucket.assets.id
 versioning_configuration {
 status = "Enabled"
 }
}

Data sources read existing infrastructure without managing it — useful for referencing shared resources:

data "aws_vpc" "main" {
 filter {
 name = "tag:Name"
 values = ["main"]
 }
}

State

Terraform tracks what it has created in a state file (terraform.tfstate). This is the source of truth for what exists — Terraform computes diffs against state, not live infrastructure.

In teams, state must be stored remotely and locked during operations:

terraform {
 backend "s3" {
 bucket = "my-terraform-state"
 key = "prod/terraform.tfstate"
 region = "eu-west-1"
 dynamodb_table = "terraform-locks"
 }
}

Never commit state files to version control — they contain secrets and will diverge between team members.

The plan/apply cycle

terraform init # download providers, initialise backend
terraform plan # show what will change — read this carefully
terraform apply # create/update/destroy resources
terraform destroy # tear everything down

terraform plan is the key step: it shows exactly what Terraform intends to do before touching anything. Review the plan — a + is create, ~ is update in-place, -/+ is replace (destroy and recreate), - is destroy.

Variables and outputs

Variables make configurations reusable:

variable "environment" {
 type = string
 default = "staging"
}

resource "aws_instance" "app" {
 ami = "ami-0abc123"
 instance_type = var.environment == "prod" ? "t3.medium" : "t3.micro"
 tags = {
 Environment = var.environment
 }
}

Pass values via terraform.tfvars, environment variables (TF_VAR_environment), or the -var flag.

Outputs expose values after apply — useful for passing information between modules:

output "bucket_name" {
 value = aws_s3_bucket.assets.bucket
}

Modules

Modules are reusable, composable units of Terraform configuration — a directory of .tf files called as a block:

module "vpc" {
 source = "terraform-aws-modules/vpc/aws"
 version = "5.0.0"

 name = "main"
 cidr = "10.0.0.0/16"
 azs = ["eu-west-1a", "eu-west-1b"]
}

Encapsulate common patterns (a standard VPC setup, an ECS service, a Lambda with IAM role) in a module rather than repeating the same resources across configurations.

Multiple environments

Workspaces exist but are limited — shared state, easy to confuse, no real isolation. The two patterns that actually work in practice:

Folder per environment — envs/dev/, envs/staging/, envs/prod/ each have their own backend config and tfvars. Explicit, auditable, easy to reason about. The downside is duplication across env directories, mitigated by shared modules.

Terragrunt — a thin wrapper around Terraform that eliminates the duplication. Environments inherit from a root config, each only overrides what differs. One place to bump a module version and it propagates everywhere.

Terragrunt

Terragrunt solves the main friction of the folder-per-environment pattern: repetition. Backend config, provider version, module source — these are the same across every environment. Terragrunt lets you define them once at the root and inherit downward.

A typical layout:

infra/
 terragrunt.hcl # root config — backend, provider defaults
 dev/
 terragrunt.hcl # env-level overrides
 vpc/
 terragrunt.hcl # module call
 eks/
 terragrunt.hcl
 prod/
 terragrunt.hcl
 vpc/
 terragrunt.hcl
 eks/
 terragrunt.hcl

The root terragrunt.hcl defines the remote state pattern once:

remote_state {
 backend = "s3"
 config = {
 bucket = "my-terraform-state"
 key = "${path_relative_to_include()}/terraform.tfstate"
 region = "eu-west-1"
 }
}

Each module’s terragrunt.hcl just declares its source and inputs:

include "root" {
 path = find_in_parent_folders()
}

terraform {
 source = "git::https://github.com/myorg/terraform-modules.git//vpc?ref=v1.4.0"
}

inputs = {
 cidr = "10.1.0.0/16"
 environment = "dev"
}

Key commands:

terragrunt plan # plan a single module
terragrunt apply # apply a single module
terragrunt run-all plan # plan all modules in a directory tree
terragrunt run-all apply # apply all, respects dependency order

run-all handles dependency ordering automatically — if eks depends on vpc, Terragrunt applies vpc first.

Testing and validation

Terraform has multiple layers of validation, from syntax checking to full integration tests against real infrastructure.

Syntax and input validation

terraform validate # checks syntax, module references, variable constraints
terraform plan # dry run — shows exactly what will change before touching anything

validate catches configuration errors early. plan is the key safety step — a + is create, ~ is update in-place, -/+ is replace, - is destroy. Read it before every apply.

Native unit tests (v1.6+)

Tests live in .tftest.hcl files alongside the configuration. run blocks execute a plan or apply in isolation; assert blocks check the result:

run "vpc_has_correct_cidr" {
 command = plan

 assert {
 condition = aws_vpc.main.cidr_block == "10.0.0.0/16"
 error_message = "VPC CIDR does not match expected value"
 }
}

Run with terraform test. Good for validating modules before promotion.

Integration testing

For end-to-end validation against real AWS resources, Terratest is the most widely used framework — Go tests that deploy infrastructure, run assertions via the AWS SDK, then tear it all down.

Policy and compliance

OPA/Rego, Conftest, or HashiCorp Sentinel can enforce policies at plan time — before anything is deployed. Useful for ensuring security groups are not wide open, IAM roles follow least privilege, tags are present on all resources.

Beyond infrastructure

The industry standard, and the scope is wider than cloud resources. The provider model means anything with an API can be managed as Terraform code:

Database schemas and users — PostgreSQL, MySQL, MongoDB providers manage schemas, roles, and users as code. Database configuration follows the same plan/apply workflow as the VPC it runs in.
DNS — Route53, Cloudflare, and others are first-class providers. DNS changes go through version control and code review.
GitHub — repositories, teams, branch protection, secrets. Useful for managing org configuration at scale.
Kubernetes — namespaces, RBAC, CRDs. Useful for bootstrapping before other tooling runs.
Secrets management — Vault, AWS Secrets Manager, SSM Parameter Store all have providers.

The implication: Terraform can be the single source of truth for everything from network topology to application database users. One workflow, one state. If there is a provider for it, Terraform is probably the right tool.

Resources

Terraform documentation
Terraform Registry — providers and modules
terraform-aws-modules — well-maintained AWS module library
Terragrunt documentation

Infra as Code on Backend Engineering Strategy Tools

Configuration Management — Puppet, Chef, Salt

The shared model

Puppet

Chef

Salt

Comparison

Where they still make sense

The general direction

Principles

See also

Crossplane

Core concepts

The platform engineering model

vs Terraform

Upbound

Learning curve

Infrastructure Testing — Molecule, Test Kitchen, InSpec, Chainsaw

Molecule — Ansible role testing

Test Kitchen — integration testing for infrastructure

InSpec — compliance testing as code

Chainsaw — Kubernetes e2e testing

Terratest — Go-based infrastructure testing

Choosing

Pulumi

How it works

State

vs Terraform

vs AWS CDK

Testing

OpenTofu / Terraform note

Ansible

Why Ansible

What it does

Architecture

Ansible Automation Platform

Where Ansible still excels

The configuration management landscape

Resources

AWS CDK

How it works

The CloudFormation problem

Cross-stack dependencies

Testing

Pros

Cons

vs Terraform

Resources

Terraform

Core concepts

State

The plan/apply cycle

Variables and outputs

Modules

Multiple environments

Terragrunt

Testing and validation

Beyond infrastructure

Resources