Top Terraform Interview Questions: Ace Your DevOps Interview

Terraform has become the de facto standard for Infrastructure as Code (IaC) in the DevOps world. Whether you're deploying to AWS, Azure, GCP, or even on-premises, Terraform allows you to define, provision, and manage infrastructure declaratively. In a DevOps interview, Terraform questions are almost guaranteed, ranging from basic concepts to advanced troubleshooting. This guide covers the most common Terraform interview questions, with detailed answers, code examples, and production insights. You'll learn how to explain Terraform's core concepts, handle state management, use modules, and debug issues. We also include a real-world production incident to illustrate common pitfalls. By the end, you'll be ready to confidently answer any Terraform question thrown your way.

What is Terraform and How Does It Work?

Terraform is an open-source Infrastructure as Code (IaC) tool created by HashiCorp. It allows you to define and provision data center infrastructure using a declarative configuration language known as HashiCorp Configuration Language (HCL). Terraform manages infrastructure as code, enabling version control, collaboration, and automation. The core workflow consists of: init (initialize providers and modules), plan (show changes), apply (execute changes), and destroy (tear down resources). Terraform uses providers (e.g., AWS, Azure, GCP) to interact with cloud APIs and maintains a state file to track resource metadata. This state file is crucial for mapping real-world resources to your configuration.

provider "aws" {
  region = "us-east-1"
}

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

Terraform State Management: Best Practices

State management is a critical aspect of Terraform. The state file contains all resource metadata and is used to map configuration to real-world resources. Best practices include: using remote state backends (e.g., S3 with DynamoDB locking), enabling state versioning, and separating state per environment (dev, staging, prod). Avoid storing state in local files for production. Use terraform state commands to manipulate state when necessary, but prefer importing resources over manual edits. Workspaces can help manage multiple environments with the same configuration, but be cautious with shared state.

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

Terraform Modules: Reusability and Organization

Modules are containers for multiple resources that are used together. They promote reusability, abstraction, and organization. A module can be local (within your project) or remote (from the Terraform Registry). Modules accept input variables and return output values. Best practices: keep modules focused on a single concern, use versioning for remote modules, and document module usage. Example: a VPC module that creates subnets, route tables, and internet gateways.

variable "cidr_block" {
  description = "CIDR block for VPC"
}

resource "aws_vpc" "main" {
  cidr_block = var.cidr_block
}

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

Terraform Workspaces: Managing Environments

Workspaces allow you to manage multiple environments (e.g., dev, staging, prod) with the same configuration. Each workspace has its own state file. The default workspace is 'default'. Use terraform workspace new, select, list, and delete commands. Workspaces are useful for quick environment separation but have limitations: they don't provide isolation for variables or backends. For production, consider using separate directory structures or Terraform Cloud workspaces.

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

# List workspaces
terraform workspace list

# Apply in dev workspace
terraform apply -auto-approve

Terraform Provisioners: When and How to Use Them

Provisioners are used to execute scripts or commands on a resource after it is created (or before destruction). Common provisioners: file, remote-exec, local-exec. However, HashiCorp recommends using provisioners as a last resort because they can make configurations brittle and hard to debug. Prefer using user_data scripts, configuration management tools (Ansible, Chef), or custom images. If you must use provisioners, ensure idempotency and handle failures gracefully.

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

  provisioner "remote-exec" {
    inline = [
      "sudo apt-get update",
      "sudo apt-get install -y nginx",
      "sudo systemctl start nginx"
    ]
    connection {
      type        = "ssh"
      user        = "ubuntu"
      private_key = file("~/.ssh/id_rsa")
      host        = self.public_ip
    }
  }
}

Terraform Error Handling and Debugging

Terraform provides several ways to debug issues. Set TF_LOG environment variable to DEBUG, INFO, WARN, or ERROR to get detailed logs. Use terraform validate to check syntax, terraform plan to preview changes, and terraform show to inspect state. Common errors: missing providers, state lock conflicts, resource conflicts. Use terraform import to bring existing resources under management. For complex issues, check provider documentation and community forums.

# Enable debug logging
export TF_LOG=DEBUG

# Run plan with debug output
terraform plan

# Validate configuration
terraform validate

# Show current state
export TF_LOG=INFO
terraform show