Infrastructure as Code

Status: Stub Category: Infrastructure Default enforcement: Soft Author: PushBackLog team

Tags

• Topic: infrastructure, automation, devops
• Skillset: devops
• Technology: generic, cloud
• Stage: deployment, architecture

Summary

Infrastructure as Code (IaC) is the practice of defining, provisioning, and managing infrastructure through machine-readable configuration files rather than manual processes or interactive console operations. IaC applies software engineering practices — version control, code review, automated testing, and continuous deployment — to infrastructure management.

Rationale

Manually configured infrastructure is undocumented by default. The only complete record of what a manually provisioned environment contains is the environment itself. When it breaks, the recovery path is reconstruction from memory. When it needs to be replicated — for a new environment, a new region, or a disaster recovery scenario — the process is inconsistent, slow, and error-prone.

IaC makes infrastructure a first-class artifact of the codebase. Every resource, every configuration, every dependency is declared in version-controlled files. The infrastructure that runs in production is the infrastructure that was reviewed, tested, and approved through the same process as application code.

Guidance

Declarative vs. imperative

Most modern IaC tooling is declarative: you describe the desired state, and the tool determines how to reach it from the current state. This is more robust than imperative approaches, which describe the steps to take rather than the outcome to achieve.

Terraform, AWS CloudFormation, Pulumi (in declarative mode), and Kubernetes manifests are all declarative. Declarative IaC is idempotent by design — applying the same configuration multiple times produces the same result.

State management

Declarative IaC requires tracking the current known state of infrastructure, typically in a remote state file (Terraform’s terraform.tfstate, for example). Remote state:

• Must be stored in a durable, shared location (S3, GCS, Terraform Cloud)
• Must be locked during operations to prevent concurrent modification
• Must never be committed to source control (it often contains sensitive values)

Module organisation

Infrastructure code should be modular and composable:

• Modules encapsulate a logical set of resources (a VPC, a database cluster, a service deployment unit)
• Modules accept input variables and produce output values
• Common modules live in a shared library and are versioned like any other library dependency
• Environment-specific configuration (dev, staging, prod) passes different variable values to the same modules

Environments and promotion

Infrastructure changes follow the same promotion path as application changes:

1. Develop and test in a non-production environment
2. Review the plan (terraform plan or equivalent) before applying
3. Apply to staging and validate
4. Apply to production with an auditable record of who approved and when

terraform apply to production without a reviewed plan is equivalent to deploying untested code.

Secrets in IaC

Infrastructure configuration frequently references secrets — database passwords, API keys, TLS certificates. These must never appear in IaC files directly:

• Use references to a secrets manager (Vault, AWS SSM Parameter Store, AWS Secrets Manager)
• Use environment variables injected at apply time
• Audit IaC state files and outputs for accidental secret exposure

Testing IaC

Infrastructure code is testable:

• Lint and validate — terraform validate, tflint, cfn-lint
• Policy as code — tools like Open Policy Agent (OPA) or Checkov enforce security and compliance policies against IaC configurations before apply
• Integration tests — apply to a real (ephemeral) environment and test that the resulting infrastructure behaves as expected (Terratest, AWS CDK Assertions)

Common failure modes

Part of the PushBackLog Best Practices Library