Infrastructure as Code (IaC) Principles: Declarative vs Imperative

In the pre-cloud era, setting up a new application environment required a system administrator to sit down, follow a 20-page runbook, and manually click through menus or execute terminal scripts. This manual approach caused configuration drift (where staging and production silently diverged) and snowflake servers (one-of-a-kind servers that nobody knows how to rebuild if they crash). Infrastructure as Code (IaC) treats your infrastructure with the exact same rigor as application code—version-controlled in Git, peer-reviewed via pull requests, and tested in CI/CD pipelines.

Declarative vs Imperative Paradigms

There are two fundamentally different approaches to writing Infrastructure as Code:

Feature	Declarative Approach (The "WHAT")	Imperative Approach (The "HOW")
Core Philosophy	You define the desired end state of the infrastructure. The engine figures out the step-by-step diff to achieve it.	You write step-by-step procedural commands telling the system exactly how to configure resources sequentially.
Idempotency	Inherently Idempotent. Running the template 10 times results in the exact same state without duplicate resources.	Hard to maintain idempotency. Running a bash script twice might create duplicate virtual machines or crash on port conflicts.
State Tracking	Maintains an explicit state file to detect deleted or modified resources.	Typically stateless; executes commands blindly against targets.
Industry Tools	Terraform, AWS CloudFormation, Azure Bicep, Kubernetes YAML.	Bash scripts, Python Boto3 scripts, AWS CLI, Ansible (procedural).

Key IaC Properties: Idempotency & Drift Detection

Idempotency: An operation is idempotent if executing it once has the exact same result as executing it multiple times. If your IaC code declares: "VPC with 3 subnets", running apply when 3 subnets already exist will do nothing (zero changes).
Configuration Drift: Occurs when an engineer bypasses code and manually modifies cloud settings in the AWS/Azure web console (e.g., opening port 22 on a firewall). Modern IaC engines detect this drift during the plan stage and automatically revert manual unauthorized changes back to the declared code state.
Immutability: Instead of logging into a running server to patch software in-place, cloud-native IaC destroys old virtual machines and launches freshly baked, updated machine images (Immutable Infrastructure).

Frequently Asked Questions (FAQ) - Student & Interview Review

Q1. What is a 'Snowflake Server' in cloud operations?

A snowflake server is a virtual machine that has been manually configured and tweaked over years with unique, undocumented packages and hotfixes. Because no one knows its exact configuration, it cannot be reliably reproduced or backed up, creating a severe single point of operational risk.

Q2. Why is Git the ideal single source of truth for infrastructure?

By storing IaC code in Git, engineering teams gain an immutable historical audit trail of who changed what resource, when it changed, and why (via commit messages). If an infrastructure update introduces an outage, the team can roll back the cloud infrastructure simply by reverting the Git commit.

Explore Related Cloud Computing Tutorials & Next Steps

Broaden your enterprise cloud architecture and DevOps expertise across our curriculum:

Terraform Infrastructure as Code (IaC)

Master the multi-cloud declarative HCL language used by thousands of engineering organizations.

CloudFormation & Azure Bicep IaC

Compare cloud-native infrastructure code tools tailored specifically for AWS and Azure ecosystems.

Shared Responsibility Security Model

Embed security scanning tools (Checkov, tfsec) into IaC code to catch misconfigurations before deployment.

120+ Cloud Computing Interview Questions

Core interview questions on declarative vs imperative IaC, state locking, and configuration drift.