Marking a Terraform variable or output as sensitive = true is a useful safety measure, but it is widely misunderstood. It does not provide complete protection for your secrets. Here is exactly what it does and does not do.

What sensitive = true Does

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

output "db_connection_string" {
  value     = "postgres://admin:${var.db_password}@${aws_db_instance.main.endpoint}/app"
  sensitive = true
}

When marked sensitive, Terraform will:

• Mask the value in terraform plan and terraform apply output as (sensitive value).
• Suppress the value in terraform output unless you use -json or -raw.
• Prevent the value from appearing in regular log output.

# Plan output with sensitive = true
+ password = (sensitive value)   # Value is hidden in terminal

What sensitive = true Does NOT Do

This is the critical part most engineers miss:

• It does NOT encrypt the value in the state file.
• It does NOT prevent the value from being read with terraform state pull.
• It does NOT remove the value from the .tfstate file on disk.

# The password is stored in CLEARTEXT inside terraform.tfstate
{
  "resources": [
    {
      "instances": [
        {
          "attributes": {
            "password": "SuperSecretPassword123!"  # Fully visible in state file!
          }
        }
      ]
    }
  ]
}

How to Truly Secure Sensitive Data

1. Use a Remote Backend with Encryption at Rest

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true          # Server-side encryption
    kms_key_id     = "arn:aws:kms:us-east-1:123456789:key/abc-123"  # KMS key
    dynamodb_table = "terraform-lock"
  }
}

2. Restrict Access to the State File

# S3 bucket policy — restrict to only Terraform IAM role
{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-terraform-state/*",
  "Condition": {
    "StringNotEquals": {
      "aws:PrincipalArn": "arn:aws:iam::123456789:role/terraform-role"
    }
  }
}

3. Avoid Storing Secrets in State at All

# Use a data source to fetch secrets at apply time instead of storing them
data "aws_secretsmanager_secret_version" "db_pass" {
  secret_id = "prod/db/password"
}

Key Takeaway

sensitive = true only masks values in CLI output and logs — it is a display-layer protection, not encryption. The secret is still stored as cleartext in your state file. For true security, use a remote backend with KMS encryption, restrict state file access via IAM policies, and source secrets from a secret manager at apply time.

The post Does sensitive = true Fully Protect Your Data in Terraform? first appeared on TechieRoop.

When you first start with Terraform, state is stored locally in terraform.tfstate. As your team grows, you need to migrate to a remote backend for collaboration, security, and state locking.

Why Migrate to a Remote Backend?

• Enables team collaboration — everyone shares the same state.
• Prevents concurrent apply conflicts with state locking.
• Keeps secrets out of your local machine and version control.
• Enables versioning, encryption at rest, and audit logs.

Step 1: Create the Remote Backend Infrastructure

First, provision the S3 bucket and DynamoDB table for state storage and locking:

# Create S3 bucket (do this manually or with a separate Terraform config)
aws s3api create-bucket \
  --bucket my-terraform-state \
  --region us-east-1

# Enable versioning
aws s3api put-bucket-versioning \
  --bucket my-terraform-state \
  --versioning-configuration Status=Enabled

# Create DynamoDB table for state locking
aws dynamodb create-table \
  --table-name terraform-state-lock \
  --attribute-definitions AttributeName=LockID,AttributeType=S \
  --key-schema AttributeName=LockID,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST

Step 2: Add the Backend Block to Your Config

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"
  }
}

Step 3: Run terraform init to Trigger Migration

terraform init

Terraform detects that the backend has changed and prompts:

Do you want to copy existing state to the new backend?
  Pre-existing state was found while migrating the previous backend.
  Enter "yes" to copy this state to the new backend.

Enter a value: yes

Type yes and Terraform automatically copies your local state to the remote backend.

Step 4: Verify the Migration

# Confirm remote state is accessible
terraform state list

# Check the remote state file in S3
aws s3 ls s3://my-terraform-state/prod/

Step 5: Clean Up Local State

After verifying the migration was successful, remove the local state file:

# Keep a backup first
cp terraform.tfstate terraform.tfstate.backup

# Remove local state (remote is now the source of truth)
rm terraform.tfstate
rm terraform.tfstate.backup

Key Takeaway

Migrating to a remote backend is a three-step process: add the backend block, run terraform init, and confirm the migration prompt. Always verify state integrity afterward and enable versioning on your S3 bucket before migrating.

The post How to Migrate Terraform State from Local to a Remote Backend first appeared on TechieRoop.

When Terraform needs to replace a resource (destroy and recreate), it follows a specific order. Understanding the create_before_destroy lifecycle rule helps you avoid downtime during infrastructure updates.

Default Behavior: Destroy Then Create

By default, when a resource needs to be replaced, Terraform:

1. Destroys the old resource.
2. Creates the new resource.

This causes a window of downtime where neither the old nor new resource exists.

create_before_destroy: Create Then Destroy

With create_before_destroy = true, Terraform reverses the order:

1. Creates the new resource first.
2. Waits for it to be fully operational.
3. Destroys the old resource.

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

  lifecycle {
    create_before_destroy = true
  }
}

Real-World Example: Auto Scaling Launch Template

resource "aws_launch_template" "app" {
  name_prefix   = "app-"
  image_id      = var.ami_id
  instance_type = "t3.micro"

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_autoscaling_group" "app" {
  launch_template {
    id      = aws_launch_template.app.id
    version = "$Latest"
  }
  min_size         = 2
  max_size         = 5
  desired_capacity = 2
}

When the AMI is updated, a new launch template is created before the old one is removed, ensuring the ASG always has a valid template.

Example: TLS Certificate Rotation

resource "aws_acm_certificate" "cert" {
  domain_name       = "example.com"
  validation_method = "DNS"

  lifecycle {
    create_before_destroy = true
  }
}

The new certificate is issued and validated before the old one is deleted, preventing HTTPS downtime.

Other Useful Lifecycle Rules

lifecycle {
  create_before_destroy = true   # Create new before destroying old
  prevent_destroy       = true   # Block any destroy operation (great for databases)
  ignore_changes        = [tags] # Ignore drift in specific attributes
}

Key Takeaway

Always use create_before_destroy = true for production resources where availability matters — load balancers, certificates, launch templates, and DNS records. Pair it with prevent_destroy = true on critical resources like databases to add an extra safety net.

The post Terraform create_before_destroy Lifecycle Rule Explained first appeared on TechieRoop.

A null_resource is a special Terraform resource that does not manage any real cloud infrastructure. Instead, it acts as a placeholder to trigger side effects — like running scripts or commands — at the right point in the Terraform lifecycle.

When to Use null_resource

Use it when you need to:

• Run a local or remote script after certain infrastructure is ready.
• Execute a command that does not map to a Terraform resource.
• Trigger actions based on changes to other resources.

Basic Example: Run a Local Script

resource "null_resource" "run_setup_script" {
  provisioner "local-exec" {
    command = "bash ./scripts/setup.sh"
  }

  depends_on = [aws_instance.web]
}

This runs setup.sh on your local machine after the EC2 instance is created.

Using triggers to Re-run on Change

By default, a null_resource only runs once. Use triggers to re-execute it when a value changes:

resource "null_resource" "redeploy_app" {
  triggers = {
    app_version = var.app_version
    instance_id = aws_instance.web.id
  }

  provisioner "local-exec" {
    command = "ansible-playbook -i '${aws_instance.web.public_ip},' deploy.yml"
  }
}

Every time app_version or the instance ID changes, this resource will be destroyed and recreated, triggering the provisioner again.

Remote Execution with remote-exec

resource "null_resource" "configure_server" {
  connection {
    type        = "ssh"
    user        = "ubuntu"
    private_key = file("~/.ssh/id_rsa")
    host        = aws_instance.web.public_ip
  }

  provisioner "remote-exec" {
    inline = [
      "sudo apt-get update -y",
      "sudo apt-get install -y nginx",
      "sudo systemctl start nginx"
    ]
  }

  depends_on = [aws_instance.web]
}

Modern Alternative: terraform_data (Terraform 1.4+)

# null_resource is being replaced by terraform_data in newer versions
resource "terraform_data" "run_script" {
  triggers_replace = [var.app_version]

  provisioner "local-exec" {
    command = "echo Deploying version ${var.app_version}"
  }
}

Key Takeaway

null_resource is your escape hatch for actions Terraform cannot model as a resource. Use it sparingly with provisioners for bootstrapping or triggering scripts. For Terraform 1.4 and above, prefer the built-in terraform_data resource instead.

The post What is the Purpose of a null_resource in Terraform? first appeared on TechieRoop.

Hardcoding secrets like passwords, API keys, or tokens directly in .tf files is a critical security mistake. This guide covers the right ways to manage secrets in Terraform.

What NOT to Do

# NEVER do this — secrets committed to version control
resource "aws_db_instance" "main" {
  username = "admin"
  password = "SuperSecretPassword123!"  # BAD
}

Option 1: Environment Variables with TF_VAR_

Terraform reads environment variables prefixed with TF_VAR_ and maps them to input variables.

# In your shell or CI/CD pipeline
export TF_VAR_db_password="SuperSecretPassword123!"

# In variables.tf
variable "db_password" {
  type      = string
  sensitive = true
}

# In main.tf
resource "aws_db_instance" "main" {
  username = "admin"
  password = var.db_password
}

Option 2: Mark Variables as sensitive

variable "api_key" {
  type      = string
  sensitive = true  # Masks value in CLI output and logs
}

Note: This masks the value in terminal output but does NOT encrypt it in the state file.

Option 3: HashiCorp Vault (Most Secure)

provider "vault" {
  address = "https://vault.mycompany.com"
}

data "vault_generic_secret" "db_creds" {
  path = "secret/database/prod"
}

resource "aws_db_instance" "main" {
  username = data.vault_generic_secret.db_creds.data["username"]
  password = data.vault_generic_secret.db_creds.data["password"]
}

Option 4: AWS Secrets Manager

data "aws_secretsmanager_secret_version" "db_pass" {
  secret_id = "prod/app/db_password"
}

resource "aws_db_instance" "main" {
  password = data.aws_secretsmanager_secret_version.db_pass.secret_string
}

Option 5: .tfvars Files (Keep Out of Git)

# terraform.tfvars — ADD THIS TO .gitignore
db_password = "SuperSecretPassword123!"

# .gitignore
*.tfvars
*.tfvars.json

Key Takeaway

Never store secrets in .tf files or commit them to version control. Use TF_VAR_ environment variables for simple cases, and HashiCorp Vault or cloud-native secret managers (AWS Secrets Manager, Azure Key Vault) for production workloads.

The post How to Handle Secrets in Terraform Without Hardcoding Them first appeared on TechieRoop.

Managing multiple environments like Dev, Staging, and Production is one of the most common Terraform challenges. You have two main approaches: Workspaces and Separate Directories. Here is how they differ and when to use each.

Terraform Workspaces

Workspaces allow multiple state files within the same backend configuration.

# Create and switch to a dev workspace
terraform workspace new dev
terraform workspace select dev

# Create a prod workspace
terraform workspace new prod
terraform workspace select prod

# Reference workspace in config
resource "aws_instance" "web" {
  instance_type = terraform.workspace == "prod" ? "t3.large" : "t2.micro"
  ami           = "ami-0c55b159cbfafe1f0"
}

All workspaces share the same backend and the same .tf files. The only difference is the state file path.

Problems with Workspaces for Prod/Dev Isolation

• A terraform apply in the wrong workspace can affect the wrong environment.
• All environments share the same backend — no true isolation.
• Config differences between environments bloat the code with conditionals.
• Not recommended by HashiCorp for strong environment isolation.

Separate Directories (Recommended)

infrastructure/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── backend.tf      # Points to dev S3 bucket
│   ├── staging/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── backend.tf      # Points to staging S3 bucket
│   └── prod/
│       ├── main.tf
│       ├── variables.tf
│       └── backend.tf      # Points to prod S3 bucket
└── modules/
    ├── networking/
    └── compute/

Each environment has its own backend, state file, and configuration. Shared logic lives in reusable modules.

Comparison Table

Key Takeaway

Use separate directories with separate backends for long-lived environments like Dev and Prod. Use workspaces only for short-lived or experimental environments where strong isolation is not needed.

The post Terraform Workspaces vs Separate Directories: Which is Better for Dev/Prod? first appeared on TechieRoop.

Manually deleting a cloud resource outside of Terraform — such as via the AWS Console, Azure Portal, or GCP Console — creates a situation called configuration drift. Understanding how Terraform handles this is critical for maintaining infrastructure integrity.

What is Configuration Drift?

Drift occurs when the real-world state of your infrastructure differs from what Terraform’s state file records. The state file still believes the resource exists, but the cloud provider no longer has it.

What Terraform Does on the Next Plan

When you run terraform plan after a manual deletion, Terraform will:

1. Refresh the state by querying the cloud provider.
2. Detect that the resource is gone from the provider.
3. Propose to recreate the resource to match your configuration.

# Example terraform plan output after manual deletion

# aws_instance.web will be created
+ resource "aws_instance" "web" {
    + ami           = "ami-0c55b159cbfafe1f0"
    + instance_type = "t2.micro"
    ...
  }

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

How to Detect Drift Without Planning

# Refresh state to detect drift without making changes
terraform refresh

# Or use plan with refresh only (Terraform 1.1+)
terraform plan -refresh-only

Options After Detecting Drift

Option 1: Let Terraform recreate it — just run terraform apply and the resource comes back.

Option 2: Accept the deletion — remove it from your .tf files and run terraform state rm to remove it from state without recreating it.

# Remove from state without destroying (resource is already gone)
terraform state rm aws_instance.web

Option 3: Import it back — if you recreated it manually and want Terraform to manage the new one:

terraform import aws_instance.web i-0newinstanceid123

Best Practice: Never Modify Terraform-Managed Resources Manually

The golden rule: if Terraform manages it, all changes must go through Terraform. Manual changes bypass the plan/apply review cycle and can lead to unintended infrastructure states.

Key Takeaway

Manually deleting a resource causes drift. Terraform detects it on the next plan and proposes recreation. Use terraform plan -refresh-only regularly in production environments to catch drift before it causes problems.

The post What Happens If You Manually Delete a Resource in the Cloud Console? first appeared on TechieRoop.

Terraform automatically builds a dependency graph by analyzing resource references in your code. In most cases, you never need to declare dependencies manually. But there are specific scenarios where depends_on is necessary.

How Implicit Dependencies Work

When one resource references another, Terraform infers the dependency automatically:

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

resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id   # Implicit dependency — Terraform knows VPC must exist first
  cidr_block = "10.0.1.0/24"
}

When Implicit Dependencies Are NOT Enough

Use depends_on when a resource relies on another that it does not directly reference in code. The most common example: an application server that needs a database to be fully initialized, but shares no configuration values with it.

resource "aws_db_instance" "postgres" {
  identifier        = "my-app-db"
  engine            = "postgres"
  instance_class    = "db.t3.micro"
  allocated_storage = 20
  username          = "admin"
  password          = var.db_password
}

resource "aws_instance" "app_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  # No direct reference to the DB, but the app needs it running first
  depends_on = [aws_db_instance.postgres]
}

depends_on with Modules

depends_on can also be applied to entire modules:

module "database" {
  source = "./modules/database"
}

module "application" {
  source     = "./modules/application"
  depends_on = [module.database]
}

depends_on with IAM Policies

A classic use case — an EC2 instance needing an IAM policy to be attached before it starts:

resource "aws_iam_role_policy_attachment" "s3_access" {
  role       = aws_iam_role.ec2_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"
}

resource "aws_instance" "worker" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  iam_instance_profile = aws_iam_instance_profile.ec2_profile.name

  depends_on = [aws_iam_role_policy_attachment.s3_access]
}

Key Takeaway

Use depends_on only when a hidden dependency exists that Terraform cannot detect through resource attribute references. Overusing it adds unnecessary coupling — rely on implicit dependencies wherever possible.

The post When Should You Explicitly Use depends_on in Terraform? first appeared on TechieRoop.

The Terraform state file (terraform.tfstate) is the single source of truth for your managed infrastructure. A corrupted or lost state file is one of the most critical incidents you can face. Here is how to handle it.

Prevention First: Enable Remote Backend with Versioning

The best recovery strategy is prevention. Always use a remote backend (like AWS S3) with versioning enabled.

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"

    # Enable versioning on the S3 bucket in AWS console or via config
  }
}

With versioning enabled, you can roll back to a previous healthy state in seconds.

Recovery Option 1: Restore from Version History

If you are using S3 with versioning:

1. Go to the S3 console and navigate to your state file.
2. Click Show versions.
3. Download a previous healthy version of the .tfstate file.
4. Upload it back to replace the corrupted one.
5. Run terraform plan to verify drift.

Recovery Option 2: Use terraform import

If the state is completely lost with no backup, manually re-import each resource:

# Re-import an existing AWS EC2 instance into state
terraform import aws_instance.web i-0abc12345def67890

# Re-import an S3 bucket
terraform import aws_s3_bucket.data my-existing-bucket-name

# Re-import an RDS instance
terraform import aws_db_instance.postgres my-db-identifier

You will need to do this for every resource in your configuration, which is tedious but recoverable.

Recovery Option 3: terraform state pull / push

# Pull the current remote state locally
terraform state pull > backup.tfstate

# Push a fixed state back to remote
terraform state push fixed.tfstate

Inspect and Fix State Manually

# List all resources in state
terraform state list

# Show details of a specific resource
terraform state show aws_instance.web

# Remove a resource from state (without destroying it)
terraform state rm aws_instance.web

Key Takeaway

Always use a remote backend with versioning and state locking (DynamoDB for S3). If disaster strikes, restore from version history first. If no backup exists, use terraform import to rebuild the state resource by resource.

The post How to Recover from a Corrupted Terraform State File first appeared on TechieRoop.

When creating multiple instances of a resource in Terraform, you have two options: count and for_each. Knowing when to use each one is a key concept for writing reliable, maintainable infrastructure code.

Using count

count creates resources using a numeric index starting at 0. It is simple and works well for identical resources.

resource "aws_instance" "server" {
  count         = 3
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name = "server-${count.index}"
  }
}

Resources are referenced as aws_instance.server[0], aws_instance.server[1], etc.

The Problem with count

If you remove an item from the middle of the list — say you delete index 1 — Terraform will shift all subsequent indices and recreate every resource after the deleted one. This is dangerous in production environments.

# Before: ["server-a", "server-b", "server-c"]
# After removing "server-b": ["server-a", "server-c"]
# Terraform will DESTROY server-c and RECREATE it as the new index 1!

Using for_each (Recommended)

for_each uses a map or set of strings as unique keys, so each resource is tied to a stable identifier — not a fragile numeric index.

variable "servers" {
  default = {
    "server-a" = "t2.micro"
    "server-b" = "t2.small"
    "server-c" = "t2.micro"
  }
}

resource "aws_instance" "server" {
  for_each      = var.servers
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = each.value

  tags = {
    Name = each.key
  }
}

Resources are referenced as aws_instance.server["server-a"]. Removing “server-b” only destroys that specific resource, leaving others untouched.

for_each with a Set of Strings

resource "aws_iam_user" "devs" {
  for_each = toset(["alice", "bob", "charlie"])
  name     = each.key
}

Quick Comparison

Key Takeaway

Prefer for_each over count for any resource list that may change over time. It provides stable, key-based identity and prevents unintended resource replacement when items are added or removed.

The post Terraform count vs for_each: Which is Better for Dynamic Resources? first appeared on TechieRoop.