Terraform Interview Questions and Answers

Terraform interview questions at top technology firms are not about definitions or reciting what the different commands are. Interviewers evaluate whether you have worked with the application, managed remote state at scale, debugged a corrupted state file, and designed a module structure for a large codebase.

The Terraform interview questions guide presents actual questions asked in interviews. Terraform interview questions and answers in this guide are arranged for beginner, intermediate, and advanced levels.

Terraform interview questions and answers in this guide cover several key topics such as IaC fundamentals, core commands, state management, modules, workspaces, security, anti-patterns, and real troubleshooting scenarios.

Key Takeaways

Basic Terraform Interview Questions

This section presents foundational concepts and Terraform interview questions asked in all Terraform interviews.

Q1. What is Terraform, and what problem does it solve?

Terraform is a tool that lets you describe your infrastructure in code, so you can create and manage resources in a clear, repeatable way. It removes the need for manual setup, helping teams avoid mistakes and keep environments consistent across development, testing, and production.

Q2. What is Infrastructure as Code (IaC), and how does Terraform implement it?

Infrastructure as Code (IaC) means setting up and managing infrastructure through code rather than doing it manually, step by step. Terraform follows this approach by letting you define what you want in simple config files and then taking care of creating or updating resources to match it.

Q3. What is the difference between Terraform and CloudFormation?

Terraform and CloudFormation help you manage infrastructure with code. However, Terraform works across multiple cloud providers, while AWS CloudFormation is built specifically for AWS and fits closely within its ecosystem.

The following table presents differences between Terraform and CloudFormation.

Feature	Terraform	AWS CloudFormation
Cloud support	Works with multiple cloud providers and services	Designed only for AWS services
Language	Uses HCL, which is simple and easy to understand	Uses JSON or YAML templates
State management	Keeps a separate state file to track changes	AWS handles the state internally
Reuse model	Uses modules to reuse and organize code	Uses nested stacks for reuse
Drift detection	Needs manual checks or extra setup	Has built-in drift detection
Community ecosystem	Large community with plenty of shared resources	More AWS-focused, smaller in comparison
When to choose it	Good choice for multi-cloud or flexible setups	Ideal when everything runs on AWS

Q4. What is the difference between Terraform and Ansible?

Terraform is used to create and manage infrastructure like servers and networks, while Ansible is used to configure and set up what runs inside those systems. Terraform builds the environment, and Ansible takes care of configuring it.

Q5. What are the core Terraform commands, and what do each do?

Terraform has a set of core CLI commands to manage infrastructure as code across the lifecycle. The following table presents Terraform core commands.

Command	What It Does	When You Run It
terraform init	Prepares your project by setting up providers and backend	At the start of a project or after setup changes
terraform plan	Shows what Terraform is about to change before doing anything	When you want to review changes safely
terraform apply	Applies the changes and updates your infrastructure	After confirming the plan looks correct
terraform destroy	Removes everything Terraform has created	When you no longer need the infrastructure
terraform validate	Checks if your configuration is written correctly	While developing or before running a plan
terraform fmt	Cleans up and standardizes your code formatting	During development to keep code readable
terraform show	Displays the current state or details of a plan	When you want to inspect what exists
terraform state list	Lists all resources Terraform is tracking	When checking or debugging your state file
terraform import	Adds existing resources into Terraform management	When bringing manual resources under control
terraform output	Prints useful values defined in your setup	After apply to get things like IPs or URLs

Q6. What is a Terraform provider and how does it work?

A Terraform provider is what connects Terraform to a specific platform, like a cloud service or API. It works behind the scenes by turning your configuration into API calls so resources can be created, updated, or removed.

Q7. What is the Terraform state file and why does it exist?

The Terraform state file is a snapshot of the resources Terraform is currently managing and their real-world details. It exists so Terraform can keep track of what’s already created and how it matches your configuration. This allows it to make safe, accurate changes instead of guessing or duplicating resources.

Q8. What is the difference between terraform plan and terraform apply?

terraform plan lets you see what changes are going to happen before anything is touched, so you can review safely. terraform apply actually goes ahead and makes those changes in your real infrastructure.

Q9. What is HashiCorp Configuration Language (HCL)?

HashiCorp Configuration Language (HCL) is a clean, easy-to-read language used to describe infrastructure in tools like Terraform. It helps you write configurations in a way that feels natural to read while still being precise enough for systems to follow.

The following table presents the HCL block types.

Block Type	Purpose	Example
terraform {}	Defines basic settings Terraform needs, like versions and providers	terraform { required_providers { aws = { source = “hashicorp/aws” } } }
provider {}	Tells Terraform which cloud or service to connect to and how	provider “aws” { region = “ap-south-1” }
resource {}	Describes the infrastructure you want to create or manage	resource “aws_instance” “web” { ami = “ami-123” instance_type = “t2.micro” }
variable {}	Lets you pass and reuse values to make configs flexible	variable “instance_type” { default = “t2.micro” }
output {}	Displays key information after the run completes	output “instance_ip” { value = aws_instance.web.public_ip }
data {}	Reads details from existing resources instead of creating new ones	data “aws_ami” “latest” { most_recent = true }
locals {}	Holds temporary values to simplify and reuse expressions	locals { env = “dev” }

Q10. What are Terraform variables and how do you pass values to them?

Terraform variables are placeholders that let you make your configuration reusable and easy to adjust without editing the main code. You can pass values using a .tfvars file, command line (-var), environment variables, or by setting defaults inside the variable block.

Q11. What is the purpose of a terraform.tfvars file?

Terraform variables are like inputs that let you tweak your setup without changing the main configuration every time. You can give them values using a .tfvars file, command line options, environment variables, or simple defaults in the code itself.

Q12. What is the Terraform Registry?

The Terraform Registry is a place where you can find ready-made modules and providers created by others. It saves time by letting you reuse existing building blocks instead of writing everything from scratch.

Intermediate Terraform Interview Questions

This section presents intermediate Terraform interview questions and answers. Topics covered for the Terraform interview questions and answers are on state management, modules, workspaces, and real infrastructure patterns.

Q13. What is a remote state and why is it important for teams?

Remote state means keeping the Terraform state file in a shared place instead of on one person’s machine. It lets everyone on the team work from the same, latest view of the infrastructure. This helps avoid clashes, keeps things consistent, and reduces the risk of overwriting each other’s changes.

Q14. What is state locking and what happens if it fails?

State locking makes sure only one person or process can update the Terraform state at a time.
If it doesn’t work, changes can overlap and leave your state or infrastructure in a messy, inconsistent state.

Q15. What are Terraform modules and why do you use them?

Terraform modules are reusable chunks of infrastructure code that bundle related resources into one place. They save time by letting you write something once and use it in multiple projects instead of repeating the same setup.

Using modules keeps your code cleaner, more consistent, and much easier to manage as your infrastructure grows.

Q16. What is the difference between a root module and a child module?

The root module is your main working folder — it’s the one Terraform runs when you execute commands. A child module is a smaller, reusable piece that the root module calls to handle specific parts of the setup.

Q17. What are data sources in Terraform and when do you use them?

Data sources in Terraform are used to fetch details about things that already exist, without managing or creating them. You use them when your setup needs to refer to existing resources, like pulling IDs or configurations into your code.

Q18. What is the terraform import command and when would you use it?

terraform import lets you bring an existing resource under Terraform’s control by adding it to the state. You use it when something is already created outside Terraform, and you want to manage it without rebuilding it.

Q19. What are Terraform workspaces and when would you use them?

Terraform workspaces are a way to keep separate state files for the same configuration, so one setup can represent multiple environments. They’re handy when you want to reuse the same code for environments like dev, test, and prod without copying everything.

The following table compares workspaces and separate directories.

Approach	What It Isolates	When to Use It	When to Avoid It
Terraform Workspaces	Keeps only the state separate while using the same code	Good when your environments are almost the same and you just need a simple way to switch between them	Not ideal if environments start needing different configs or tighter control—it can become confusing
Separate Root Modules / Directories	Separates everything—code, variables, and state	Best when environments have clear differences or need strong isolation and independent management	Overkill if everything is identical, since you’ll end up repeating the same setup in multiple places

Q20. What is the depends_on argument and when do you use it explicitly?

depends_on tells Terraform to create or update one resource only after another one is done. You add it when Terraform can’t naturally figure out the dependency, but the order still matters.

Q21. What is the lifecycle meta-argument in Terraform and what settings does it support?

The lifecycle meta-argument in Terraform gives you control over how a resource behaves during creation, updates, and deletion. The following table presents lifecycle settings.

Setting	What It Does	Example Use Case
create_before_destroy	Builds the new resource first, then removes the old one	Useful when you want to avoid downtime during updates, like replacing a server
prevent_destroy	Stops Terraform from deleting a resource	Helps protect important resources such as production databases
ignore_changes	Skips tracking changes for certain attributes	Handy when some values are updated outside Terraform, like tags or timestamps
replace_triggered_by	Forces a resource to be recreated when something else changes	For example, redeploy a server when its configuration or image is updated

Q22. How does Terraform handle secrets and sensitive values?

Terraform can mark certain values as sensitive so they don’t get displayed in the terminal output. Even then, those values are still stored in the state file, so keeping that state secure is very important.

In practice, teams often use external secret managers like Vault or cloud secret services instead of putting secrets directly in Terraform.

Q23. What is terraform output and how do you use it to pass values between modules?

output in Terraform is used to show or expose useful values after resources are created, like an IP address or resource ID. You can then pass these values into other modules so different parts of your setup can work together.

Q24. What is the difference between count and for_each in Terraform?

count and for_each are both used to create multiple instances of a resource, but they work in slightly different ways. The following table compares count and for_each.

Feature	count	for_each
Index type	Uses simple numbers like 0, 1, 2	Uses meaningful keys like names or map values
Behaviour when list changes	If the order changes, resources may get recreated	More stable because each resource is tied to a specific key
Best for	When you just need multiple similar resources without much variation	When each resource needs a unique identity or config
Common pitfall	Reordering items can accidentally recreate resources	Slightly harder to use since you need a map or set instead of a list

Advanced Terraform Interview Questions

This section presents advanced Terraform interview questions. The questions focus on architecture-level judgment, multi-cloud strategy, security, and production Terraform patterns. The Terraform interview questions and answers are asked in senior and principal-level interviews.

Q25. How do you structure Terraform code for a large organisation with multiple teams?

In big organisations, Terraform code is usually organised into reusable modules for common infrastructure, while each team has its own separate root configuration for what they manage.

Remote state with locking is used so multiple teams don’t overwrite each other’s work.

Clear ownership is defined per team or environment, along with access controls to keep things safe. Standards like naming rules and CI/CD pipelines help keep everything consistent and easy to maintain.

Q26. What is drift in Terraform-managed infrastructure and how do you detect and handle it?

Drift is when your real infrastructure gets changed outside of Terraform, so it no longer matches your code. You usually spot it by running terraform plan, which highlights any differences between state and reality.

To resolve it, you either apply the Terraform changes to fix it or update your configuration/state if the new setup is intended.

Q27. How do you manage Terraform across multiple cloud providers?

Keep one Terraform setup, but connect it to different cloud providers by configuring each provider where needed. Break your infrastructure into small, reusable modules so each cloud part stays organized and easy to manage.

Store state remotely and use variables or workspaces to handle differences between environments and providers.

Q28. What is Terraform Cloud, and how does it differ from open-source Terraform?

We typically separate each cloud (AWS, Azure, GCP) into its own provider configuration so they don’t interfere with each other. Common patterns like tagging, naming, and networking are put into shared Terraform modules so we don’t repeat code everywhere.

To keep things safe and manageable, we also maintain separate state files per environment and sometimes per provider.

Q29. How do you implement policy-as-code with Terraform?

We write rules that check Terraform plans before anything gets applied, using tools like Sentinel or Open Policy Agent (OPA). These rules help enforce things like mandatory tags, approved resource types, or extra approvals for production changes.

We plug them into the CI/CD pipeline so every change is automatically validated before it reaches the cloud.

Q30. What are provisioners in Terraform, when should you use them, and what are the risks?

Provisioners are basically a way to run scripts or commands on a resource after it’s created in Terraform. They’re best kept as a last resort, mainly for small setup tasks when tools like cloud-init or Ansible can’t handle it cleanly.

The downside is that they can make your setup less predictable and harder to manage because they introduce external steps outside Terraform’s normal flow.

Q31. How do you handle breaking changes in Terraform provider upgrades?

We start by checking the provider changelog to see what’s changed and what might break in our existing setup. Then we try the upgrade in a non-production environment first to make sure everything still works as expected.

We also pin provider versions and move up in small steps so we don’t introduce sudden surprises in production.

Q32. What is terraform_remote_state and when would you use it over direct module output sharing?

terraform_remote_state lets one Terraform setup read outputs from another state file, usually stored in a remote backend like S3 or Terraform Cloud. It’s useful when different projects or teams manage infrastructure separately but still need to share values like VPC IDs or subnet info.
We use it instead of direct module outputs when stacks are independent, but we try not to overuse it since it can create hidden dependencies.

Q33. How do you test Terraform code?

We usually start with terraform validate to catch basic mistakes, then use terraform plan to see exactly what changes will happen. For more confidence, we run automated tests with tools like Terratest or kitchen-terraform to check real infrastructure behaviour.

Before going live, we always try out changes in a staging or sandbox environment to make sure nothing breaks in production.

Q34. What is the Terraform backend and how does backend migration work?

The Terraform backend is basically where your state file lives, like locally, in S3, or in Terraform Cloud, so everyone works with the same source of truth. When you migrate a backend, you’re just moving that state from one place to another without rebuilding any infrastructure.

This is usually done with terraform init -migrate-state, which shifts the state safely so nothing gets lost or recreated.

Terraform Anti-Patterns and Common Mistakes

This section presents Terraform interview questions and answers that evaluate what candidates have seen go wrong and how they fixed it.

1. Hardcoding secrets in configuration files

• Putting passwords, tokens, or keys directly in Terraform code instead of managing them properly.
• This can easily expose sensitive data and create security risks if the repo is shared or leaked.
• Use secret managers like AWS Secrets Manager, Vault, or encrypted variables instead.

2. Using local state in team environments

1. Keeping Terraform state on personal machines when multiple people are working on the same infrastructure.
2. It leads to conflicts, overwritten changes, and broken collaboration.
3. Use a remote backend with locking so everyone works from a single consistent state.

3. Giant root modules

• Writing everything in one massive root module without breaking it into parts.
• It becomes difficult to read, maintain, and safely change over time.
• Split infrastructure into smaller, reusable modules with clear responsibilities.

4. Overusing provisioners

• Depending too much on remote-exec or local-exec to configure resources after creation.
• It makes deployments fragile and breaks Terraform’s declarative nature.
• Prefer native resources or proper configuration tools instead of scripting inside Terraform.

5. Using the wrong looping construct for named resources

• Using count when resources need unique names or identities instead of for_each.
• This often causes unwanted resource replacement when the list order changes.
• Use for_each for stable, key-based resource creation.

6. Not pinning provider versions

• Letting Terraform automatically pull the latest provider versions.
• This can suddenly break your infrastructure due to unexpected changes.
• Always pin provider versions and upgrade them in a controlled way.

7. Direct state manipulation without a plan

• Changing Terraform state directly without reviewing the impact first.
• It can easily lead to a mismatched state and real infrastructure.
• Always inspect changes carefully and follow a plan-driven approach.

8. Misusing workspaces as full environment isolation

• Trying to manage dev, staging, and prod differences only through workspaces.
• This breaks down when environments need different configurations or structures.
• Use separate folders or modules for truly different environments.

9. No drift detection in CI

• Not checking whether the real infrastructure has drifted from the Terraform code.
• Over time, manual changes go unnoticed and create inconsistencies.
• Run scheduled Terraform plan checks in CI to catch drift early.

10. Committing state files to version control

• Pushing .tfstate files into Git repositories.
• This can expose sensitive data and cause state corruption issues.
• Always store state in a secure remote backend and ignore it in version control.

Terraform Scenario and Troubleshooting Questions

This section presents Terraform interview questions on scenario testing. Interview questions on Terraform evaluate if you can diagnose and resolve real problems.

Scenario 1: Your apply succeeds for most resources then fails partway through. How do you recover?

The steps are:

1. Look at the error message first to see exactly which resource and issue caused the failure.
2. Check the Terraform state list to understand what got created successfully before things broke.
3. Inspect the real infrastructure to see what actually exists versus what Terraform thinks exists.
4. Compare your current state file with the configuration to spot any mismatch or partial updates.
5. Fix the underlying issue in the code, dependency, or external service that caused the failure.
6. Run Terraform apply again so Terraform can continue where it left off.
7. If something was created outside Terraform during the partial run, bring it under control using terraform import.
8. Only if necessary, target a specific resource for re-application rather than rerunning everything blindly.

Scenario 2: A team member ran the destroy command on a shared state file by mistake. What do you do?

The steps are:

1. Immediately pause any Terraform activity so nothing else changes while you assess the impact.
2. Verify what was actually deleted in the cloud versus what was only removed from the state file.
3. If you use a remote backend, restore the most recent state version or backup copy.
4. Run a Terraform plan to see what Terraform now thinks is missing or needs to be created.
5. Rebuild the state carefully using Terraform import for any real resources that still exist.
6. Apply changes gradually with terraform apply, watching closely to avoid accidental recreations or deletions.
7. Strengthen safeguards like state locking, versioning, and restricted access to destructive commands.
8. Do a quick review with the team so the same mistake is less likely to happen again.

Scenario 3: Your plan output shows a resource will be destroyed and recreated unexpectedly. How do you investigate?

The steps are:

1. Start by reading the plan output carefully and focus on why Terraform thinks it must replace the resource.
2. Compare the live state with your current code using terraform state show to spot what actually changed.
3. Look for small but important changes in fields like names, IDs, regions, or settings that force recreation.
4. Check recent commits, variable changes, or module upgrades that might have unintentionally altered inputs.
5. Review the provider documentation to see which arguments trigger a “replace” instead of an in-place update.
6. See if any computed values or data sources are shifting between runs and causing instability.
7. If it’s still unclear, narrow the focus with a targeted plan to isolate just that resource.
8. Once you understand the trigger, adjust the config so the change becomes safe or intentional.

Scenario 4: A new team member cannot run plan because the state is locked. How do you resolve this?

The steps are:

1. First, check if someone else is actually running a Terraform command that’s holding the lock.
2. Look at the lock message to see who created it and when it started.
3. If a run is still in progress, it’s usually best to wait it out.
4. If the process crashes, confirm there’s no Terraform job still active anywhere.
5. If it’s clearly stuck, release the lock using Terraform force-unlock with the lock ID.
6. Make sure the team knows before you unlock it so no one runs conflicting changes.
7. After unlocking, try running terraform plan again to confirm everything is working.
8. If this recurs, review your backend setup to reduce stale locks.

Scenario 5: You need to move a resource to a different module without destroying and recreating it. How do you do this?

The steps are:

1. Start by finding the resource’s current address in the state using terraform state list.
2. Create the new module structure in your code where the resource should now live.
3. Move the resource in state using terraform state mv from the old path to the new module path.
4. Update your configuration so the resource definition matches what already exists in the state.
5. Run Terraform plan to make sure Terraform doesn’t think it needs to recreate anything.
6. Fix any differences in arguments if the plan still shows drift.
7. Apply the changes to lock in the new structure without rebuilding the resource.
8. Double-check the state to confirm it’s now tracked under the new module path.

Scenario 6: Two engineers merged at the same time and both pipeline runs are trying to apply simultaneously. What happens and how do you prevent it?

When two engineers trigger deployments at the same time, Terraform blocks one run because the state is locked. If locking is not properly enforced, you can end up with failed applies or conflicting changes to infrastructure.

1. Use a remote backend with state locking (like S3 with DynamoDB or Terraform Cloud).
2. Ensure only one pipeline can run per environment at any given time.
3. Add CI/CD controls to queue builds instead of running them in parallel.
4. Protect main branches so that changes only happen through controlled merges.
5. Keep environments separated so each has its own state file or workspace.
6. Require a plan stage so changes are reviewed before anything is applied.
7. Set up alerts so you know quickly if a pipeline gets stuck or blocked on a lock.

Quick Reference: Terraform Concepts Every Interviewer Tests

Terraform core concepts reference table.

Concept	What it is	Key detail
Terraform	Tool for managing infrastructure as code	You describe what you want, it builds it for you
Provider	Connector to a cloud or service	Each platform like AWS or Azure needs its own provider
Resource	A single piece of infrastructure	Things like servers, databases, or networks
State	Terraform’s memory of what it built	Keeps track of real infrastructure vs code
Backend	Where the state file is stored	Often remote for teams (S3, Terraform Cloud, etc.)
Plan	Preview of changes before applying	Shows what will change without making updates
Apply	Executes the planned changes	Actually creates or modifies infrastructure
Module	Reusable chunk of Terraform code	Helps avoid repeating the same setup
Variable	Input values for your config	Makes setups flexible and reusable
Output	Information returned after apply	Useful for passing values between modules or tools

Terraform quick reference table

Concept	What it is	Key detail
terraform init	Sets up a working directory	Downloads providers and configures backend
terraform plan	Shows what will change	Safe preview before any real action
terraform apply	Makes changes live	Creates or updates real infrastructure
terraform destroy	Tears everything down	Removes all managed resources
terraform validate	Checks config correctness	Catches syntax and basic logic issues
terraform fmt	Cleans up code style	Formats files consistently
terraform import	Brings existing resources under Terraform	Links real infra to state without recreating it
terraform state mv	Moves resources in state	Used when reorganizing code safely
terraform force-unlock	Breaks a stuck lock	Used only when state lock is stale
State file	Terraform’s tracking file	Maps code to real infrastructure
Remote backend	Shared state storage	Enables team access and locking
Provider	Cloud connector	Lets Terraform talk to AWS, Azure, etc.
Module	Reusable code block	Helps structure and reuse infrastructure
Workspace	Separate state environment	Commonly used for dev/test/prod separation
count	Creates multiple copies	Index-based scaling of resources
for_each	Creates multiple copies	Key-based, safer for dynamic sets
depends_on	Forces ordering	Manually defines resource dependency
lifecycle	Controls resource behavior	Can prevent destroy or ignore changes
sensitive = true	Hides output values	Prevents secrets from showing in logs
terraform_remote_state	Reads another state file	Shares outputs between separate stacks

Conclusion

The Terraform interview questions and answers guide is structured for beginners, intermediate, and advanced-level developers. Terraform interview questions and answers present cover IaC fundamentals, core commands, state management, modules, workspaces, security, anti-patterns, and real troubleshooting scenarios.

Terraform interview questions test your practical code development and implementation, along with theory. To crack interview questions on Terraform, you should demonstrate practical skills in using the application. Learn to use all the commands and functions.

To crack interview questions on Terraform, read case studies extensively, practice coding, register for reputed interview preparation courses like Interview Kickstart, and take mock interviews.

References

1. What is Terraform?

Recommended Reads:

• Oracle Software Engineer and Developer Salary — All Levels
• Prepare for Google Software Engineer Early Career Interviews in 2026
• Guide to Transition from Software Engineer to AI Engineer
• Entry Level Software Engineer’s Salary at Amazon
• Top Google Software Engineer Interview Questions You Must Know in 2026