Terraform & IaC Interview Questions and Answers

A provider is a plugin that lets Terraform talk to an API, such as AWS, Azure, or Kubernetes.

• Declare required providers and versions so builds are reproducible.
• terraform init downloads providers, initialises the backend, and installs modules. Run it first in any working directory.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}
provider "aws" { region = "us-east-1" }

The core workflow is init, plan, apply, and destroy. Providers are versioned independently of Terraform core, so pin versions and commit the lock file .terraform.lock.hcl to keep CI consistent. Use provider aliases and multiple provider blocks when you work across regions or accounts. Run terraform init -upgrade to move to newer allowed versions deliberately.

A module is a reusable package of Terraform configuration. Every configuration is a root module, and it can call child modules.

Benefits:

• Encapsulation: expose a small set of input variables and outputs, and hide the complexity.
• Consistency: standardise how a database or VPC is provisioned across teams.
• Reuse: avoid copy-pasting the same blocks.

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.5.0"
  name    = "app-vpc"
  cidr    = "10.0.0.0/16"
  azs     = ["us-east-1a", "us-east-1b"]
}

Use the public registry or a private module registry with version pins. Pass data in through variables and expose needed values via outputs. Avoid deep nesting and over-abstraction; a module should have a clear single purpose. Test modules with tools such as Terratest, and document inputs and outputs.

plan is a dry run; apply makes changes.

• terraform plan refreshes state, compares configuration to reality, and shows what will be created, updated, or destroyed. It does not change infrastructure. Use -out to save the plan.
• terraform apply executes the proposed actions and calls provider APIs. With a saved plan it applies exactly what you reviewed.

terraform plan -out=tfplan
terraform apply tfplan
terraform plan -detailed-exitcode

The detailed exit code helps CI: 0 means no changes, 1 is an error, and 2 means changes are present. Review plans carefully, especially destroys and replacements marked -/+. A resource that changes a force-new attribute is destroyed and recreated, which can cause downtime. Use -target only for emergencies, since it can leave state inconsistent. In automation, always apply the reviewed plan file.

Workspaces let one configuration manage multiple, separate states. terraform.workspace is a variable naming the active workspace, and the default workspace always exists.

terraform workspace new dev
terraform workspace new prod
terraform workspace select prod
terraform workspace list

Each workspace has its own state, so resources are isolated. With the S3 backend, state goes to different keys per workspace.

Use cases:

• Ephemeral environments for testing or feature branches.
• Lightweight separation of dev, staging, and prod from one codebase.

Cautions:

• Workspaces share the same configuration and variables, so environment differences must be parameterised.
• They are easy to confuse, and a wrong selection can target production.
• They do not provide strong isolation or separate credentials.

For serious environments, prefer separate directories or repositories with distinct backends and accounts. Use workspaces for temporary or closely related environments.