Infrastructure as Code

---
name: infrastructure-as-code
description: "Provides guidance and best practices to define, manage, and audit cloud infrastructure via code, ideal when automating provisioning and ensuring repeatable environments."
metadata:
  tags: "infrastructure-as-code, devops, cloud, terraform, cloudformation, drift-detection, version-control"
  source: "https://skilldb.dev/skills/devops-cloud-skills/infrastructure-as-code"
  pack: "devops-cloud-skills"
  category: "Technology & Engineering"
---

# Infrastructure as Code

## When to use this skill
Use when the user says things like:
- "how do i implement infrastructure as code"
- "provision cloud resources from code"
- "set up drift detection and state management"
- "enforce tagging and secret management in IaC"


## Core Philosophy
Infrastructure as Code treats infrastructure provisioning and configuration as a
software engineering discipline. Every server, network, database, and permission
is defined in version-controlled code that can be reviewed, tested, and reproduced
deterministically. The principle is simple: if it is not in code, it does not exist.
Manual changes are the enemy of reliability, auditability, and disaster recovery.

## Key Techniques
- **Declarative Definitions**: Describe the desired end state of infrastructure
  and let the tool determine the steps to achieve it. Terraform HCL and
  CloudFormation YAML are declarative; scripts are imperative.
- **State Management**: Maintain a state file that maps declared resources to
  real infrastructure. Remote state backends (S3, GCS) with locking prevent
  concurrent modifications and enable team collaboration.
- **Modular Composition**: Package reusable infrastructure components as modules
  with well-defined inputs and outputs, enabling consistent patterns across teams.
- **Plan Before Apply**: Always generate and review an execution plan before
  making changes. The plan shows exactly what will be created, modified, or
  destroyed.
- **Drift Detection**: Periodically compare actual infrastructure state against
  the declared configuration to detect and remediate manual changes.
- **Environment Parity**: Use the same modules with different variable files to
  create identical dev, staging, and production environments.

## Best Practices
- Store all IaC in version control alongside application code or in a dedicated
  infrastructure repository with the same review processes.
- Use remote state with locking. Local state files cause conflicts and data loss
  in team environments.
- Never hardcode secrets in IaC files. Reference secret managers or inject at
  apply time via environment variables.
- Tag every resource with owner, environment, project, and cost center for
  visibility and cost attribution.
- Write automated tests for infrastructure modules using tools like Terratest
  or kitchen-terraform.
- Pin provider and module versions to prevent unexpected behavior from upstream
  updates.
- Use workspaces or directory structures to isolate environments, never share
  state between production and non-production.

## Common Patterns
- **Hub-and-Spoke Networking**: A central networking module provisions VPCs, subnets,
  and peering; application modules consume network outputs as inputs.
- **GitOps for Infrastructure**: Merge to main triggers automated plan and apply,
  with pull request plans serving as the review mechanism.
- **Layered Stacks**: Separate long-lived foundational infrastructure (networking,
  IAM) from frequently changing application infrastructure to reduce blast radius.
- **Self-Service Modules**: Provide pre-approved, parameterized modules that
  application teams can use without deep infrastructure knowledge.

## Anti-Patterns
- ClickOps — making infrastructure changes through cloud console UIs. These changes
  are untracked, unrepeatable, and invisible to the team.
- Monolithic state files containing hundreds of resources. A single failed apply
  can block all infrastructure changes.
- Copying and pasting infrastructure code instead of creating reusable modules.
- Ignoring state file security. State contains sensitive data including resource
  IDs, IP addresses, and sometimes passwords.
- Applying changes without reviewing the plan first. A single misconfiguration
  can destroy production databases.
- Not implementing proper IAM for the IaC pipeline itself. The CI/CD service
  account that applies infrastructure changes is a high-value target.