Beginner 4 min read Updated: Sep 09, 2026

Infrastructure as Code (IaC): Declarative vs Imperative Principles & State Management

Understand Infrastructure as Code (IaC): contrast declarative and imperative methodologies, manage remote state files, prevent configuration drift, and integrate CI/CD pipelines.

In legacy IT operations, provisioning enterprise infrastructure required human systems administrators to log into web consoles (ClickOps), click through multi-page wizard dialogs, or execute ad-hoc terminal scripts on individual servers. This manual approach inevitably created Configuration Drift: disparate environments (Development, Staging, Production) diverged subtly over time, producing unexpected deployment bugs, undocumented security holes, and untraceable outages.

Infrastructure as Code (IaC) treats cloud and server infrastructure with the same engineering rigor as software source code. By defining compute, network, storage, and IAM policies in version-controlled text files, infrastructure becomes reproducible, auditable, testable, and automated.

Declarative vs Imperative Methodologies

IaC tooling is divided into two primary philosophical approaches:

Factor Declarative Infrastructure as Code Imperative (Procedural) Infrastructure as Code
Core Philosophy "What" the desired end-state should look like. "How" to execute step-by-step sequential commands to reach the state.
Engine Responsibility The IaC engine inspects the current live state, calculates the delta, and executes only the exact create/modify/delete actions required to match the code. The script executes every step in order. The author must explicitly write error handling, loops, and conditional checks for existing resources.
Idempotency Inherently idempotent: running the same code 10 times produces the exact same environment without duplicate resources or errors. Difficult to maintain idempotency: running an imperative script twice often fails (e.g. "Error: Resource already exists").
Drift Detection Native: can compare active cloud resources against the declared code manifests and alert on unmanaged manual changes. Minimal: imperative scripts execute commands and terminate without maintaining a persistent model of the cloud state.
Primary Tooling Terraform (HCL), OpenTofu, AWS CloudFormation, Azure Bicep, Kubernetes Manifests. Bash Scripts, PowerShell Scripts, AWS CLI / Azure CLI, Python SDKs (boto3).

Declarative Example: HashiCorp Configuration Language (HCL)

In a declarative model, the engineer simply declares the desired infrastructure end-state:

main.tf (Terraform Declarative Manifest) 
# Declare an enterprise AWS VPC with exact CIDR and tagging
resource "aws_vpc" "production_vpc" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name        = "prod-core-vpc"
    Environment = "Production"
    ManagedBy   = "Terraform"
  }
}

The Critical Role of State Management

Declarative engines like Terraform require a State File (terraform.tfstate) to function. The state file acts as the source of truth that maps declared code identifiers to real-world cloud resource IDs (e.g. mapping aws_vpc.production_vpc to vpc-0a1b2c3d4e5f):

  • Remote State Backends: In enterprise engineering teams, state files must never reside on local developer laptops. They are stored in secure remote backends—such as an AWS S3 bucket with versioning and SSE-KMS encryption or an Azure Blob Storage container.
  • State Locking: When an engineer or CI/CD pipeline runs a deployment, the engine acquires an atomic distributed lock (via AWS DynamoDB or Azure Blob lease). This strictly prevents concurrent executions from corrupting the state file.
Security: Protecting IaC State Files
State files often contain sensitive unencrypted data, including database passwords, TLS private keys, and administrative credentials returned by cloud APIs. Restrict access to the remote state bucket with strict IAM policies and enforce encryption-at-rest.

Immutable Infrastructure vs Mutable Configuration Management

Modern cloud architecture distinguishes between infrastructure provisioning and host configuration:

  • Mutable Configuration Management (Ansible / Puppet / Chef): Deploys base virtual machines and applies in-place configuration scripts over SSH/WinRM. Over time, in-place patching can introduce subtle differences between running servers.
  • Immutable Infrastructure (Packer / Terraform / Containers): Servers are never updated in place. When a software update or patch is required, a new golden image (AMI/VHD) is baked with Packer, deployed with Terraform, and the old instances are terminated. This "Pets vs Cattle" model eliminates configuration drift completely.

Preventing Configuration Drift in CI/CD

Modern DevOps workflows automate IaC through continuous integration and continuous deployment (CI/CD) pipelines:

  1. Pull Request (PR): An engineer proposes an infrastructure change via Git.
  2. Automated Plan: The CI pipeline runs terraform plan, outputting the exact list of additions, modifications, and destructions.
  3. Static Security Analysis: Tools like Checkov or TFLint scan the plan for security violations (e.g. detecting an S3 bucket with public read access or unencrypted EBS volumes).
  4. Peer Review & Merge: Senior engineers approve the pull request.
  5. Automated Apply: The pipeline merges to main and executes terraform apply -auto-approve, eliminating human console intervention.

Summary

Infrastructure as Code is the bedrock of enterprise cloud maturity. By embracing declarative frameworks, maintaining secure remote state with locking, adopting immutable infrastructure patterns, and automating drift detection through GitOps CI/CD pipelines, organizations eliminate snowflake servers, guarantee deployment repeatability, and maintain an immutable audit trail of every infrastructure change across their cloud environments.

Code copied to clipboard!