Infrastructure as Code Explained: Terraform, State, Modules and Production Best Practices

Modern infrastructure can be created through cloud consoles, command-line tools, APIs, automation platforms, and configuration systems. The challenge appears when infrastructure grows beyond a few manually managed resources.

Imagine maintaining:

• Virtual machines
• Virtual networks
• Subnets
• Firewalls
• Load balancers
• Databases
• DNS records
• Storage
• IAM permissions
• Monitoring
• Multiple development, staging, and production environments

Manual configuration may work initially, but it becomes increasingly difficult to reproduce, audit, review, and maintain consistently as an environment grows.

Infrastructure as Code (IaC) changes that operating model by describing infrastructure in code or structured configuration files.

Instead of asking an engineer to manually create a network, deploy servers, configure permissions, and document the final result afterward, infrastructure can be represented as version-controlled configuration that is reviewed, tested, and applied through an automated workflow.

Google Cloud describes Infrastructure as Code as managing and provisioning infrastructure through configuration rather than relying on manual workflows. Its official Infrastructure as Code overview emphasizes reproducibility and repeatable deployments.

Terraform is one of the best-known tools associated with this model. The official Terraform documentation describes Terraform as an Infrastructure as Code tool for building, changing, and versioning infrastructure.

For the infrastructure concepts underneath IaC, see Cloud Computing Explained, Cloud Networking Explained, and Servers and Infrastructure Explained.

Table of Contents

1. What Is Infrastructure as Code?
2. IaC vs Manual Infrastructure
3. Benefits of Infrastructure as Code
4. Declarative vs Imperative Infrastructure
5. What Is Terraform?
6. The Terraform Workflow
7. Terraform Configuration Files
8. Providers, Resources, Variables and Outputs
9. Terraform Plan and Apply
10. Terraform State
11. Local State vs Remote State
12. Securing Terraform State
13. Terraform Modules
14. Root and Child Modules
15. Avoiding Over-Modularization
16. Configuration Drift
17. Terraform Import
18. IaC with Git and Pull Requests
19. Terraform in CI/CD
20. Provider Version Pinning
21. Multi-Cloud Infrastructure as Code
22. Terraform on AWS, Azure and Google Cloud
23. Terraform vs CloudFormation and Native IaC
24. Networking as Code
25. IAM and Security as Code
26. Terraform Secrets and Sensitive Values
27. Policy as Code
28. IaC, Auto Scaling and Immutable Infrastructure
29. IaC vs Configuration Management
30. Environment Separation
31. Testing Infrastructure as Code
32. Disaster Recovery
33. Platform Engineering and Standardization
34. Terraform Supply Chain Security
35. Observability and SIEM
36. Production IaC Architecture
37. Common IaC Mistakes
38. Production Checklists
39. Infrastructure as Code Learning Roadmap
40. Frequently Asked Questions

1. What Is Infrastructure as Code?

Infrastructure as Code is the practice of defining and managing infrastructure through machine-readable configuration rather than depending primarily on manual configuration.

The infrastructure itself may include:

Network
   |
   +-- Subnets
   +-- Routes
   +-- Firewalls
   +-- NAT
   |
Compute
   |
   +-- Virtual Machines
   +-- Auto Scaling
   |
Storage
   |
Databases
   |
IAM
   |
Monitoring

The key concept is that the desired infrastructure architecture becomes a version-controlled definition.

A simplified model looks like:

Git Repository
      |
      v
Infrastructure Code
      |
      v
IaC Engine
      |
      v
Cloud APIs
      |
      v
Infrastructure

The objective is not simply automation.

The more important objectives are:

• Reproducibility
• Traceability
• Consistency
• Controlled change
• Reviewability

2. Infrastructure as Code vs Manual Infrastructure

A manual cloud workflow might look like:

Engineer
   |
Cloud Console
   |
   +--> Create network
   +--> Create subnet
   +--> Create VM
   +--> Create firewall
   +--> Create database
   +--> Configure IAM

The environment may work correctly.

But six months later, another engineer may build a similar environment slightly differently.

You may end up with:

Environment A
Environment B
Environment C

where each environment contains undocumented differences.

Infrastructure as Code changes the source of truth:

Git Repository
      |
Infrastructure Definition
      |
Terraform
      |
Provider
      |
Cloud APIs
      |
Infrastructure

Instead of relying on memory or manual console operations, infrastructure changes can follow an engineering process.

3. Benefits of Infrastructure as Code

Infrastructure as Code can provide several important advantages.

The important distinction is that IaC converts infrastructure from an informal operational activity into an engineered and reviewable system.

4. Declarative vs Imperative Infrastructure

One of the most important IaC concepts is the difference between imperative and declarative approaches.

Imperative Infrastructure

An imperative process describes how to perform the change.

For example:

Create network
Create subnet
Create VM
Attach firewall
Start VM

The order of operations is part of the workflow.

Declarative Infrastructure

A declarative configuration describes what the final infrastructure should look like.

For example:

Network:
10.0.0.0/16

Subnets:
10.0.1.0/24
10.0.2.0/24

Web instances:
3

The IaC engine determines what actions are required to move the real environment toward the desired configuration.

Terraform primarily follows this declarative approach.

5. What Is Terraform?

Terraform is an Infrastructure as Code tool developed by HashiCorp.

Terraform allows engineers to describe infrastructure using declarative configuration and manage that infrastructure through providers.

A simple workflow is:

Write Configuration
        |
        v
 terraform init
        |
        v
 terraform plan
        |
        v
 Review Changes
        |
        v
terraform apply
        |
        v
 Infrastructure

HashiCorp’s official Terraform documentation covers the complete Terraform workflow and language.

Terraform can manage multiple types of platforms through providers.

Terraform
   |
   +--> AWS Provider --------> AWS APIs
   |
   +--> Azure Provider ------> Azure APIs
   |
   +--> Google Provider -----> Google Cloud APIs
   |
   +--> Kubernetes Provider -> Kubernetes API

HashiCorp’s provider documentation explains how providers connect Terraform configuration to external platforms and APIs.

6. The Terraform Workflow

The core Terraform lifecycle is straightforward:

Design
  ↓
Write
  ↓
Initialize
  ↓
Validate
  ↓
Plan
  ↓
Review
  ↓
Apply
  ↓
Monitor
  ↓
Detect Drift
  ↓
Update Code
  ↓
Plan Again

The familiar commands are:

terraform init
terraform fmt
terraform validate
terraform plan
terraform apply

Each serves a different purpose.

terraform init prepares the working directory and required providers.

terraform fmt formats Terraform configuration.

terraform validate checks whether configuration is structurally valid.

terraform plan calculates proposed infrastructure changes.

terraform apply performs approved changes.

7. Terraform Configuration Files

Terraform commonly uses .tf configuration files.

A small project may look like:

terraform-project/
├── main.tf
├── variables.tf
├── outputs.tf
├── versions.tf
├── terraform.tfvars
└── README.md

A common organizational pattern is:

main.tf
   |
Resources

variables.tf
   |
Inputs

outputs.tf
   |
Outputs

versions.tf
   |
Terraform / Provider Requirements

Terraform evaluates the configuration in a directory as one configuration rather than treating each .tf file as an independent deployment.

8. Providers, Resources, Variables and Outputs

Providers

Providers allow Terraform to communicate with external platforms.

Example:

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

Production environments should deliberately control provider versions rather than automatically accepting every future version.

Resources

A resource represents infrastructure Terraform manages.

Example:

resource "aws_instance" "web" {
  ami           = var.ami_id
  instance_type = var.instance_type

  tags = {
    Name = "web-server"
  }
}

Conceptually:

Resource Block
     |
Terraform Provider
     |
Cloud API
     |
Real Resource

Variables

Variables make configurations reusable.

Instead of:

instance_type = "t3.medium"

use:

instance_type = var.instance_type

with:

variable "instance_type" {
  type        = string
  description = "EC2 instance type"
}

This separates infrastructure logic from environment-specific values.

Outputs

Outputs expose values produced by infrastructure.

output "instance_id" {
  value = aws_instance.web.id
}

Another example:

output "public_ip" {
  value = aws_instance.web.public_ip
}

Outputs can be consumed by users, automation, or other Terraform modules.

9. Terraform Plan and Apply

One of Terraform’s most important commands is:

terraform plan

It compares the desired configuration with the managed infrastructure and produces a proposed execution plan.

Current Infrastructure
        +
Desired Configuration
        |
        v
Terraform Plan
        |
        +--> Create
        +--> Change
        +--> Destroy

This makes infrastructure changes reviewable.

A production workflow might look like:

Developer
   |
Commit
   |
CI Pipeline
   |
terraform plan
   |
Review
   |
Approval
   |
terraform apply

Then:

terraform apply

executes the approved operations.

If a plan says:

3 to add
0 to change
1 to destroy

the operator should understand why one resource will be destroyed before applying the plan.

Infrastructure automation should reduce human error, not eliminate human judgment.

10. Terraform State

Terraform state is one of the most important Terraform concepts.

Terraform needs to understand the relationship between configuration and the real infrastructure it manages.

Conceptually:

Terraform Configuration
          |
          v
        State
          |
          v
Real Infrastructure

If the configuration contains:

resource "aws_instance" "web" {
  # ...
}

Terraform must know which real cloud object corresponds to:

aws_instance.web

State provides that relationship.

The official Terraform state documentation explains how state tracks bindings between Terraform resource instances and real remote objects.

11. Local State vs Remote State

Terraform can maintain local state in:

terraform.tfstate

Local state can be acceptable for:

• Learning
• Laboratories
• Small personal projects

Team environments generally require a shared state architecture.

Developer A ----\
Developer B -----+--> Remote State
Developer C ----/

A shared backend helps avoid each engineer operating against a different local copy.

Remote state architectures may use cloud storage or managed Terraform platforms depending on organizational requirements.

12. Securing Terraform State

Terraform state must be treated as sensitive infrastructure data.

State and plan files can contain sensitive information depending on the configuration and providers being used.

A secure design may include:

Remote State
    +
Encryption at Rest
    +
TLS in Transit
    +
Access Control
    +
Versioning
    +
Audit Logging

Do not casually commit:

terraform.tfstate

to a public repository.

A secure remote-state architecture might look like:

Terraform Users
      |
Authentication
      |
State Backend
      |
      +--> Encryption
      +--> Authorization
      +--> Versioning
      +--> Auditing

HashiCorp’s Managing Sensitive Data documentation should be consulted when designing Terraform workflows involving credentials or secret values.

13. Terraform Modules

As configurations grow, one large configuration becomes difficult to manage.

Terraform modules provide reusable infrastructure components.

Example:

modules/
├── network/
├── database/
├── web-server/
├── load-balancer/
└── monitoring/

A root configuration may then compose those components:

Root Module
   |
   +--> Network Module
   |
   +--> Application Module
   |
   +--> Database Module
   |
   +--> Monitoring Module

HashiCorp’s Terraform modules documentation explains modules as collections of resources that can be reused and composed.

14. Root and Child Modules

Terraform distinguishes between a root module and child modules.

The directory in which Terraform runs directly is the root module.

It can call another module:

module "network" {
  source = "./modules/network"

  cidr_block = "10.0.0.0/16"
}

A module can expose inputs and outputs.

Input
  ↓
Module
  ↓
Output

Example:

variable "cidr_block" {
  type = string
}

output "vpc_id" {
  value = aws_vpc.main.id
}

This allows one network design to support:

Development
Staging
Production
Disaster Recovery

using different input values.

15. Avoid Over-Modularization

Modules improve reuse, but excessive abstraction can reduce clarity.

A deeply nested design such as:

Module A
   |
Module B
   |
Module C
   |
Module D

can become difficult to understand.

A good module should represent a meaningful architectural boundary.

Examples might include:

• Network
• Application
• Database
• Monitoring
• IAM

The goal is reusable architecture, not abstraction for its own sake.

16. Configuration Drift

Configuration drift occurs when real infrastructure changes outside the intended IaC workflow.

For example:

Terraform
   |
Creates Firewall Rule

Then an administrator changes the rule manually through the cloud console.

Now:

Declared Configuration
        ≠
Actual Infrastructure

This is drift.

Drift can cause:

• Security inconsistencies
• Deployment surprises
• Troubleshooting problems
• Reproducibility failures
• Compliance issues

Example:

Terraform:
Port 22 blocked

Cloud Console:
Port 22 manually opened

Emergency manual changes may sometimes be necessary.

The important operational rule is:

Reconcile emergency changes back into the managed infrastructure definition.

17. Terraform Import

Many organizations adopt Terraform after infrastructure already exists.

A migration may look like:

Existing Infrastructure
        |
Discover Resources
        |
Map / Import
        |
Create Terraform Configuration
        |
Validate
        |
Manage through IaC

This allows IaC adoption to happen incrementally rather than requiring a complete rebuild.

Importing a resource does not automatically mean the configuration is correct. The resource definition still needs to accurately represent the infrastructure you intend Terraform to manage.

18. Infrastructure as Code with Git

IaC becomes significantly more powerful when configuration is maintained in version control.

Example:

Git Repository
      |
      +--> main
      |
      +--> feature/network-change
      |
      +--> feature/database-change

Infrastructure can then follow a software-engineering workflow:

Branch
   ↓
Commit
   ↓
Pull Request
   ↓
Review
   ↓
Automated Validation
   ↓
Terraform Plan
   ↓
Approval
   ↓
Apply

This turns infrastructure changes from hidden console operations into reviewable engineering changes.

19. Terraform in CI/CD

A mature Terraform CI/CD pipeline may look like:

Developer
    |
Git Commit
    |
CI Pipeline
    |
    +--> terraform fmt
    +--> terraform validate
    +--> Security Scan
    +--> terraform plan
    |
Human Review
    |
Approval
    |
terraform apply

This connects infrastructure to the wider DevOps lifecycle.

Infrastructure no longer remains a manually managed island while application delivery becomes automated.

A modern engineering environment may combine:

Application Code
      +
Infrastructure Code
      +
Security Policy
      +
Monitoring
      +
CI/CD

20. Provider Version Pinning

Terraform providers are released independently.

A production configuration should intentionally constrain compatible versions.

Example:

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

Provider version control improves:

• Predictability
• Testing
• Reproducibility
• Change management

The principle applies to providers and reusable modules alike.

21. Multi-Cloud Infrastructure as Code

Terraform’s provider architecture allows a shared workflow to manage multiple systems.

Terraform
   |
   +--> AWS
   +--> Azure
   +--> Google Cloud
   +--> Kubernetes
   +--> SaaS
   +--> Other APIs

This can simplify tooling across heterogeneous environments.

However:

Common tooling does not mean identical cloud architecture.

AWS, Azure, and Google Cloud have different:

• Services
• Network models
• IAM concepts
• APIs
• Operational patterns

For the platform-level differences, see AWS vs Azure vs Google Cloud.

22. Terraform on AWS, Azure and Google Cloud

Terraform and AWS

Terraform can create AWS resources through the AWS provider.

Example:

provider "aws" {
  region = var.region
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

AWS also provides its own Infrastructure as Code platform, AWS CloudFormation. The official AWS CloudFormation documentation describes CloudFormation as a service for defining and managing AWS resources through templates and stacks.

Terraform and Azure

Terraform can manage Azure resources such as:

• Resource Groups
• Virtual Networks
• Subnets
• Virtual Machines
• Storage
• Load Balancers
• Databases

A basic provider configuration may look like:

provider "azurerm" {
  features {}
}

Microsoft also provides Azure-native infrastructure-definition technologies including ARM templates and Bicep. The Azure resource reference documents supported resource definitions.

Terraform and Google Cloud

Google Cloud also provides official Terraform support and documentation.

A simplified model:

Terraform
    |
Google Cloud Provider
    |
Google Cloud APIs
    |
    +--> VPC
    +--> Compute
    +--> Storage
    +--> Databases

The official Terraform on Google Cloud documentation covers Terraform workflows for Google Cloud infrastructure.

23. Terraform vs AWS CloudFormation

Terraform and CloudFormation overlap but are not identical.

The right tool depends on:

• Platform strategy
• Existing tooling
• Team skills
• Governance
• Architecture
• Multi-cloud requirements

The goal is not to select a tool because it is fashionable.

The goal is to select an infrastructure-management model that supports the required architecture and operations.

24. Networking as Code

Networking is one of the areas where IaC provides particularly strong value.

Infrastructure configuration can describe:

VPC / VNet
 |
 +-- Subnets
 |
 +-- Routes
 |
 +-- NAT
 |
 +-- Firewalls
 |
 +-- Load Balancers
 |
 +-- DNS
 |
 +-- VPN

A network architecture may look like:

                   Terraform
                       |
              +--------+--------+
              |                 |
           Network           Security
              |                 |
       +------+------+       Firewall
       |             |
   Public          Private
   Subnet          Subnet
       |             |
   LB / NAT      Application
                     |
                  Database

The same pattern can then be instantiated for:

Development
Staging
Production

with controlled differences.

For the underlying network design, see Cloud Networking Explained and Computer Networking Explained.

25. IAM and Security as Code

Infrastructure as Code can manage more than compute.

It may also define:

Users
Roles
Policies
Service Accounts
Managed Identities
Workload Permissions

This turns authorization into part of the infrastructure definition.

A complete environment might include:

Infrastructure Code
      |
      +--> Network
      +--> Compute
      +--> Storage
      +--> IAM
      +--> Monitoring

Security as Code

Reusable infrastructure components can encode secure defaults.

For example, an approved network module could automatically create:

Private Application Subnet
Restricted Inbound Rules
Centralized Logging
No Unrestricted Management Ports

This does not make infrastructure automatically secure.

It does make approved security patterns easier to reproduce.

The principles are closely related to Network Security Basics and Firewalls Explained.

26. Terraform Secrets and Sensitive Values

Secrets require special handling.

A dangerous pattern is:

variable "db_password" {
  default = "MySecretPassword123"
}

Configuration repositories should not become password vaults.

A better conceptual architecture is:

Terraform
    |
Secret Management System
    |
Sensitive Value

Terraform also supports sensitive variables:

variable "db_password" {
  type      = string
  sensitive = true
}

However, marking a value as sensitive primarily reduces accidental display. It does not automatically guarantee that the underlying value will never exist in Terraform state or plan data.

This is why HashiCorp’s sensitive data guidance is important for production workflows.

27. Policy as Code

Organizations can also represent governance requirements in machine-readable policy.

Examples include:

Public storage prohibited
Management ports restricted
Encryption required
Approved regions only
Mandatory tags required
Approved VM sizes only

Conceptually:

Infrastructure Code
       +
Security Policy
       |
       v
Automated Validation

This moves governance earlier into the deployment process.

Instead of relying only on a written policy:

Policy Document

the organization can move toward:

Executable Infrastructure Policy

28. IaC, Auto Scaling and Immutable Infrastructure

Infrastructure as Code and Auto Scaling

IaC can define the boundaries of an auto-scaling environment.

Example:

Minimum:
2

Desired:
4

Maximum:
20

The distinction is:

IaC:
Defines infrastructure configuration

Autoscaler:
Adjusts runtime capacity

IaC establishes the baseline.

Runtime automation adjusts capacity according to workload demand.

For the scaling model, see Cloud Auto Scaling Explained.

Immutable Infrastructure

Immutable infrastructure follows a related principle.

Instead of:

Old Server
   |
Repeated Manual Changes
   |
Unknown Final State

an immutable approach may use:

New Image
   |
New Instance
   |
Traffic Migration
   |
Old Instance Removed

This can reduce configuration drift and improve reproducibility.

29. IaC and Virtualization

Infrastructure as Code can manage virtualized resources such as:

• Virtual machines
• Virtual networks
• Storage
• Clusters
• Security policies

This creates a direct relationship between virtualization and cloud automation.

See Virtualization Explained for the underlying concepts behind hypervisors, virtual machines, virtual networking, and storage.

30. IaC vs Configuration Management

Infrastructure provisioning and operating-system configuration overlap, but they are not identical.

A workflow might look like:

Terraform
   |
Creates VM
   |
Configuration Management
   |
Installs / Configures Software

Terraform can create the infrastructure that hosts Linux systems, but it is not automatically a replacement for operating-system administration.

For that layer, see Linux Server Administration.

31. Environment Separation

Production IaC commonly separates:

Development
Staging
Production

The environments can reuse common modules but receive different inputs.

Example:

Development
   |
2 Instances
Small Database

Production
   |
10 Instances
Larger Database
Multi-Zone Architecture

A production repository may look like:

infrastructure/
├── modules/
│   ├── network/
│   ├── compute/
│   ├── database/
│   └── monitoring/
│
├── environments/
│   ├── dev/
│   ├── staging/
│   └── prod/
│
├── policies/
├── scripts/
├── .gitignore
└── README.md

The exact layout depends on the team and architecture.

The objective is clarity and controlled reuse.

32. Testing Infrastructure as Code

Infrastructure code should be tested.

Testing may include:

Formatting
      ↓
Configuration Validation
      ↓
Security Checks
      ↓
Policy Checks
      ↓
Terraform Plan
      ↓
Human Review
      ↓
Deployment Testing
      ↓
Drift Detection

A safe workflow is:

Developer Change
      |
Validation
      |
Security Scan
      |
Plan
      |
Review
      |
Apply

This is safer than directly editing production infrastructure without review.

33. Tagging and Metadata

Infrastructure should be labeled consistently.

Useful metadata may include:

Environment
Owner
Application
Cost Center
Department
Data Classification
Managed By

Example:

tags = {
  Environment = var.environment
  Application = "web"
  ManagedBy   = "terraform"
}

Consistent tagging improves:

• Inventory
• Cost allocation
• Governance
• Search
• Automation
• Troubleshooting

34. Disaster Recovery with Infrastructure as Code

One of IaC’s major advantages is reproducibility.

Suppose an infrastructure environment is lost.

A version-controlled architecture can help reconstruct:

Git Repository
      |
Terraform
      |
Network
      |
Compute
      |
Storage
      |
Monitoring

However:

Infrastructure as Code is not the same as data backup.

A complete recovery strategy requires:

Infrastructure as Code
        +
Backups
        +
Data Recovery
        +
Application Recovery

A secondary environment may therefore be represented as:

Primary Environment
       |
Infrastructure Code
       |
Version-Controlled Definition
       |
Secondary Environment

Infrastructure reconstruction and data restoration remain separate operational concerns.

35. Infrastructure Standardization and Platform Engineering

Suppose an organization has many engineering teams.

Without reusable infrastructure patterns:

Team A → Custom Network
Team B → Different Network
Team C → Different Firewall Rules
Team D → Different Monitoring

With approved modules:

Approved Network Module
          |
   +------+------+------+
   |      |      |      |
 Team A Team B Team C Team D

This does not require every system to be identical.

It creates standardized architectural patterns with controlled inputs.

Platform Engineering

Platform teams can expose approved building blocks:

Platform Team
     |
     +--> Secure Network Module
     +--> Application Module
     +--> Database Module
     +--> Monitoring Module
     +--> IAM Module

Application teams can then consume approved infrastructure without manually rebuilding every component.

This enables a more consistent self-service infrastructure model.

36. Terraform Module Reuse

Terraform modules can be obtained from:

• Local directories
• Git repositories
• Public registries
• Private registries
• Other supported sources

Third-party modules should still be evaluated carefully.

Review:

• Maintenance
• Security
• Permissions
• Dependencies
• Versions
• Resource behavior
• Source repository

A public module is not automatically a secure module.

37. Terraform Supply Chain Security

Terraform configurations can depend on:

Providers
Modules
Git Repositories
CI/CD Platforms
External APIs

This creates an infrastructure software supply chain.

Organizations should track:

Provider Version
Module Version
Source Repository
Change History
Security Advisories
Review Status

Infrastructure dependencies deserve many of the same controls applied to application dependencies.

38. Observability as Code

Infrastructure may be reproducible but still difficult to operate if monitoring is forgotten.

IaC can define:

Infrastructure
     |
     +--> Logging
     +--> Metrics
     +--> Monitoring
     +--> Alerts

This connects infrastructure automation directly with observability and security monitoring.

For centralized security monitoring, see SIEM Explained.

39. IaC and Network Security

Consider a standard application environment:

Internet
   |
Load Balancer
   |
Application Subnet
   |
Database Subnet

An infrastructure module can encode allowed communication:

Internet
   |
   v
Load Balancer
   |
   v
Application
   |
   v
Database

while rejecting unrelated connectivity.

This creates repeatable segmentation instead of depending on engineers manually recreating firewall policies.

40. Enterprise Governance

Large organizations often require controls such as:

Production Resources Must:
- Have an owner
- Use approved regions
- Enable logging
- Use encryption
- Include required tags
- Avoid public management access

Infrastructure as Code makes these requirements easier to:

• Validate
• Review
• Audit
• Standardize
• Automate

This represents a shift from policies that are only documented toward policies that can also be enforced during infrastructure delivery.

41. When Infrastructure as Code Is Not Enough

IaC is powerful, but it does not automatically provide:

• Good architecture
• Secure credentials
• Correct database design
• Capacity planning
• Reliable monitoring
• Disaster recovery
• Operational expertise
• Application reliability

Infrastructure as Code can automate a poor design just as efficiently as a good one.

The correct principle is:

Architecture first. Automation second.

42. Common Infrastructure as Code Mistakes

Storing Terraform State in Public Git

State may contain sensitive information.

Excessive IaC Permissions

Automation with administrator-level permissions can create large security risks.

Apply least privilege wherever practical.

Ignoring Provider Versions

Unexpected provider upgrades may introduce behavioral changes.

Excessive Module Abstraction

Too many nested modules make infrastructure difficult to understand.

Manual Changes Without Reconciliation

This creates configuration drift.

Applying Large Production Plans Without Review

Always understand important create, update, and destroy operations.

Storing Secrets in Source Code

Use controlled secret-management mechanisms.

Treating Terraform as Every Kind of Configuration Tool

Terraform is primarily an infrastructure-management system, not a universal operating-system configuration replacement.

43. Production Infrastructure as Code Architecture

A mature IaC workflow may look like:

                       Git Repository
                            |
                            v
                       Pull Request
                            |
               +------------+------------+
               |                         |
               v                         v
           Validation               Security Scan
               |                         |
               +------------+------------+
                            |
                            v
                       Terraform Plan
                            |
                            v
                       Human Review
                            |
                            v
                         Approval
                            |
                            v
                      Terraform Apply
                            |
               +------------+------------+
               |            |            |
               v            v            v
            Network      Compute      Database
               |            |            |
               +------------+------------+
                            |
                            v
                        Monitoring
                            |
                            v
                           Audit

This combines:

Version control + automation + security + review + reproducibility

44. Infrastructure as Code Security Checklist

Before using IaC in production, verify:

• State is stored securely
• State access is restricted
• Encryption is configured
• Secrets are not committed to Git
• Provider versions are constrained
• IAM permissions follow least privilege
• Production plans are reviewed
• Infrastructure changes are audited
• Modules are reviewed
• Third-party dependencies are evaluated
• Public resources are intentionally exposed
• Firewall rules are reviewed
• Required tags are applied
• Recovery procedures are documented

Terraform state deserves particular attention because it can contain infrastructure metadata and sensitive values.

45. Operational Checklist

A production IaC environment should also have:

• Documented architecture
• Version control
• Remote state
• State-access controls
• Module documentation
• Development testing
• Staging testing
• Production approval workflow
• Automated validation
• Security scanning
• Drift monitoring
• Recovery testing
• Emergency-change procedures

46. Infrastructure as Code for Beginners

A beginner does not need to begin with a large enterprise environment.

A practical learning sequence is:

1. Learn cloud fundamentals
        ↓
2. Learn networking
        ↓
3. Learn Terraform syntax
        ↓
4. Create one VM
        ↓
5. Create a network
        ↓
6. Add variables
        ↓
7. Add outputs
        ↓
8. Learn state
        ↓
9. Learn modules
        ↓
10. Add CI/CD

Before moving into larger Terraform environments, Computer Networking Explained and Cloud Networking Explained provide useful infrastructure foundations.

47. Frequently Asked Questions

What is Infrastructure as Code?

Infrastructure as Code is the practice of defining and managing infrastructure through configuration or code instead of relying primarily on manual infrastructure changes.

What is Terraform?

Terraform is an Infrastructure as Code tool that uses declarative configuration and providers to manage infrastructure.

Is Terraform a programming language?

Terraform uses a declarative configuration language designed primarily to describe infrastructure rather than general-purpose application logic.

What is Terraform state?

Terraform state stores information that associates Terraform-managed resource instances with real infrastructure objects.

Should Terraform state be stored in Git?

Terraform state can contain sensitive information. It should therefore be protected appropriately rather than casually stored in public or insecure repositories.

What are Terraform modules?

Modules are reusable collections of Terraform configuration that organize infrastructure into logical components.

What is configuration drift?

Configuration drift occurs when the actual infrastructure differs from the intended configuration managed through the IaC workflow.

Is Terraform only for AWS?

No. Terraform uses providers to manage multiple platforms and APIs.

Is Terraform the same as CloudFormation?

No.

Terraform uses a provider-oriented multi-platform architecture.

CloudFormation is AWS’s native infrastructure-management system.

Is Infrastructure as Code part of DevOps?

Yes. IaC commonly integrates with version control, reviews, automated validation, CI/CD, and production deployment workflows.

Can Terraform manage networking?

Yes. Where supported by providers, Terraform can manage resources such as:

• Virtual networks
• Subnets
• Routes
• Firewalls
• Load balancers
• VPN-related resources

Can Terraform manage IAM?

Yes. Terraform providers can manage supported identities, roles, permissions, policies, and service accounts.

Is Infrastructure as Code secure?

IaC can improve consistency and auditability, but it does not automatically guarantee security.

Insecure infrastructure can also be automated.

Security still depends on:

• Architecture
• IAM
• State protection
• Secrets management
• Module quality
• Network policies
• Testing
• Review

Conclusion

Infrastructure as Code represents a major change in how modern infrastructure is built and operated.

Instead of creating systems manually and documenting them afterward, teams can define infrastructure in configuration, store it in version control, review proposed changes, automate provisioning, and maintain repeatable environments.

Terraform supports this model through:

Declarative Configuration
        |
Providers
        |
Resources
        |
Variables / Outputs
        |
State
        |
Modules
        |
Plan
        |
Review
        |
Apply

But Terraform itself is only part of the larger architecture.

A mature Infrastructure as Code environment combines:

Architecture
     +
Version Control
     +
Infrastructure Code
     +
Security
     +
Policy
     +
Automation
     +
Monitoring
     +
Operations

The most important production lesson is therefore:

Infrastructure as Code is not simply automation.

It is a controlled relationship between the intended architecture, version-controlled configuration, real infrastructure, security requirements, and operational processes.

When combined with Cloud Computing Explained, Cloud Networking Explained, Virtualization Explained, Cloud Auto Scaling Explained, Linux Server Administration, and Network Security Basics, Infrastructure as Code becomes one of the foundations of a modern Cloud and DevOps architecture.