Infrastructure as Code: State, Drift, and Blast Radius

Infrastructure as Code (IaC) manages infrastructure through declarative configuration files rather than interactive tools or manual steps. This approach becomes critical when deploying systems that must be reproducible, version-controlled, and auditable. The core challenge lies in maintaining alignment between desired state and actual deployed resources—particularly when changes occur outside the IaC system.

Managing Desired State

Storing Infrastructure Definitions

Infrastructure definitions are typically stored as configuration files in a version control system. These files describe resources using a structured format such as JSON or YAML. For example, a simple virtual machine definition might look like:

resources:
  - type: compute.instance
    name: web-server
    properties:
      machine_type: n1-standard-2
      zone: us-central1-a
      boot_disk:
        initialize_params:
          image: debian-cloud/debian-11

The configuration must be version-controlled and reviewed through pull requests to ensure changes are intentional and auditable.

Applying Infrastructure Changes

Changes are applied using a command-line tool or API that reads the configuration and compares it with existing infrastructure. A common workflow involves:

# Validate the configuration before applying
terraform validate

# Plan what changes will be made
terraform plan

# Apply the configuration to infrastructure
terraform apply

The plan step is crucial: it shows what will change without making any modifications. If the plan includes unexpected deletions or replacements, the operation should not proceed.

Handling State Files

Infrastructure state must be stored separately from configuration. This state file tracks which resources exist, their properties, and metadata about the deployment. The most common pattern involves:

# Initialize a new state management system
terraform init

# Save current infrastructure state
terraform state list

# Export current state to JSON for backup
terraform state show > state-backup.json

State files are typically stored remotely (on S3, GCS, or a database) to ensure multiple engineers can collaborate on the same infrastructure.

Detecting and Managing Drift

Identifying Drift

Drift occurs when actual infrastructure differs from the declared configuration. This can happen through manual changes, external tools, or automation not managed by IaC. To detect drift:

# Compare current state with desired configuration
terraform plan

# Show detailed differences between desired and actual
terraform plan -out=plan.out
terraform show plan.out

If the output shows Plan: 0 to add, 0 to change, 1 to destroy, then a resource was deleted outside of IaC.

Handling Drift in Practice

When drift is detected, decisions must be made about how to resolve it. Common approaches include:

Reconcile: Apply the IaC configuration over existing resources
Import: Bring manually modified resources into IaC management
Ignore: Accept that manual changes are intentional and should not be overwritten

The import command is used when adding existing infrastructure to IaC:

# Import an existing resource into the state file
terraform import aws_instance.example i-1234567890abcdef0

Drift Scenarios

Drift can occur in several ways:

Manual changes made via cloud console or CLI (e.g., changing instance type in AWS Console)
External automation tools that modify resources without updating state files
Accidental deletion of resources through non-IaC processes

If drift is not caught early, it can cause cascading failures when subsequent IaC operations try to manage the same resources.

Understanding and Containing Blast Radius

What Constitutes a Blast Radius

Blast radius refers to the scope of impact when an IaC change is applied. This includes direct resource changes and indirect effects like dependencies or side effects from configuration updates.

A change that affects a single compute instance might have a blast radius of one if no other services depend on it, but could be many if that instance hosts critical services used by other systems.

Determining Blast Radius

To assess blast radius before applying changes:

# Show detailed plan with resource dependencies
terraform plan -detailed-exitcode

# View the full resource graph
terraform graph | dot -Tpng > graph.png

The resource graph shows how resources are connected and helps identify which other systems may be affected by a change.

Managing Large Changes

For changes that could have significant blast radius, consider:

Testing in isolation: Apply changes to a staging environment first
Gradual rollout: Use blue-green deployments or canary releases
Rollback planning: Ensure you can revert changes if they cause problems

# Apply configuration with specific targets to limit scope
terraform apply -target=aws_instance.web-server

# Preview what would be applied without actually applying
terraform plan -target=aws_instance.web-server

Handling Rollbacks

When an IaC change causes problems, rollback should involve:

Reverting to a known good configuration version
Re-applying that version to restore infrastructure state
Possibly restoring from backups of affected resources

# Revert to a previous state file
terraform apply -state=backup-state.json

# Destroy and recreate specific resources
terraform destroy -target=aws_instance.db-server
terraform apply -target=aws_instance.db-server

Common Failure Modes

Silent State Corruption

If the state file becomes corrupted or inconsistent, IaC operations may silently fail or make incorrect changes. Symptoms include:

Terraform reporting "Resource not found" when it should exist
Unexpected replacements or deletions during apply
Inconsistent outputs from terraform show and terraform plan

To detect this, always validate state files after major operations.

Drift Between Environments

Different environments (dev, staging, prod) may drift apart if changes are applied only to one environment. This leads to:

Unexpected behavior in production due to differences from staging
Inconsistent configuration across environments
Difficulty reproducing issues

Regular audits of state files and configuration consistency checks can prevent this.

Unintended Resource Destruction

When applying IaC changes, resources may be destroyed even when they should be preserved. This often happens because:

Missing lifecycle blocks that specify how to handle updates
Accidentally targeting the wrong resources with -target
Not using terraform import for manually created resources

Dependency Management Issues

IaC systems can fail if dependencies are not properly declared or if ordering is incorrect. For example, a database instance may be created before its VPC network exists, causing failures.

# Example of proper dependency declaration
resource "aws_instance" "web" {
  depends_on = [aws_vpc.main]
}

Configuration Drift Detection

Some tools provide drift detection features that are easy to overlook. For example, Terraform's terraform plan output shows:

Plan: 1 to add, 1 to change, 1 to destroy

But this doesn't indicate which resources have drifted from their configuration. Manual inspection of each resource's actual vs desired state is required.

Remote State Management

If the remote state storage (S3 bucket, GCS bucket, or database) becomes unavailable, IaC operations may fail or produce inconsistent results. The system should handle:

Failures to read or write state files
Concurrent access conflicts
Backup and restore procedures

# Check if remote state is accessible
terraform state pull > local-state.json

# Push updated state back
terraform state push local-state.json

Multi-Environment Consistency

When managing infrastructure across multiple environments, maintaining consistency becomes harder. Changes in one environment should be carefully considered for their impact on others.

The key is to ensure that changes are reviewed and tested in the same order across all environments, and that state files for each environment are kept separate and synchronized appropriately.

Versioning and Rollback Strategies

IaC systems must have clear version control policies. Each change should be:

Committed with descriptive messages
Merged through pull requests
Tested before deployment
Rolled back quickly if issues arise

State files should also be versioned to ensure that operations can be replayed or rolled back to previous states.

Human Error Mitigation

Human errors are a major source of IaC failures. Common mistakes include:

Applying incorrect configuration files
Using wrong target resources in apply commands
Forgetting to import existing resources
Modifying state files directly instead of through IaC tools

These issues often manifest as:

Unexpected resource destructions
Configuration drift that goes unnoticed
Inconsistent infrastructure states across teams

Proper process controls and automated checks help minimize these errors.

Resource Locking and Concurrency

When multiple engineers work on the same infrastructure, concurrent changes can cause conflicts. Proper locking mechanisms should ensure:

Only one person can modify state at a time
Changes are applied in order
Conflicts are detected and resolved appropriately

# Check for lock status
terraform state list -lock=true

# Force unlock if needed
terraform force-unlock <lock-id>

Dependency Graph Validation

The dependency graph of IaC resources must be validated to ensure that:

Resources are created in correct order
Dependencies are properly declared
Circular dependencies are avoided

This can be checked with:

# Generate dependency graph
terraform graph | dot -Tpng > dependency-graph.png

Best Practices for Managing State, Drift, and Blast Radius

Regular Audits

Perform regular audits of infrastructure state to catch drift early. These should include:

Comparing actual vs desired configuration
Verifying that all resources are properly tracked in IaC
Ensuring no manual changes have occurred without corresponding IaC updates

Change Management

All infrastructure changes should follow a process:

Changes must be reviewed in pull requests
Test environments should be updated before production
Rollback procedures must be documented and tested

State File Management

State files must be:

Stored remotely for team collaboration
Versioned with the configuration
Regularly backed up
Protected from concurrent access issues

Testing and Validation

Before applying changes, always:

Validate configuration syntax
Plan what changes will occur
Check resource dependencies
Verify that no unintended resources will be affected

This approach ensures that infrastructure remains predictable, reproducible, and manageable across all environments.

This page was rewritten on 15 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.