Terraform Interview Questions

1. What is Terraform, and why is it used?

Terraform is an open-source Infrastructure as Code (IaC) tool. It lets you define and manage your infrastructure (like servers, databases, and networks) using configuration files written in HashiCorp Configuration Language (HCL).

It’s used because it allows you to:

Automate provisioning: It automates the process of setting up infrastructure, making it repeatable and consistent.
Manage multi-cloud environments: Terraform works across many different cloud providers like AWS, Azure, and Google Cloud.
Version control: Because your infrastructure is defined as code, you can use systems like Git to track changes, review them, and roll back if necessary.
Ensure consistency: It ensures that your various environments (development, testing, production) are configured identically.

2. Explain the difference between Terraform and other IaC tools like Ansible, Puppet, or Chef.

The main difference lies in what they manage: provisioning versus configuration management.

Terraform is a provisioning tool. It focuses on creating, updating, and destroying the infrastructure itself. It answers the question, “What infrastructure should exist?”
Ansible, Puppet, and Chef are primarily configuration management tools. They focus on installing software and configuring services on already-existing servers. They answer the question, “How should this server be configured?”

3. What is the difference between Terraform and CloudFormation?

Terraform is multi-cloud. It can manage resources on AWS, Azure, Google Cloud, and many other platforms.
CloudFormation is a service specific to AWS. It can only manage resources within the AWS ecosystem.

The key distinction is their scope. Terraform offers a single way to manage infrastructure across multiple clouds, while CloudFormation is limited to AWS.

4. What are Terraform providers, and how do they work?

A provider is a plugin that lets Terraform interact with a specific cloud or service. It’s the essential connection between your Terraform code and the API of the platform you’re managing.

Each provider contains the logic needed to authenticate with a service (like AWS or GitHub) and exposes its resources and data to Terraform.
When you use a resource like aws_instance, the AWS provider is what translates that code into the correct API calls to create an EC2 instance in your account.

5. Explain the concept of Terraform state.

The Terraform state file is a crucial file that stores a snapshot of your infrastructure’s current state. It’s the source of truth for what Terraform has created.

It keeps a record of:

The connection between your configuration and the real resources.
The attributes of the resources it has created.

Terraform uses this state file to understand what changes to make when you run terraform apply. Without it, Terraform wouldn’t know which resources it’s managing or how they are configured.

6. What are the different types of Terraform state backends?

A backend is where Terraform stores the state file. The two main types are:

Local Backend (default): The state file is stored on your machine. This is good for personal use but not for teams.
Remote Backend: The state file is stored in a shared location, like an Amazon S3 bucket or Azure Storage Account. This is the recommended approach for teams as it enables state locking and prevents conflicts.

7. Why do we need a remote backend in Terraform?

A remote backend is essential for production use and team collaboration for several reasons:

State Locking: It prevents multiple people from making changes to the state file at the same time, which could corrupt it.
Team Collaboration: It allows everyone on a team to use a single, central state file.
Security: It lets you securely store your state file and any sensitive data it might contain.
Durability: Your state file is stored in a durable location, so you don’t lose your infrastructure’s state if your local machine fails.

8. How does Terraform handle dependencies between resources?

Terraform automatically figures out the order in which to create resources by inferring dependencies. For instance, a security group rule that references a database’s ID won’t be created until the database itself exists.

Implicit Dependencies: Most dependencies are implicit. For example, any resource that references a value from another resource will automatically wait for that other resource to be created first.
Explicit Dependencies: You can also use the depends_on meta-argument to manually specify a dependency when Terraform can’t infer it.

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

terraform plan is a dry-run command. It shows you exactly what changes Terraform will make to your infrastructure without actually making them. It’s used to review and confirm changes before they are applied.
terraform apply is the execution command. It applies the changes from the plan to your infrastructure, creating, updating, or deleting resources.

10. Explain the purpose of the terraform init command.

The terraform init command is the first command you run in a new or existing Terraform directory. Its main purpose is to prepare the working directory.

This involves:

Downloading Providers: It downloads and installs all the provider plugins your configuration needs.
Configuring Backends: It configures the backend you’ve specified (e.g., S3).
Downloading Modules: If you’re using remote modules, it downloads them as well.

Essentially, terraform init gets your directory ready for any other Terraform commands like plan or apply.

11. What are Terraform modules, and why are they used?

A Terraform module is a reusable, self-contained set of Terraform configuration files. Every Terraform configuration, even a root one, is implicitly a module. However, when the term is used, it usually refers to child modules—directories containing configuration that are called from a parent (root) module.

Modules are used for:

Reusability: They allow you to define a common infrastructure pattern (e.g., an AWS VPC or a Kubernetes cluster) once and reuse it across multiple projects or environments.
Encapsulation and Organization: They help organize large configurations into smaller, manageable, and logical units.
Consistency: They enforce consistent deployment patterns across your organization.

12. How do you create and use a Terraform module?

Creating a Module

Organize files: Create a new directory (e.g., modules/vpc) to house the module’s files.
Define configuration: Place the standard configuration files inside the directory:
- main.tf: Contains the resource definitions.
- variables.tf: Contains all input variables (parameters for the module).
- outputs.tf: Contains all output variables (values the module exports).

Using a Module

To use a module, you call it from your main configuration file (main.tf in the root module) using the module block:

module "my_network" {
  source = "./modules/vpc"  # Path to the module directory
  cidr_block = "10.0.0.0/16" # Passing an input variable
  name = "prod-vpc"
}

After defining the source, you run terraform init to download the module if it’s remote, or prepare it if it’s local.

13. What are input variables in Terraform?

Input variables (defined using the variable block) act as parameters for a Terraform module or configuration. They allow you to customize the configuration without altering the underlying code.

They serve two main purposes:

Customization: They allow different environments (like Dev, QA, Prod) to use the same configuration while applying different values (e.g., instance size, region, or count).
Externalizing Configuration: They separate configuration values from the resource definitions, making the code cleaner and more reusable.

14. What are output variables in Terraform?

Output variables (defined using the output block) are used to export values from a Terraform configuration or module. They act as return values.

They are primarily used for:

Displaying Information: Showing important information to the user after deployment (e.g., the public IP address of a newly created server or a website URL).
Cross-Configuration Communication: Allowing a parent module or a separate configuration to easily read and use resource attributes created by a child module (e.g., passing the ID of a VPC to a separate configuration that will deploy subnets into it).

15. How do you pass variables to Terraform?

There are several ways to provide values for input variables, listed in increasing order of precedence (highest precedence wins):

Default Values: Defined in the variable block using the default argument.
Environment Variables: Variables prefixed with TF_VAR_ (e.g., TF_VAR_instance_type).
terraform.tfvars file: Automatically loaded if present in the working directory.
Custom .tfvars file: Loaded using the -var-file argument (e.g., terraform apply -var-file="prod.tfvars").
Command Line Arguments: Passed directly using the -var argument (e.g., terraform apply -var="region=us-east-1").

16. What are the different ways to manage secrets in Terraform?

Terraform’s state file contains sensitive information, and while inputs and outputs can be marked as sensitive, the state file itself should be protected. Since Terraform is not a dedicated secret manager, secrets are typically managed externally:

Secret Manager Services: The most secure way is using dedicated external services like:
- AWS Secrets Manager or AWS KMS
- Azure Key Vault
- HashiCorp Vault
- These services securely store the secrets, and Terraform uses data sources to read the secrets at runtime, injecting them into the configuration (e.g., passing a database password to a resource).
Environment Variables: For basic configurations, secrets can be passed via environment variables to avoid storing them directly in .tfvars files.

17. What are Terraform workspaces?

Terraform workspaces allow you to manage multiple distinct state files for a single configuration. This is primarily useful for managing multiple non-production environments (like Dev, Test, QA) that use the exact same configuration code but target different physical infrastructure.

By default, you are in the workspace named default.
Each workspace maintains its own, isolated state file.

Note: For production and complex environment isolation, using separate directories or separate source code repos is often preferred over workspaces, but they are highly useful for staging and testing.

18. How do you use workspaces in Terraform?

The primary commands for managing workspaces are:

terraform workspace new [name]: Creates a new workspace and switches to it (e.g., terraform workspace new dev).
terraform workspace select [name]: Switches to an existing workspace (e.g., terraform workspace select prod).
terraform workspace show: Shows the name of the current workspace.
terraform workspace list: Lists all existing workspaces.
terraform workspace delete [name]: Deletes a workspace (after destroying its associated resources).

When you run terraform apply after selecting a workspace, Terraform uses that workspace’s dedicated state file.

19. What is the difference between local and remote state in Terraform?

Feature	Local State	Remote State
Storage Location	Stored on the machine running Terraform (`terraform.tfstate`).	Stored in a secure, remote location (e.g., S3, Azure Blob Storage, Terraform Cloud).
Collaboration	Not suitable for teams; state is isolated to one machine.	Essential for teams; all team members share the same source of truth.
State Locking	No built-in locking mechanism.	Most remote backends provide state locking to prevent conflicts.
Security/Durability	Risk of corruption or loss if the local machine fails.	Highly durable, backed up, and more secure than local storage.

Remote state is the standard for any professional or team environment.

20. What is state locking in Terraform, and why is it important?

State locking is a mechanism used by remote backends to prevent concurrent operations on the same state file.

When a user executes a modifying command (like terraform apply or terraform refresh):

The backend attempts to acquire a lock on the state file.
If successful, the operation proceeds.
If another user tries to run a command while the lock is active, their command will be blocked and an error will be returned.
Once the operation is complete, the lock is released.

Importance: State locking is critical because running concurrent operations on the same state file would lead to state corruption. If two people try to create resources or destroy them simultaneously, the state file becomes inconsistent with the actual infrastructure, potentially leading to data loss or incorrect resource tracking.

21. How does Terraform detect resource drift?

Terraform detects resource drift by comparing the current state of your real-world infrastructure with the state recorded in your Terraform state file. When you run commands like terraform plan or terraform apply, Terraform first performs a refresh. This refresh action queries the cloud provider’s API to get the latest attribute values for all managed resources. It then compares these live values to the values stored in the state file. If a difference is found—for example, a resource was manually deleted or an attribute was changed outside of Terraform—it’s identified as drift. Terraform will then propose changes to either correct the drift or inform you of the change in the execution plan.

22. What are Terraform data sources?

Terraform data sources allow you to fetch or “read” information about resources that are not managed by your current Terraform configuration. They are a read-only way to get data from a provider.

They are used to:

Reference existing resources: Get the ID or other attributes of a resource that was created manually or by a different Terraform configuration. For example, you can use a data source to get the details of a pre-existing VPC or a specific AMI.
Query provider information: Retrieve dynamic data, such as the available availability zones in a region or the details of a specific user.

A data source block is defined with the data keyword, followed by the provider and type (e.g., data "aws_ami" "ubuntu").

23. Explain the difference between count and for_each in Terraform.

Both count and for_each are meta-arguments used to create multiple instances of a resource or module.

Feature	`count`	`for_each`
Input	Takes a whole number (`integer`).	Takes a `map` or a `set` of strings.
Behavior	Creates a list of instances. Resources are referenced by an index (e.g., `aws_instance.server[0]`, `aws_instance.server[1]`).	Creates a map of instances. Resources are referenced by a key (e.g., `aws_instance.server["web"]`, `aws_instance.server["db"]`).
Best Use Case	When you need a simple, homogeneous list of resources and the number of resources is the only thing that changes.	When you need more complex or heterogeneous resources where each instance has a unique name or specific configuration values. It’s more resilient to changes because adding or removing items won’t cause other resources to be replaced.

Using for_each is generally a better practice because it avoids issues where changes in the list order with count can cause resources to be destroyed and recreated unnecessarily.

24. What is the difference between depends_on and implicit dependencies?

Implicit dependencies are the standard way Terraform handles resource ordering. Terraform automatically builds a dependency graph by analyzing resource configurations. For example, if an EC2 instance’s security group is set to aws_security_group.web.id, Terraform knows it must create the security group before it creates the instance. This is the preferred method because it’s automatic and less prone to error.

Explicit dependencies are defined using the depends_on meta-argument. You use this to manually tell Terraform that one resource depends on another, even if there is no direct reference between them. This is typically used as a last resort when Terraform can’t infer a dependency on its own, such as when a resource is created but a separate configuration needs to wait for it to be fully ready before a provisioning script can run on it. It’s a signal to Terraform, “Don’t create this resource until that one is finished.”

25. What are Terraform provisioners, and when should you use them?

Terraform provisioners are a last-resort mechanism used to execute scripts or commands on a local or remote machine after a resource has been created. They are not an IaC best practice and should be used sparingly.

A common example is using a remote-exec provisioner to run a shell script on an EC2 instance to install software or configure it.

You should consider using a provisioner only when a resource’s configuration cannot be handled by the provider’s API. For most use cases, it’s better to use dedicated configuration management tools like Ansible, Puppet, or Chef, or leverage cloud-native services like AWS Cloud-init or Azure Custom Script Extension.

26. What are dynamic blocks in Terraform?

A dynamic block is a feature that allows you to generate nested configuration blocks dynamically within a resource. Instead of hard-coding multiple similar blocks, you can iterate over a list or map to create them.

This is extremely useful when the number of a certain nested block is not fixed. For example, you can use a dynamic block to create multiple ingress rules for an aws_security_group resource based on a variable list of ports.

resource "aws_security_group" "example" {
  name = "example-sg"
  vpc_id = var.vpc_id

  dynamic "ingress" {
    for_each = var.ports
    content {
      from_port = ingress.value
      to_port = ingress.value
      protocol = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }
  }
}

27. How do you manage multiple environments in Terraform?

There are two primary ways to manage multiple environments (e.g., development, staging, production):

Workspaces: This approach uses a single Terraform configuration and separates the state files using terraform workspace. This works well for simple, non-production environments that are nearly identical.
Separate Directories/Folders: This is the more common and robust method. You create a directory for each environment (e.g., prod/, dev/) and call a shared module from within each one. This allows for environment-specific variables, custom resources, and gives you more control over each environment’s configuration.

The separate directories approach is generally preferred for production deployments because it provides clearer separation and reduces the risk of accidentally applying changes to the wrong environment.

28. What are some best practices for structuring Terraform code?

Modularize your code: Break down your configuration into reusable modules (e.g., modules/vpc, modules/database).
Use a standard directory layout: Organize your directories by environment (/prod, /staging) with a shared modules directory.
Keep your root module simple: The root module should primarily be a call to other modules and variable definitions, not a place to define resources.
Use remote state: Always use a remote backend like S3 or Azure Blob Storage for state management to enable collaboration and state locking.
Use variables and outputs: Separate variable definitions from resource code and expose important information using outputs.
Avoid hard-coding values: Use variables to make your code more flexible and reusable.

29. What is the difference between terraform refresh and terraform apply?

terraform refresh (which is run implicitly by plan and apply) reads the current state of resources from the cloud provider and updates the state file to reflect any manual changes (drift). It only updates the state file and does not make any changes to your real-world infrastructure.
terraform apply takes the desired state from your configuration and the current state from the state file, generates a plan, and applies that plan to your infrastructure to make it match the desired state. This is the command that actually creates, modifies, or destroys resources.

terraform refresh has been largely deprecated in favor of terraform plan which provides a more transparent and safe way to check for drift.

30. How do you perform a targeted resource deployment in Terraform?

You can perform a targeted deployment on a specific resource using the -target flag.

terraform apply -target=aws_instance.web_server

This command will tell Terraform to only consider the specified resource (aws_instance.web_server) for its plan and apply actions.

Note: Using -target is generally considered a bad practice and is discouraged in production. It can lead to state file inconsistencies, as it ignores any dependencies or related resources. It should only be used for debugging or recovery in exceptional circumstances. The preferred method for making small changes is to make them in the code and let terraform apply figure out the most efficient way to get to the desired state.

31. What happens when you delete the Terraform state file?

When you delete the Terraform state file (terraform.tfstate), Terraform loses its record of the infrastructure it manages. It will no longer know about the resources that were previously created.

Loss of Association: Terraform loses the link between your configuration code and the real-world resources.
Terraform thinks the infrastructure is gone: When you run terraform plan, Terraform will see all the resources in your configuration as new and will propose to create them again. This can lead to duplicate resources if you run terraform apply.
Destructive Operations: If you try to destroy resources, Terraform won’t find them in the state and will not be able to destroy them, leaving them as orphaned resources that are difficult to manage.

Deleting the state file is highly discouraged and can cause significant issues, so it should only be done in a controlled and intentional way, typically as part of a manual recovery or a complete wipe-and-rebuild process.

32. What are some ways to upgrade provider versions in Terraform?

You can upgrade provider versions in Terraform by updating the version constraint in your configuration and then running terraform init.

Specify a new version constraint: You can edit the provider block in your code to a new version. For example: version = "~> 3.0" to version = "~> 4.0".
Run terraform init -upgrade: This command will force Terraform to disregard the currently installed provider versions and download the newest versions that satisfy your version constraints.

The terraform.lock.hcl file, which tracks the exact versions, is updated during this process to reflect the new provider versions.¹

33. What is the purpose of the .terraform.lock.hcl file?

The .terraform.lock.hcl file is a dependency lock file. Its purpose is to lock the exact versions of providers used in your project to ensure consistent and repeatable builds.

Consistent Execution: It guarantees that every time terraform init is run (by you, a coworker, or a CI/CD pipeline), it will download the exact same provider versions, preventing unexpected changes or issues from a provider update.
Security and Stability: It provides an audit trail and a way to ensure that a provider’s behavior doesn’t change unexpectedly between runs, which could impact the stability of your infrastructure.

This file should be checked into version control alongside your configuration files.²

34. How do you import existing infrastructure into Terraform?

You can import existing, unmanaged infrastructure into your Terraform state using the terraform import command.

Write the configuration: First, write a resource block in your Terraform configuration that exactly matches the resource you want to import. This block must have the same resource type, name, and any required arguments.
Run the import command: Use the command terraform import [resource_address] [resource_id].
- resource_address: The address of the resource in your configuration (e.g., aws_instance.web).
- resource_id: The actual ID of the existing resource in the cloud provider (e.g., i-08a0d2f094b8e6122).
Validate: After importing, run terraform plan to ensure that the imported resource’s state matches your configuration and that there are no proposed changes.

This process adds the resource to your state file without creating it, effectively bringing it under Terraform’s management.

35. What are Terraform resource taints?

The terraform taint command was used to manually mark a resource as “tainted.”³ A tainted resource is one that Terraform believes is in a broken state and must be replaced.

Behavior: When you run terraform plan after a resource is tainted, Terraform will propose to destroy that resource and then create a new one with the same configuration.

Note: The terraform taint command has been deprecated.⁴ The new, preferred method is to use terraform state replace-resource. This command has a more predictable and targeted effect, allowing you to explicitly plan to replace a resource.

36. How do you destroy a specific resource in Terraform?

You can destroy a single, specific resource using the -target flag with the terraform destroy command.

terraform destroy -target=aws_instance.web_server

This will target only the aws_instance named web_server for destruction, leaving all other resources in your configuration untouched.

Warning: Similar to the -target flag with apply, this is generally discouraged for production use as it can lead to state inconsistencies. It should only be used in specific, carefully managed situations like debugging or recovery.

37. What is the difference between soft delete and hard delete in Terraform resources?

This distinction is more about the cloud provider’s API behavior than a native Terraform concept.

Hard Delete: This is the typical behavior when you destroy a resource. The resource is permanently deleted from the cloud provider and cannot be recovered.
Soft Delete: Some resources in cloud providers (like databases or storage buckets) have a soft delete feature. When you “destroy” them, they are not permanently deleted but are moved to a protected or pending-deletion state for a specified period (e.g., 30 days). Terraform’s destroy command will trigger this behavior if the provider’s API supports it, and you’ll typically need to wait for the grace period to expire for the resource to be permanently gone.

You would need to check the provider documentation to see if a resource type supports soft delete.

38. How do you handle versioning of Terraform modules?

Versioning of Terraform modules ensures that your infrastructure is predictable and that changes to a module don’t unexpectedly break a consuming configuration.

Source URL: When you reference a module, you can specify a version in the source argument.⁵
- For local modules, you don’t version them directly.
- For remote modules (from a registry, Git repo, or S3 bucket), you append a version constraint to the source URL.

Example with a Git repository:

module "vpc" {
  source = "git::https://example.com/vpc.git?ref=v1.2.0"
}

This specifies that Terraform should use the v1.2.0 tag in the Git repository for the module.

39. What are some common Terraform workflow commands in CI/CD pipelines?

A typical CI/CD pipeline for Terraform uses a standard set of commands to automate the process.⁶

terraform init: Initializes the working directory, downloads providers, and configures the backend.
terraform fmt -check: Checks that the configuration files are properly formatted.⁷
terraform validate: Validates the syntax and configuration, checking for errors.
terraform plan -out=tfplan: Creates a plan and saves it to a file.⁸ This is often run in a “planning” stage.
terraform apply "tfplan": Applies the saved plan to the infrastructure. This is run in a separate, approval-gated “apply” stage to ensure changes are reviewed.

This workflow ensures that the plan remains the same between the review and application stages.

40. What is the difference between local-exec and remote-exec provisioners?

Both are provisioners used to run commands, but they execute the commands in different locations.⁹

local-exec: Executes a command or script on the local machine where Terraform is running. This is useful for tasks like running a script to generate a configuration file before a resource is created or performing cleanup after a resource is destroyed.
remote-exec: Executes a command or script on the remote machine that was just created.¹⁰ This requires a connection block (e.g., SSH or WinRM) to the remote host. This is often used to install software or configure services on a newly launched server.

In general, it’s a best practice to use other tools like Cloud-init or a configuration management system instead of provisioners.

41. What are Terraform functions, and can you give examples?

Terraform functions are built-in tools used to transform and process values within your configuration. They allow you to manipulate strings, numbers, and collections (lists, maps) to create dynamic and reusable code. Functions make your configurations more powerful and flexible.

Examples

String Functions:
- upper("hello") returns "HELLO".
- replace("hello world", "world", "terraform") returns "hello terraform".
Numeric Functions:
- ceil(1.5) returns 2.
- min(5, 2, 8) returns 2.
Collection Functions:
- length(["a", "b", "c"]) returns 3.
- keys({"a" = 1, "b" = 2}) returns a list ["a", "b"].
Encoding Functions:
- base64encode("secret") returns "c2VjcmV0".

42. How do you reference outputs from one module into another module?

To reference outputs from one module into another, you first define an output variable in the source module’s outputs.tf file. Then, in the consuming module’s configuration, you can access that output using the module block’s name, followed by the output variable name.

Example:

Module 1 (VPC):

# modules/vpc/outputs.tf
output "vpc_id" {
  value = aws_vpc.main.id
}

Module 2 (EC2):

# main.tf
module "my_vpc" {
  source = "./modules/vpc"
}

module "my_ec2" {
  source = "./modules/ec2"
  vpc_id = module.my_vpc.vpc_id # Referencing the output
}

43. What are Terraform expressions?

Terraform expressions are the fundamental building blocks used to define values, access data, and reference resources within your configuration files. They are typically used on the right side of an equals sign (=) and can be literal values, function calls, or references.

Examples:

Literal values: name = "my-server"
References: subnet_id = aws_subnet.public.id
Interpolations: name = "web-server-${count.index}"
Functions: name = upper(var.environment)

44. What is the difference between terraform state list and terraform show?

terraform state list lists all the resources that Terraform is currently managing, as recorded in the state file. It provides a simple list of resource addresses, like aws_instance.web or aws_security_group.allow_ssh. It does not show any resource attributes.
terraform show provides a detailed, human-readable view of the entire state file. It displays all the resources, their addresses, and every attribute and its value, including sensitive data. It can also be used to show a saved plan file.

45. What is drift detection, and how does Terraform handle it?

Drift detection is the process of identifying differences between your Terraform code’s desired state and the real-world state of your infrastructure. This “drift” happens when resources are manually changed outside of Terraform (e.g., a security group rule is added directly in the AWS console).

Terraform handles it by automatically performing a refresh operation at the beginning of plan or apply. This refresh queries the cloud provider’s API to get the latest state of all managed resources. It then compares this live data with the state file. Any differences are flagged as drift, and the execution plan will propose changes to bring the infrastructure back in line with the configuration.

46. How do you roll back infrastructure changes with Terraform?

Terraform does not have a built-in rollback command. The standard way to roll back changes is to revert your configuration to a previous version using your version control system (like Git) and then run terraform apply.

Workflow:

Use git log to find the commit hash of the last known good configuration.
Run git checkout <commit_hash> to revert your code.
Run terraform plan to see the changes that will be made to revert the infrastructure.
Run terraform apply to execute the rollback.

47. What is the difference between declarative and imperative approaches in IaC, and where does Terraform fit?

Declarative: You define the desired state of your infrastructure, and the tool figures out how to get there. You specify “what” you want, not “how” to achieve it.
Imperative: You provide a list of commands or steps that must be executed in a specific order. You specify “how” to achieve the desired state.

Terraform is a declarative tool. You write HCL to describe the end state of your infrastructure, and Terraform handles the ordering, creation, and modification of resources to match that state. In contrast, a bash script to provision resources would be an imperative approach.

48. How does Terraform ensure idempotency?

Idempotency is the principle that an operation will produce the same result regardless of how many times it’s executed. Terraform achieves this by using its state file.

Terraform’s state file acts as a source of truth, recording the current state of the managed infrastructure.
Before any changes, Terraform performs a plan. It compares the desired state (from your configuration) with the current state (from the state file and a refresh of the real infrastructure).
If the two states already match, Terraform will produce a plan that shows “no changes,” and no action will be taken. If there are differences, it will produce a plan to resolve only those differences.

This process ensures that running terraform apply on a configuration that has already been deployed will not cause any changes unless the configuration or the infrastructure itself has changed.

49. What are some limitations of Terraform?

No built-in configuration management: Terraform is not designed to install software or configure services on a server after it’s been created. You need to use other tools like Ansible or Chef for that.
State file management: The state file is critical and must be managed carefully. If it’s lost or corrupted, it can be difficult to recover and may result in lost infrastructure.
Not a full CI/CD solution: Terraform provides the core IaC engine but requires integration with other tools (like Jenkins, GitHub Actions, or GitLab CI) for a complete CI/CD pipeline.
Resource dependencies: While Terraform handles most dependencies implicitly, complex or non-standard dependencies sometimes require using the depends_on meta-argument, which can make configurations more complex.

50. How do you debug issues in Terraform?

Debugging in Terraform involves using various tools and techniques to understand what’s going wrong.

Read the error message: Terraform’s error messages are often very descriptive and point directly to the cause of the problem.
Use terraform plan: Always use terraform plan to review the proposed changes before applying them. This is the first line of defense for debugging.
Increase log verbosity: Set the TF_LOG environment variable to a higher level (e.g., TF_LOG=INFO, TF_LOG=DEBUG, TF_LOG=TRACE). This will provide detailed logs of the API calls and other operations Terraform is performing.
Use terraform console: This interactive console allows you to test expressions, functions, and variable values to see how they are evaluated.
Check provider documentation: Errors often arise from incorrect resource arguments or missing required fields. The provider’s documentation is the authoritative source for these details.
Validate the code: Use terraform fmt to format the code correctly and terraform validate to check for syntax and configuration errors before attempting to plan or apply.

51. What are the benefits of using Terraform over manual provisioning?

Using Terraform offers several benefits over manual provisioning. It allows you to manage infrastructure as code, which makes the provisioning process automated and repeatable. This approach significantly reduces human error and ensures that your environments are consistent across development, staging, and production. It also enables version control, allowing you to track all changes, roll back to previous versions, and collaborate on infrastructure definitions in the same way you would with application code. Terraform can manage infrastructure across different cloud providers, providing a single, consistent workflow for managing multi-cloud environments.

52. Explain the concept of “desired state” in Terraform.

In Terraform, the “desired state” is the final, ideal configuration of your infrastructure as defined in your .tf files. It’s a key tenet of Terraform’s declarative approach. You declare what you want your infrastructure to look like (e.g., one EC2 instance, two databases, and a VPC), and Terraform’s job is to make the real-world infrastructure match that desired state. Terraform figures out the “how”—the specific API calls and the order of operations—to get from the current state to the desired state.

53. What is the role of HCL (HashiCorp Configuration Language) in Terraform?

HCL is a configuration language developed by HashiCorp specifically for its tools, including Terraform. Its primary role is to provide a human-readable, yet machine-friendly, way to define infrastructure. HCL is designed to be easy for a user to write and understand, but it can also be parsed into JSON for machine processing. It supports expressions, variables, and modules, making it flexible enough to describe complex infrastructure in a concise way.

54. Can Terraform work with multiple cloud providers in the same configuration?

Yes, Terraform can work with multiple cloud providers in the same configuration. This is one of its core strengths. You simply define a provider block for each cloud you want to interact with (e.g., aws, azurerm, google). Terraform manages the resources from all providers in a single state file and figures out the dependencies between them, even if those dependencies span different cloud environments.

55. How do you define resource dependencies in Terraform?

Terraform automatically manages most dependencies through implicit dependencies, which are inferred from resource references. For example, if a security group rule references the ID of a VPC, Terraform knows it must create the VPC before it can create the rule. You only need to use the depends_on meta-argument for explicit dependencies, which are required when Terraform cannot infer the dependency on its own. It’s generally best practice to rely on implicit dependencies whenever possible.

56. What are Terraform meta-arguments?

Terraform meta-arguments are special arguments that can be used on any resource or module block to change its behavior. Unlike regular arguments that are specific to a resource type, meta-arguments are universal. Common meta-arguments include count, for_each, depends_on, and lifecycle. They provide control over how resources are created, updated, and destroyed.

57. What is the difference between lifecycle meta-arguments like create_before_destroy and prevent_destroy?

Both create_before_destroy and prevent_destroy are lifecycle meta-arguments used for managing resource changes.

create_before_destroy = true tells Terraform to create a new version of a resource before it destroys the old one. This is useful for avoiding downtime, especially for resources like databases that cannot be recreated without affecting availability.
prevent_destroy = true acts as a safeguard to prevent a resource from being destroyed. If you try to run terraform destroy or an apply that would destroy that resource, Terraform will return an error. This is a crucial safety measure for protecting critical infrastructure.

58. How do you use conditional expressions in Terraform?

Conditional expressions in Terraform are a way to make your configurations dynamic by using a ternary operator: condition ? true_val : false_val. They allow you to define a resource argument’s value based on a condition, typically a variable. This is a common way to manage different configurations for different environments without using multiple files.

Example:

instance_type = var.is_production ? "t2.large" : "t2.micro"

This expression sets the instance type to a large size for production and a micro size for other environments.

59. What is the difference between terraform plan -out and terraform apply with a plan file?

terraform plan -out=<file_name> saves the generated execution plan to a file. This is a crucial part of a CI/CD pipeline, as it ensures that the exact plan that was reviewed is the one that is applied. The plan file is binary and cannot be edited.
terraform apply <file_name> takes the previously saved plan file and applies it to the infrastructure. When you use a plan file, Terraform skips the planning phase and goes straight to applying the changes, which is a safer and more consistent workflow. Running terraform apply without a plan file will generate a new plan and then immediately apply it.

60. How do you share Terraform state between team members?

Sharing Terraform state between team members is essential for collaboration and preventing state corruption. The best practice is to use a remote backend, such as an Amazon S3 bucket, Azure Blob Storage, or Terraform Cloud. A remote backend stores the state file in a central, secure location and provides state locking, which prevents multiple users from running commands that modify the state file simultaneously. This ensures that the entire team is always working with the same, up-to-date source of truth for the infrastructure.

61. How do you handle sensitive data in Terraform outputs?

There are two primary methods for handling sensitive data in Terraform outputs: using the sensitive argument and leveraging a secrets management system.

`sensitive` Argument

The sensitive argument is a meta-argument you can add to any output block. When you set this to true, Terraform will hide the value of the output in the console after terraform apply or when you run terraform show. Instead of displaying the sensitive value, it will show a message like <sensitive>. The value is still stored in the state file, but its display is suppressed for security.

Secrets Management Systems

While the sensitive argument prevents the display of a value, the data is still stored in plain text in the state file. For enterprise-level security, the best practice is to avoid storing sensitive data in Terraform’s state file altogether. You should instead use a dedicated secrets management system like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. Terraform can then use a data source to dynamically fetch the secret at runtime, ensuring the sensitive value is never written to the state file.

62. What is the difference between local values and variables in Terraform?

Variables are inputs to a Terraform configuration or module. They are how you pass data into your code, making it reusable and dynamic. Variables can have default values, but their primary purpose is to receive external input from a user, an environment file, or a CI/CD pipeline.

Local values are temporary, named expressions that are calculated once and can be referenced throughout a configuration. They are used to avoid repeating complex expressions or values. Local values are internal to a configuration and are not exposed as inputs.

63. How do you restrict provider versions in Terraform?

You restrict provider versions in Terraform by using a version constraint in the required_providers block. This constraint tells Terraform which versions of a provider it is allowed to download and use. This is crucial for ensuring that your infrastructure deployments are consistent and reproducible.

Example:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

In this example, the version constraint ~> 4.0 allows Terraform to use any provider version from 4.0 up to, but not including, 5.0.

64. What happens if you change a resource name in Terraform configuration?

If you change a resource name in your Terraform configuration (e.g., from aws_instance.web to aws_instance.web_server), Terraform sees the original resource as one that needs to be destroyed and the new one as a resource that needs to be created. It does not automatically recognize that the old and new names refer to the same physical resource. To avoid this destructive behavior, you can use the terraform state mv command to manually rename the resource in the state file, matching the new name in your code.

65. Explain how Terraform manages immutable and mutable infrastructure changes.

Immutable infrastructure is an approach where resources are not changed after they are deployed. Any update or change requires a new resource to be created, and the old one is destroyed. Terraform supports this by destroying and recreating resources when a change to a critical attribute is detected.
Mutable infrastructure is an approach where resources can be updated in place. Terraform supports this by updating existing resources when you change an attribute that a provider allows to be modified without replacement. Terraform handles both types of changes gracefully, figuring out which action to take based on the resource type and the specific attribute that was changed.

66. What is the difference between resource arguments and attributes in Terraform?

Resource arguments are the parameters you define in your configuration file to specify the desired state of a resource (e.g., instance_type, ami, subnet_id). They are inputs to the resource.
Resource attributes are the properties of a resource that exist in the real world after it’s been created (e.g., public_ip, id, instance_state). These are typically read-only values that can be referenced by other resources or exposed via outputs.

67. How do you organize Terraform projects for a large enterprise setup?

For a large enterprise, a robust project structure is essential. The common approach is a monorepo with multiple directories organized by environment and application.

Root directory: Contains a single main.tf for each environment (dev, staging, prod) that calls modules.
Modules directory: Contains reusable modules for common infrastructure patterns (e.g., modules/vpc, modules/eks-cluster).
Environment-specific files: Variables for each environment are stored in separate files (dev.tfvars, prod.tfvars). This approach provides clear separation, reusability, and control over changes across different environments.

68. What is the difference between a module source from registry, GitHub, and local path?

Registry source: The module is hosted on a central registry (like the public Terraform Registry or a private one). The source is a simple string, and Terraform handles the download.
GitHub source: The module is located in a Git repository. You reference it using a Git URL, optionally specifying a branch or tag. Terraform will clone the repository to use the module.
Local path: The module is located on your local file system, typically within the same project. You reference it using a relative path, and Terraform uses the files directly without cloning or downloading.

69. How do you test Terraform code?

Testing Terraform code is different from testing application code. The primary testing methods are:

Syntax and formatting checks: terraform fmt and terraform validate check for syntax errors.
Static analysis: Tools like Terrascan or Checkov analyze your code for security and compliance issues without deploying it.
Dry-run validation: Running terraform plan is a form of testing that shows you exactly what changes will be made before you apply them.
Integration testing: For more robust testing, you can use tools like Terratest or Infracost to deploy your infrastructure in a dedicated test environment, run tests against it, and then destroy it.

70. What is the purpose of terraform validate?

The purpose of terraform validate is to check your Terraform configuration files for syntax errors and internal consistency. It ensures that your code is syntactically correct and can be parsed by Terraform. This command is a preliminary check that should be run before terraform plan to catch simple mistakes like missing curly braces or incorrect argument names, without needing to connect to a cloud provider.

71. How does terraform fmt help in Terraform workflows?

The terraform fmt command is used to automatically format your Terraform configuration files to a consistent, canonical style. It helps maintain code readability and a uniform standard across a team. This is particularly useful in collaborative environments where different developers may have different formatting habits. By running terraform fmt before committing code, teams can avoid unnecessary formatting changes in their commits and ensure a clean, consistent codebase.

72. What is the purpose of the .terraform directory?

The .terraform directory is a hidden folder created by the terraform init command. Its purpose is to store the necessary files and data for Terraform to operate. This includes:

Downloaded providers: It holds the provider plugins that Terraform needs to interact with your cloud or service.
Modules: It stores any remote modules that are referenced in your configuration.
Backend configuration: It contains configuration details for your remote state backend.

The .terraform directory should never be manually edited or checked into version control. It is generated automatically and is specific to a local environment.

73. How do you roll out infrastructure changes gradually with Terraform?

Terraform’s core design is for a single, desired state. However, you can achieve gradual rollouts like blue-green or canary deployments with careful planning and the use of modules and variables.

Blue-Green Deployment: You define two identical sets of infrastructure as separate modules: “blue” (the current version) and “green” (the new version). You deploy the “green” environment, test it, and then update a load balancer or DNS record to switch all traffic to it. After the switch, the “blue” environment can be destroyed.
Canary Deployment: A similar approach where you deploy a small percentage of new infrastructure as a separate module (“canary”). You then gradually increase the traffic to the canary instance until it’s handling 100% of the traffic.

Both strategies require managing separate modules and using variables to control which version is active.

74. What is the difference between terraform destroy and manually deleting resources?

The key difference is that terraform destroy also updates your state file.

terraform destroy: This command reads the state file, identifies all the resources Terraform is managing, and sends API calls to the provider to delete them. Importantly, it then removes those resources from the state file, ensuring Terraform no longer tracks them. This is the correct and safe way to remove infrastructure.
Manually deleting resources: This is done by directly using the cloud provider’s console or CLI. While the physical resource is deleted, Terraform’s state file is not updated. When you run terraform plan again, Terraform will see that the resource is missing from the real world but still in its state file, and will propose to recreate it, leading to drift.

75. How do you troubleshoot provider authentication errors in Terraform?

Troubleshooting provider authentication errors typically involves checking a few key areas:

Credentials: Ensure your environment variables (e.g., AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY), credential files, or provider-specific configuration blocks have the correct and valid credentials.
Permissions: Verify that the IAM user, role, or service principal has the necessary permissions to perform the requested actions (e.g., ec2:CreateInstance). The error message from the provider often indicates a permissions issue.
Region: Make sure the region configured in your provider block matches the region where you are trying to deploy resources.
Backend: If you’re using a remote backend, ensure that your credentials and permissions for the backend (e.g., S3 bucket) are also correct.

Increasing the log verbosity with TF_LOG=TRACE can also provide detailed information on the exact API calls and authentication attempts being made, which can help pinpoint the problem.

76. How do you perform blue-green or canary deployments with Terraform?

Terraform can be used as a part of a larger blue-green or canary deployment strategy. It’s not a single command, but rather a workflow.

Separate environments: You manage two separate, parallel environments (e.g., a “blue” environment and a “green” environment) using Terraform modules.
Update and test: You first deploy the new version of your infrastructure to the “green” environment using a terraform apply on that specific configuration.
Traffic routing: Once the new environment is tested and validated, you update a separate resource—a load balancer or DNS record—to switch traffic from the “blue” to the “green” environment. This step is also managed by Terraform.
Decommission: After a successful switch, the “blue” environment can be safely destroyed with a final terraform destroy.

This ensures that the infrastructure is managed as code throughout the entire process.

77. What is the difference between static and dynamic expressions in Terraform?

Static expressions are values that are known at the time Terraform’s configuration is being parsed. These are simple literals like strings, numbers, or boolean values.
Dynamic expressions are values that are not known until the apply step. They depend on the results of a resource creation. For example, the ID of a newly created EC2 instance or the IP address of a load balancer are dynamic expressions. Terraform’s planning phase can identify that these values are unknown and will show them as “known after apply.”

78. How do you handle cross-region deployments in Terraform?

You handle cross-region deployments by using provider aliases. By default, a provider block sets the default region for all resources. To deploy to a different region, you define a second provider block with the same provider name but with an alias and a different region. Then, you explicitly reference that alias in the resources you want to deploy to the second region.

Example:

provider "aws" {
  region = "us-east-1"
}
provider "aws" {
  alias  = "west"
  region = "us-west-2"
}
resource "aws_instance" "west_server" {
  provider = aws.west
  # ...
}

79. What are Terraform Cloud and Terraform Enterprise?

Terraform Cloud and Terraform Enterprise are HashiCorp’s commercial offerings for using Terraform in a collaborative, production environment. They are managed services that extend the open-source Terraform CLI.

Terraform Cloud: A cloud-hosted service that provides remote state management, team collaboration, policy enforcement, and a private module registry. It’s a great choice for teams that want a managed, hosted solution.
Terraform Enterprise: A self-hosted version of Terraform Cloud designed for large organizations with strict security or compliance requirements. It has all the features of Terraform Cloud plus additional enterprise-specific capabilities like audit logging, single sign-on (SSO), and air-gapped support.

80. What are Sentinel policies in Terraform Enterprise?

Sentinel policies are a policy-as-code framework used in Terraform Cloud and Terraform Enterprise to enforce governance and compliance rules on your infrastructure deployments. They are written in the Sentinel language and are run automatically as part of the Terraform workflow.

Sentinel policies can be used to:

Prevent specific actions: For example, a policy can block the creation of a public S3 bucket or a database instance that isn’t encrypted.
Enforce tagging: Policies can require that all resources have a “cost-center” tag.
Control resource size: A policy can limit the size of virtual machines that can be deployed to reduce costs.

A policy can have different enforcement levels, such as advisory (warns but doesn’t block), soft mandatory (can be overridden), and hard mandatory (must pass to proceed).

81. How do you migrate Terraform state from local to remote backend?

To migrate a Terraform state from a local to a remote backend, you first configure the remote backend in your .tf file and then run a specific command.

Configure the Backend: In your configuration file, add a backend block inside the terraform block. Specify the type and required arguments for your remote backend (e.g., S3, Azure, Google Cloud).
Run terraform init: Execute terraform init from your terminal. Terraform will detect the change in the backend configuration and prompt you to migrate the existing state.
Confirm migration: You will be asked to confirm the migration. Enter yes, and Terraform will copy the state from your local machine to the configured remote backend. After the migration, all subsequent operations will use the remote state.

82. What is a partial state file in Terraform?

A partial state file is a feature of remote backends that allows Terraform to only store a portion of the state file locally. Instead of downloading the entire, potentially large, state file, Terraform can use a “partial” local copy that is just enough to perform its operations. This is a common feature in cloud backends and helps to reduce network transfer and improve performance, especially with very large configurations. The full state is always managed and stored in the remote backend.

83. What happens if two people run terraform apply at the same time?

If two people run terraform apply at the same time, it can lead to state file corruption and unexpected infrastructure changes. This is why state locking is a crucial feature of remote backends. When one person runs an apply, the backend acquires a lock on the state file. The second person’s command will be blocked and will return an error, preventing them from making conflicting changes. Once the first operation is complete, the lock is released, and the second person can proceed.

84. How do you manage large numbers of resources in Terraform?

You manage a large number of resources in Terraform through a process of modularization. Instead of putting all your resources in a single, monolithic configuration, you break them down into smaller, reusable modules. Each module manages a specific component (e.g., a VPC, a database, a Kubernetes cluster). You then use a root module to call and connect these child modules, organizing the infrastructure into a clear, manageable hierarchy. This approach makes the code easier to read, maintain, and scale.

85. What is the difference between Terraform’s count parameter and looping in other IaC tools?

The count parameter in Terraform is a meta-argument that creates a specified number of nearly identical resources. It’s a simple, built-in way to create multiple instances of a single resource type. In contrast, looping in other IaC tools (like Ansible’s with_items or Chef’s for loops) is often more flexible and can be used to create resources with more varied properties, or to perform more complex tasks like iterating through a list of users and creating an account for each one. The for_each meta-argument in Terraform is more similar to general-purpose looping, as it allows for more varied and distinct resources to be created.

86. Can Terraform create resources in multiple accounts? How?

Yes, Terraform can create resources in multiple accounts. You achieve this by configuring a separate provider block for each account and using an alias. Each provider block will have its own set of credentials and configuration (e.g., region, access key). You then use the provider argument in each resource block to explicitly tell Terraform which provider, and therefore which account, to use for that resource.

87. How do you secure state files stored in remote backends?

Securing state files is critical because they contain sensitive data. The primary methods for securing them are:

Encryption at rest: Most remote backends, like Amazon S3 and Azure Blob Storage, offer built-in encryption that automatically encrypts the state file.
Access control: You should use fine-grained access policies (e.g., IAM policies in AWS) to restrict who can read, write, or delete the state file.
State locking: As mentioned earlier, state locking prevents simultaneous operations, which is a form of security against state corruption.
Secrets management: The best practice is to avoid putting secrets in your configuration or state file in the first place by using a secrets management service like Vault.

88. What is the role of the terraform output command?

The terraform output command is used to display the values of the output variables that have been defined in a Terraform configuration. Its primary roles are:

Sharing information: It provides an easy way to get important values, like the IP address of a server, a database connection string, or a cluster’s endpoint, after deployment.
Externalizing data: It allows one Terraform configuration to pass data to another, enabling you to chain configurations together.
Inspecting a state file: You can also use terraform output to inspect the state file for specific values, making it useful for debugging and automation.

89. How do you ensure Terraform code follows best practices automatically?

You can enforce best practices and code standards automatically in a CI/CD pipeline using several tools:

terraform fmt: This command ensures that all code is formatted consistently.
terraform validate: This command checks for syntax errors before a plan is even generated.
Static analysis tools: Third-party tools like Terrascan or Checkov analyze your code for security and compliance issues without deploying it. They can automatically check for things like public S3 buckets or unencrypted databases and fail the build if they are found.
Sentinel policies: For Terraform Cloud/Enterprise users, Sentinel policies provide a robust way to enforce governance rules on every apply operation.

90. What is drift remediation in Terraform?

Drift remediation is the process of bringing your infrastructure back into alignment with your Terraform configuration after it has been changed manually. When you run terraform plan, Terraform detects the “drift”—the difference between the state file and the real-world infrastructure. The plan then shows what changes are needed to correct the drift, and running terraform apply executes those changes to restore the infrastructure to the state defined in your code.

91. How do you recover from a corrupted state file?

Recovering from a corrupted state file can be a complex process. The primary method is to use the terraform state commands.

Backup first: Always make a backup of the corrupted state file before attempting any changes.
terraform state pull: This command can be used to pull the corrupted state file from a remote backend.
Manual editing: In simple cases, you can manually edit the state file to fix minor issues, but this is a very risky operation and is not recommended.
terraform state rm: You can use this command to remove the corrupted resource from the state file. After removal, you can re-import the resource correctly using terraform import.
Re-import everything: In the worst-case scenario, if the corruption is severe, you may need to delete the state file and re-import all resources from scratch.

92. What are custom providers in Terraform?

Custom providers are plugins that you can write to extend Terraform’s functionality beyond the official providers. They allow you to manage a custom API or a non-standard service that doesn’t have a pre-existing provider. Writing a custom provider requires using the Go programming language and the Terraform Plugin SDK. Once created, a custom provider can be used just like any other provider, allowing you to manage specialized resources with Terraform.

93. How does Terraform’s graph theory work for dependency management?

Terraform’s dependency management is built on graph theory. When you run terraform plan, Terraform analyzes all the resources and their relationships to build a directed acyclic graph (DAG). Each node in the graph represents a resource or module, and the edges represent dependencies. Terraform then executes the graph, starting with nodes that have no incoming edges (no dependencies). This ensures that resources are created in the correct order, with dependent resources being deployed only after their dependencies are fully provisioned.

94. What is the difference between Terraform OSS, Cloud, and Enterprise?

Terraform OSS (Open-Source): The free, command-line version of Terraform. It’s the core engine that allows you to provision infrastructure as code. It’s great for individual use and small teams but lacks built-in collaboration features like state locking and a shared workspace.
Terraform Cloud: A managed service from HashiCorp that provides a web-based UI, remote state management, team collaboration, a private module registry, and policy-as-code (Sentinel). It’s designed to streamline Terraform workflows for teams.
Terraform Enterprise: A self-hosted version of Terraform Cloud for large organizations. It offers all the features of Terraform Cloud plus additional security and governance capabilities like single sign-on (SSO), audit logging, and air-gapped support.

95. How do you handle provider aliasing in Terraform?

Provider aliasing is used to manage resources with the same provider but with different configurations (e.g., in different regions or accounts). You can create an alias by adding an alias argument to the provider block. You can then reference that alias in the provider argument of a resource block.

Example:

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

provider "aws" {
  alias  = "west"
  region = "us-west-2"
}

resource "aws_instance" "example_west" {
  provider = aws.west
  # ...
}

96. What is the difference between inline blocks and nested blocks in Terraform resources?

Inline blocks are a simpler way to define configuration for a nested object within a resource. The configuration is written directly within the resource block using a key-value format. They are typically used for simple lists or sets of attributes.
Nested blocks are defined using a dedicated block inside a resource, allowing for more complex, structured configurations. They are used when a nested object has multiple, related arguments.

Example:

# Nested block
resource "aws_security_group" "example" {
  ingress {
    from_port = 22
    to_port   = 22
    protocol  = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

97. How do you structure Terraform modules for reusability?

To structure modules for reusability, follow a standard file layout. A module directory should contain:

main.tf: Defines the resources.
variables.tf: Defines all input variables.
outputs.tf: Defines all output values.
README.md: Documents the module’s purpose, inputs, and outputs.

This clear separation ensures that the module is easy to understand, use, and maintain, allowing other teams to use it like a reusable component without needing to know the implementation details.

98. How do you integrate Terraform with configuration management tools?

Terraform is primarily for provisioning infrastructure, while configuration management tools like Ansible, Puppet, and Chef are for configuring the operating system and software on those resources. The integration works by using Terraform to create the infrastructure and then passing the necessary information (e.g., public IP addresses) to the configuration management tool. This can be done using outputs, local-exec provisioners, or a central inventory file. The best practice is to have Terraform run the provisioning and then trigger the configuration management tool as a separate, subsequent step in a CI/CD pipeline.

99. What are remote operations in Terraform Cloud?

Remote operations are a core feature of Terraform Cloud where all Terraform CLI commands, like plan and apply, are executed on a dedicated, managed server instead of on your local machine. The local CLI simply sends your configuration files to the Terraform Cloud platform. This provides a consistent and secure execution environment, centralizes logs and state management, and enables features like policy-as-code and team collaboration.

100. How do you upgrade Terraform version in an existing project safely?

To safely upgrade the Terraform version in an existing project, follow these steps:

Read the release notes: Check the official release notes for the new version for any breaking changes or required migration steps.
Update the version constraint: In your main.tf file, update the required_version argument to the new version.
Run terraform init: Execute terraform init. Terraform will download the new binary and initialize the project for the new version.
Run terraform plan: Perform a dry run with terraform plan to ensure that there are no unexpected changes to your infrastructure.

This approach ensures you can check for any issues before applying the new version.

101. How does Terraform interact with APIs of cloud providers?

Terraform interacts with the APIs of cloud providers through providers. Each provider is a plugin that understands the API of a specific service (like AWS, Azure, or Google Cloud). When you run terraform apply, Terraform uses the provider plugin to translate your declarative configuration into the appropriate API calls to create, modify, or destroy resources on the cloud platform. The provider handles authentication and manages the low-level interactions with the API for you.

102. What is the purpose of the terraform graph command?

The purpose of the terraform graph command is to generate a visual representation of the dependency graph for your configuration. It outputs a file in the DOT format that can be used with graphing software to visualize the order in which resources will be created. This is extremely useful for understanding complex configurations, identifying implicit dependencies, and debugging circular dependencies.

103. How do you manage breaking changes in Terraform provider upgrades?

You manage breaking changes in Terraform provider upgrades by:

Reviewing provider documentation: Always check the provider’s upgrade guides and release notes for any breaking changes before upgrading.
Version constraints: Use version constraints (e.g., version = "~> 4.0") to control the version of the provider that is used in your project.
Testing: Use a dedicated, non-production environment to test the upgrade.
terraform plan: Always run terraform plan to see what changes the upgrade will propose before you apply it.

This process ensures that you are aware of any potential issues and can address them before they affect your production environment.

104. What happens internally when you run terraform init?

When you run terraform init, Terraform performs several internal operations:

Backend configuration: It reads the backend configuration from your code and sets up the backend (e.g., configuring a remote S3 bucket).
Provider discovery: It finds all the providers required by your configuration.
Provider download: It downloads the necessary provider plugins into the .terraform directory.
Module download: It downloads any remote modules.
Lock file creation: It creates or updates the .terraform.lock.hcl file, which records the exact versions of the providers and modules being used.

105. How do you enforce tagging policies using Terraform?

You can enforce tagging policies using Terraform in several ways:

Manual configuration: You can manually include the required tags in every resource block.
Local variables: You can define a map of mandatory tags as a local variable and reference it in every resource.
default_tags: The AWS provider has a default_tags block that automatically applies a set of tags to all resources created by that provider.
Sentinel policies: For Terraform Cloud/Enterprise users, you can write a Sentinel policy that will automatically check for and enforce tagging on all resources before a plan can be applied.

106. What is the difference between a backend and a provider in Terraform?

A backend is where Terraform stores the state file, which tracks the real-world infrastructure. It’s an internal part of Terraform’s workflow. A provider is a plugin that acts as an interface to a specific cloud or service, allowing Terraform to manage resources on that platform. The backend is about the state of the project, while the provider is about the resources themselves.

107. How do you handle secrets stored in AWS SSM or Vault with Terraform?

You handle secrets stored in AWS SSM or HashiCorp Vault by using a data source. You can write a data block that connects to the secrets management service and fetches the secret’s value at runtime. This value can then be passed to a resource argument, ensuring that the secret is never written in plain text to your configuration files or the state file.

108. What is the role of terraform workspace show?

The terraform workspace show command displays the name of the current workspace you are in. It’s a simple utility command used to confirm which isolated state file you are currently working with, which is useful when managing multiple environments with a single configuration.

109. How do you split monolithic Terraform configurations into smaller units?

You split monolithic configurations into smaller units by modularizing your code. You create a module for each logical component of your infrastructure (e.g., a VPC module, a database module, and a web server module). You then create a root module for each environment (e.g., prod, dev) that calls these smaller, reusable modules. This provides a clean, maintainable, and scalable structure.

110. How do you resolve cyclic dependencies in Terraform?

Cyclic dependencies occur when two or more resources or modules depend on each other, creating a deadlock. Terraform cannot resolve these dependencies automatically. To fix them, you must restructure your code to break the cycle. This typically involves using one of the following methods:

Separate resources: Break the dependent resources into separate, independent resources.
Rethink the architecture: Re-evaluate the infrastructure architecture to remove the circular dependency.
Delayed creation: In some cases, you may need to rely on external tools or scripts to handle a portion of the configuration after the initial apply is complete.

111. What are the differences between managed and unmanaged resources in Terraform?

Managed resources are those that are defined in your Terraform configuration and tracked in your state file. Terraform has full control over them and will propose changes to create, update, or destroy them based on your code. Unmanaged resources exist in your cloud environment but are not tracked by your Terraform state file. They may have been created manually or by a different process. Terraform will ignore unmanaged resources unless you explicitly import them into your state file.

112. How do you manage Terraform code for multi-cloud projects?

Managing code for multi-cloud projects is handled by defining multiple provider blocks, one for each cloud provider. Each provider block specifies the credentials and configuration for that cloud. You can then define resources for any of those providers within the same Terraform configuration. Terraform will intelligently manage all resources from the different clouds, even if they have cross-cloud dependencies, all within a single state file.

113. Explain the concept of ephemeral environments with Terraform.

Ephemeral environments are temporary, short-lived infrastructure environments used for specific tasks like testing a new feature or running a pull request. With Terraform, you can automate the creation and destruction of these environments. When a new feature branch is created, a CI/CD pipeline can run a Terraform configuration to provision a complete, isolated environment. After the feature is tested and merged, the pipeline can run terraform destroy to tear down the environment, saving costs and resources.

114. How do you handle “plan file too large” errors in Terraform?

The “plan file too large” error occurs when the output of terraform plan exceeds the size limit of the environment where it’s being saved, such as a CI/CD tool’s log. To handle this, you can:

Use terraform plan -out=tfplan: This saves the plan to a binary file and avoids printing the entire plan to the console. You can then pass this file to the terraform apply command.
Filter the output: Use a command like grep to filter out specific parts of the plan output that you don’t need to see in the logs.
Split your configuration: For very large projects, consider breaking your monolithic configuration into smaller, modular units with separate state files.

115. What are the pros and cons of using terraform import?

Pros:

Migration: You can bring existing, manually created infrastructure under Terraform’s management.
State synchronization: You can use it to fix a state file if a resource was accidentally deleted.

Cons:

Time-consuming: You have to manually write the configuration for each resource before importing it.
One-way street: It’s a one-way operation; there’s no way to “export” a resource from Terraform’s state.
Not for daily use: It’s intended for one-time migrations and not as part of a regular workflow.

116. How do you migrate resources between modules without destroying them?

To migrate resources between modules without destroying and recreating them, you use the terraform state mv command.

Refactor the code: First, move the resource block from the old module’s configuration file to the new module’s file.
Move the state: Run terraform state mv "old_module.resource_name" "new_module.resource_name". This command updates the state file, telling Terraform that the resource has a new address in your configuration.
Run terraform plan: Execute a terraform plan to confirm that Terraform recognizes the move and proposes no changes to the infrastructure.

117. What is terraform state mv used for?

The terraform state mv command is used to move a resource’s address in the state file. It renames a tracked resource from a source address to a destination address. Its primary use cases are refactoring code (moving a resource to a new module) or renaming a resource in your configuration without destroying and recreating it.

118. How do you deal with provider authentication across multiple environments?

For multi-environment provider authentication, you should avoid hard-coding credentials in your configuration files. Instead, use variables or a configuration management system to pass credentials to Terraform. The best practices are:

Environment variables: Use environment variables (e.g., AWS_ACCESS_KEY_ID) to provide credentials for each environment.
IAM Roles/Service Principals: For CI/CD, use IAM roles (AWS) or service principals (Azure) that Terraform can assume to authenticate with the cloud provider without needing explicit credentials.
Local credentials file: Use a local credentials file for development, and ensure it’s not checked into version control.

119. How do you implement infrastructure drift alerts outside of Terraform?

To implement infrastructure drift alerts, you need an external tool to monitor your cloud environment and compare it to your desired state. Tools like AWS Config, Cloud Custodian, or Checkov can continuously scan your infrastructure and report any resources that do not match the expected configuration. When a drift is detected, these tools can send alerts to a notification system like Slack or email. This proactive approach helps you find and fix manual changes before they cause issues.

120. What happens if a resource creation partially fails during terraform apply?

If a resource creation partially fails, Terraform will mark the resource as “tainted” in the state file. This indicates that the resource is in an inconsistent or incomplete state. The next time you run terraform plan, Terraform will propose to destroy the tainted resource and recreate it from scratch. If the resource is unable to be destroyed (due to the incomplete creation), you may have to manually delete the resource and then run terraform apply to resolve the issue.

121. How do you handle dependency upgrades across Terraform modules?

You handle dependency upgrades across Terraform modules by updating the module’s source and version arguments. First, you update the module in its repository and tag a new version. Then, in the consuming root module, you change the version constraint to the new version. After updating the version, you run terraform init -upgrade to download the latest version of the module. Finally, you run terraform plan to review the changes and terraform apply to execute them. This process ensures a controlled and deliberate upgrade.

122. What is the difference between ignore_changes and lifecycle arguments?

ignore_changes is a lifecycle meta-argument that prevents Terraform from considering specific resource arguments when checking for updates. It’s used when an attribute of a resource might be changed outside of Terraform, and you want to prevent Terraform from attempting to change it back.
lifecycle is a broader meta-argument block that allows you to customize how Terraform manages the resource’s lifecycle, including actions like preventing destruction or telling Terraform to create a new resource before destroying the old one. ignore_changes is a specific option within the lifecycle block.

123. How do you prevent accidental deletions in Terraform?

You prevent accidental deletions in Terraform by using the prevent_destroy lifecycle meta-argument. When you set prevent_destroy = true on a resource, Terraform will block any terraform apply or terraform destroy command that would lead to the destruction of that resource. This is a critical safety mechanism for protecting production resources like databases or core network components.

124. What is the role of terraform refresh in drift detection?

The terraform refresh command updates the Terraform state file with the latest attribute values from the real-world infrastructure. Its primary role is to detect drift—any changes made to resources outside of Terraform. However, it’s generally not used on its own. It runs automatically as the first step of the terraform plan and terraform apply commands, which is the standard way to detect and propose fixes for drift.

125. How do you manage concurrent runs in Terraform Cloud/Enterprise?

In Terraform Cloud and Terraform Enterprise, concurrent runs are managed automatically using a run queue and state locking. When a new run is initiated, it’s placed in a queue. Terraform Cloud ensures that only one run can modify a workspace’s state file at a time, preventing conflicts and state corruption. This eliminates the need for manual locking and is a key benefit of using a managed platform.

126. What is the significance of “state reconciliation” in Terraform?

State reconciliation is the process where Terraform brings the real-world infrastructure into alignment with the state defined in your configuration. It’s the core task of the terraform apply command. Terraform compares the desired state from your code with the actual state of your infrastructure and determines a set of actions (create, update, or delete) to reconcile the two, ensuring your infrastructure is always in the intended state.

127. How do you scale Terraform execution for very large infrastructures?

You scale Terraform execution for very large infrastructures by splitting your configuration into smaller, independent units. Instead of a single, monolithic configuration, you can use:

Modules: Break down your infrastructure into logical, reusable modules with their own state files.
Workspaces: Use workspaces to manage different environments from the same code.
Separate repositories: Divide your infrastructure code into separate repositories, with a different team or pipeline managing each one. This ensures that a failure or change in one part of the infrastructure does not affect the rest.

128. How do you audit Terraform changes in production?

You audit Terraform changes in production by logging and storing the results of terraform plan and terraform apply runs. The plan output provides a detailed record of what changes were proposed, and the apply output confirms what was actually executed. In Terraform Cloud and Terraform Enterprise, these logs are automatically stored and can be reviewed in the UI. For open-source Terraform, you can use a CI/CD pipeline to save the plan and apply output to a centralized log management system.

129. What is the difference between .tf, .tfvars, and .tfstate files?

A .tf file is a Terraform configuration file that contains the code for your infrastructure resources, modules, and variables.
A .tfvars file is a variable definition file that provides values for the variables in your .tf files. It’s used to customize configurations for different environments.
A .tfstate file is the state file that stores the record of the real-world infrastructure that Terraform is managing. It’s the single source of truth for the managed resources.

130. How do you integrate Terraform with GitOps workflows?

You integrate Terraform with GitOps workflows by making your Git repository the single source of truth. All infrastructure changes are proposed as pull requests (PRs) to the repository. A CI/CD pipeline is configured to automatically run terraform plan on every PR, and the plan output is added to the PR for review. Once the PR is merged, the pipeline automatically runs terraform apply, executing the changes to the infrastructure. This creates a fully automated, auditable, and version-controlled workflow.

131. How does Terraform handle cross-dependencies between modules in different repositories?

Terraform handles cross-dependencies between modules in different repositories by using outputs from one configuration as inputs to another. The first repository manages a root module that provisions a set of resources and exports key values (like a VPC ID or a subnet name) as outputs. The second repository then references this output data by using a data source or by fetching the state file from the first repository’s remote backend. This approach decouples the two configurations while allowing them to share information, creating a clear dependency chain without making them monolithic.

132. What is the terraform login command used for?

The terraform login command is used to authenticate with Terraform Cloud or Terraform Enterprise. When you run it, you’re prompted to enter an API token, which Terraform then stores locally. This token allows the Terraform CLI to interact with your remote workspaces, manage state, and access private modules in the registry, eliminating the need to manually configure tokens for every command.

133. How do you pin a provider version in Terraform, and why?

You pin a provider version in Terraform by specifying an exact version in the required_providers block of your configuration. For example, version = "4.2.0". You do this to ensure that all team members and CI/CD pipelines use the exact same provider version. This prevents unexpected changes in behavior or syntax that might occur between different provider releases, ensuring consistency and reproducible deployments.

4. What is the difference between public and private modules in the Terraform Registry?

The main difference between public and private modules in the Terraform Registry is their accessibility. Public modules are freely available to anyone and are hosted on the public Terraform Registry. They are community-contributed and often used for common cloud patterns. Private modules are hosted within a private registry, typically part of a Terraform Cloud or Terraform Enterprise account. They are only accessible to members of your organization and are used for sharing internal, proprietary, or sensitive infrastructure patterns.

135. How do you enforce compliance requirements in Terraform projects?

You enforce compliance requirements in Terraform projects using a policy-as-code framework. For users of Terraform Cloud or Terraform Enterprise, this is done with Sentinel. You write policies that check for and block non-compliant resources (e.g., a public S3 bucket or an unencrypted database). For open-source users, tools like Open Policy Agent (OPA), Checkov, or Terrascan can be integrated into a CI/CD pipeline to scan Terraform plans and fail the build if compliance violations are found.

136. What is the best way to roll back Terraform infrastructure after a failed deployment?

The best way to roll back Terraform infrastructure after a failed deployment is to revert your code to a previous, stable version using your version control system (e.g., git checkout <commit_hash>). You then run terraform plan to see the proposed changes, followed by terraform apply to execute the rollback. This method ensures that the infrastructure state matches a previously working code version.

137. How do you use terraform output -json in automation?

You use terraform output -json in automation to retrieve output values in a machine-readable format. Instead of a human-readable list, the command returns a JSON object containing all the outputs and their values. This is ideal for scripting, as it allows a script to easily parse and use the output data, for instance, to pass a newly created server’s IP address to a configuration management tool like Ansible.

138. What is the use case for terraform state rm?

The terraform state rm command is used to remove a resource from the Terraform state file without destroying the actual physical resource. The primary use case is to deliberately stop managing a resource with Terraform. This is often necessary when a resource is manually deleted or a configuration is refactored, and you want to prevent Terraform from attempting to recreate it.

139. How do you plan infrastructure updates without affecting production?

You plan infrastructure updates without affecting production by using a CI/CD pipeline. The pipeline automatically runs terraform plan on every code change, generating a plan file that shows exactly what changes will be made to the infrastructure. This plan is reviewed by a team member before it can be applied. In addition, you can use separate environments (e.g., dev, staging) to test changes before they are promoted to production.

140. How do you secure Terraform execution in CI/CD pipelines?

You secure Terraform execution in CI/CD pipelines by:

Separating credentials: Use a secret management system or environment variables to inject credentials at runtime, avoiding hard-coding them in the codebase.
Least privilege: Configure the CI/CD user or role with the minimum necessary permissions to deploy the infrastructure.
Mandating plan review: Require a human review and approval of the plan output before the apply step can be executed.
State locking: Use a remote backend with state locking to prevent concurrent runs from corrupting the state file.

141. How do you handle zero-downtime deployments with Terraform?

You handle zero-downtime deployments with Terraform by using a blue-green or canary deployment strategy. Terraform manages two separate, identical environments: a “blue” environment (the current version) and a “green” environment (the new version). You deploy the new infrastructure to the “green” environment using a separate Terraform configuration. Once the new environment is validated, you use Terraform to update a load balancer or DNS record to switch all traffic from “blue” to “green”. This switch happens instantly, with no downtime. After a successful switch, the “blue” environment can be destroyed.

142. What are transient resources in Terraform, and how do you handle them?

Transient resources are temporary resources created during a Terraform apply to facilitate a change, but they are not part of the final state. They often appear and disappear during an update. For example, a resource might be created to help migrate data before the original is destroyed. You handle them by using a local-exec provisioner or a data source to create or reference the temporary resource. However, it’s generally an anti-pattern. A better way to handle these types of tasks is to use a dedicated migration or orchestration tool outside of Terraform.

143. How do you use depends_on with modules?

You can use the depends_on meta-argument with modules to explicitly define a dependency. This is useful when one module’s resources depend on a resource created by another module, and Terraform cannot infer the dependency automatically. For example, if a module deploys a database and another deploys a web service that needs to connect to it, you can add depends_on to the web service module to ensure the database is fully ready before the web service attempts to start.

144. What is the difference between .tf.json and .tf files in Terraform?

The difference is in their format. A .tf file uses the HashiCorp Configuration Language (HCL), which is designed to be human-readable and easy to write. A .tf.json file is the JSON equivalent of an HCL file. You can use either format to write your configuration, and Terraform will interpret both. While .tf files are the standard for manual coding, .tf.json files are more suitable for configurations that are generated by a script or another program.

145. How do you optimize Terraform runs to reduce API rate limits?

You optimize Terraform runs to reduce API rate limits by:

Caching: Use a local or remote cache for providers and modules to reduce network requests.
Batching: Some providers can batch requests, which can be configured in the provider block.
Parallelism: Use the -parallelism flag to control the number of concurrent operations, which can help manage API requests.
State management: Use a remote backend and ensure your state file is up-to-date to minimize the need for a full refresh on every run.

146. What happens if you lose access to your remote backend?

If you lose access to your remote backend, you will not be able to perform any Terraform operations that require a state file, such as plan or apply. This is because Terraform cannot access the source of truth for your infrastructure. In this situation, you would need to either restore access to the backend or use terraform state pull to get a local copy of the state file and terraform init to configure a new backend.

147. How do you handle Terraform drift when someone changes resources outside Terraform?

You handle Terraform drift by running a terraform plan. This command automatically performs a refresh, which detects any changes made to resources outside of Terraform. The plan output will show the drift and propose the necessary changes to bring the infrastructure back in line with your configuration. You can then run terraform apply to remediate the drift. For proactive management, you can set up a scheduled job in a CI/CD pipeline to periodically run terraform plan and alert you when drift is detected.

148. How do you manage Terraform providers that are deprecated?

You manage deprecated Terraform providers by upgrading to the latest version as soon as possible. The provider’s documentation usually provides a clear migration guide. The process involves updating the provider version in your configuration and running terraform init -upgrade and terraform plan. For resources with breaking changes, you may need to use terraform state mv to rename resources in your state file.

149. How do you secure Terraform state files at rest and in transit?

You secure Terraform state files by using a remote backend with encryption.

At rest: Most remote backends, like Amazon S3 or Azure Blob Storage, offer built-in encryption at rest. This means the state file is encrypted on the storage disk.
In transit: When the state file is being transferred between the remote backend and your machine (e.g., during plan or apply), it’s protected by the backend’s secure communication protocols (e.g., HTTPS). This ensures the data is encrypted during transfer and safe from interception.

150. What are common anti-patterns in Terraform usage?

Common anti-patterns in Terraform usage include:

Using local state: This is not suitable for teams and leads to state corruption.
Hard-coding values: Hard-coding secrets or configuration values makes your code inflexible and insecure.
Monolithic configurations: Putting all resources into a single file makes the project difficult to manage and scale.
Using provisioners: Relying on provisioners for configuration management instead of dedicated tools like Ansible or Cloud-init is an anti-pattern.
Not using terraform plan: Applying changes without reviewing the plan can lead to unexpected and destructive results.

151. What is the purpose of terraform provider command?

The purpose of the terraform providers command is to inspect and manage the providers used in your Terraform configuration. It gives you a clear overview of which providers are required by your root module and any child modules, their dependencies, and their versions. This command is useful for troubleshooting version mismatches and for understanding the full set of provider plugins needed to run your configuration.

152. How does Terraform differentiate between managed and unmanaged infrastructure resources?

Terraform differentiates between managed and unmanaged resources by using its state file.

Managed resources are those that are defined in your Terraform configuration and whose details are tracked in the state file. When you run terraform plan, Terraform compares your configuration with the state file to see if any changes are needed to the managed resources.
Unmanaged resources exist in your cloud or on-premises environment but are not recorded in the state file. Terraform completely ignores these resources during a plan or apply because it doesn’t know they exist. This is why if you manually delete a resource, Terraform will propose to recreate it, as the resource is still in the state file, but not in the real world. You can bring an unmanaged resource under Terraform’s control by using the terraform import command.

153. What are the differences between “provisioners” and “post-deployment scripts” in Terraform?

Provisioners are a built-in feature of Terraform that runs scripts or commands on a local or remote machine as part of a resource’s lifecycle (e.g., during creation or destruction). HashiCorp recommends using them sparingly as they can make your configuration less declarative and harder to maintain. They are considered a last resort for imperative actions that cannot be done with providers.

Post-deployment scripts, on the other hand, are external to Terraform and are typically run as a separate step in a CI/CD pipeline after the terraform apply command has successfully completed. This approach is the recommended best practice, as it keeps Terraform’s core job (provisioning infrastructure) separate from the task of configuring that infrastructure (like installing software or running commands). This separation of concerns makes your workflow more robust and easier to debug.

154. When would you use terraform force-unlock?

You would use the terraform force-unlock command to manually remove a state lock. Terraform uses state locking to prevent concurrent operations from corrupting the state file. However, if a terraform apply operation is interrupted or crashes unexpectedly, the lock can be orphaned, preventing any further operations. In this situation, the force-unlock command is the last resort to release the lock and regain access to the state file. You should use it with extreme caution and only after confirming that no other operations are running.

155. How do you manage state files for ephemeral environments like feature branches?

The best way to manage state files for ephemeral environments like feature branches is by using Terraform workspaces with a remote backend.

Workspaces: You create a new workspace for each feature branch (e.g., terraform workspace new feature-xyz).
Isolated State: Each workspace has its own isolated state file in the remote backend. This means that a terraform apply on the feature-xyz workspace will not affect the state file of your main or production workspaces.
Destruction: When the feature is complete and the branch is merged, you can use terraform destroy to tear down the environment and terraform workspace delete to remove the isolated state file. This process is fully automated and keeps your backend clean.

156. How do you integrate Terraform with Vault for secret injection?

You integrate Terraform with Vault for secret injection using the Vault provider and data sources. You configure the Vault provider to authenticate with your Vault server. Then, you use a vault_generic_secret or a similar data source to read a secret from a specific path in Vault. This data source fetches the secret at runtime, and its value can then be passed to a resource argument. This ensures that sensitive data is never hard-coded in your configuration files and is not stored in your state file.

157. What happens if you upgrade Terraform CLI but keep the same provider versions?

If you upgrade the Terraform CLI but keep the same provider versions, everything should work as expected. New minor and patch versions of the Terraform CLI are generally backward compatible. The CLI will simply continue to use the pinned provider versions specified in your configuration. However, if the new CLI version requires a new state file format, it will automatically update the state file when you next run a command that modifies it.

158. How do you configure retries for Terraform operations when APIs fail intermittently?

Terraform providers, not the core CLI, are responsible for handling API retries. Many providers have built-in retry logic that handles common intermittent failures. Some providers, like the Azure or AWS providers, also allow you to configure timeouts and custom retry behavior at the provider level or on a per-resource basis. You can set the number of retries, the wait interval, and even match specific error codes. This is typically done within the provider block.

159. How do you perform cross-account IAM role assumption with Terraform?

You perform cross-account IAM role assumption with Terraform by using provider aliases.

Define Providers: In your configuration, you define two AWS provider blocks. One is for the source account (the one you are running Terraform from), and the second is for the destination account. The second provider block is given an alias and is configured to assume_role with the ARN of a role in the destination account.
Assume Role: The role in the destination account must have a trust policy that allows the source account to assume it.
Reference Aliases: You then reference the aliased provider in the resource blocks that need to be deployed to the destination account. This tells Terraform to use the credentials of the assumed role for those specific resources.

160. How do you reduce plan/apply execution time in very large infrastructures?

To reduce plan/apply execution time in very large infrastructures, you should modularize your code and split your state files.

Modularization: Break down your monolithic configuration into smaller, independent modules, each with its own state file. This limits the scope of each plan and apply to a smaller, more manageable set of resources.
Targeting: Use the -target flag to limit operations to a single resource or module, though this is considered an anti-pattern for regular use.
Concurrency: Increase the level of parallelism with the -parallelism flag, allowing Terraform to create or update more resources at once, though you should be mindful of API rate limits.

161. How do you prevent terraform destroy from wiping out critical resources?

You prevent terraform destroy from wiping out critical resources by using the prevent_destroy lifecycle meta-argument.¹ When you set prevent_destroy = true on a resource, Terraform will block any destroy command, or an apply that would result in its destruction, and return an error. This is the primary safety mechanism for protecting critical infrastructure like production databases, root network components, or shared resources that should not be deleted.

162. What is the purpose of terraform show -json?

The purpose of terraform show -json is to provide a machine-readable output of the state file or a plan file.² Instead of the default human-readable format, this command returns the data as a single JSON object. This is essential for automation and scripting, as it allows other programs or scripts to easily parse the state of the infrastructure or the details of a planned change without needing to rely on brittle string parsing.

163. How do you visualize complex dependency graphs in Terraform?

You visualize complex dependency graphs using the terraform graph command. It generates a file in the DOT language that describes the dependencies between resources in your configuration. You then use an external graphing tool like Graphviz to convert this DOT file into a visual image, such as a PNG or SVG. This visual representation helps you understand the order of operations and identify potential issues like circular dependencies.

164. How do you handle deprecated resource types in Terraform?

You handle deprecated resource types by updating your configuration to use the recommended, newer resource type. The provider’s documentation typically provides a migration guide with instructions on how to make the change. The process usually involves:

Adding the new resource type to your code.
Using a terraform state mv command to update the state file, migrating the old resource to the new one.³
Removing the old, deprecated resource from your code.

This method allows you to migrate to the new resource without destroying and recreating the infrastructure.

165. What are sentinel policies and how do you enforce them?

Sentinel policies are a policy-as-code framework used in Terraform Cloud and Terraform Enterprise to enforce governance and compliance rules. They are written in the Sentinel language and are executed during a Terraform run. You enforce them by uploading the policies to your Terraform Cloud or Enterprise account and associating them with your workspaces.⁴ A run will not be allowed to proceed if it violates a mandatory policy, ensuring that your infrastructure adheres to your organization’s rules.

166. How do you integrate Terraform with ServiceNow or ticketing systems?

You integrate Terraform with ServiceNow or other ticketing systems by using webhooks or a CI/CD pipeline.⁵ The CI/CD pipeline can be configured to automatically create a new ticket in the ticketing system at the start of a terraform apply run. The ticket can contain a link to the plan output, and the run can be paused until an approval is received. Once the change is approved in the ticketing system, the pipeline can proceed with the apply. This provides an auditable trail for all infrastructure changes.

167. What happens if you delete a remote backend bucket by mistake?

If you delete a remote backend bucket by mistake, you lose your state file, which is the single source of truth for your managed infrastructure. Terraform will no longer know which resources it is managing. When you run a terraform plan or apply, it will see all the infrastructure as new and propose to create it again, which can lead to duplicate resources and difficult-to-manage drift. The only way to recover is to either restore the bucket from a backup or manually re-import all your infrastructure into a new state file.

168. How do you use terraform state pull and terraform state push safely?

You use terraform state pull and terraform state push with extreme caution, as they can bypass state locking and lead to corruption.

terraform state pull downloads the current state file from the remote backend. It’s used primarily for debugging or inspecting the state file locally.
terraform state push overwrites the remote state file with a local one. It should only be used as a last resort for recovery, for example, to upload a manually fixed state file after a crash.

These commands should never be part of a regular workflow.

169. What is the use case for terraform state replace-provider?

The terraform state replace-provider command is used to update the provider address for resources already tracked in your state file. This is useful when a provider is deprecated or its name changes (e.g., from hashicorp/aws to a new organization name). You use this command to tell Terraform that a resource that was managed by the old provider is now managed by the new one, without having to destroy and recreate the resource.

170. How do you build custom modules with version constraints?

You build custom modules with version constraints by defining them in a Git repository and using tags to mark different versions. In your module’s repository, you use git tag to create tags (e.g., v1.0.0, v1.0.1). When a user references your module in their configuration, they can specify a specific version by adding a ref parameter to the source URL. For example: source = "git::https://example.com/mymodule.git?ref=v1.0.0". This ensures that other users will not be affected by changes you make to newer versions of your module.

171. How do you troubleshoot Terraform hanging during terraform apply?

If Terraform is hanging during terraform apply, it’s typically due to one of a few common issues:

State Locking: The most frequent cause is an existing lock on the state file. This happens when a previous run was interrupted and the lock was not released. Check for an orphaned lock and use terraform force-unlock to release it.
Provider API issues: The provider’s API may be slow, or a resource is stuck in a pending state. You can increase the log verbosity with TF_LOG=TRACE to see what API call Terraform is waiting for and investigate the issue on the cloud provider’s side.
Complex dependencies: A resource may be waiting on a non-obvious dependency. You can use terraform graph to visualize the dependencies and identify any long-running or stalled resources.

172. What happens if you lose .terraform.lock.hcl?

If you lose the .terraform.lock.hcl file, Terraform will not have a record of the exact provider and module versions that were used in the last successful run. When you next run terraform init, Terraform will download the latest compatible versions based on the version constraints in your configuration. This can lead to unexpected behavior or resource changes if a new provider version has introduced breaking changes. It’s crucial to always check this file into your version control system to ensure consistent and reproducible builds.

173. What are resource addressing concepts in Terraform?

Resource addressing refers to the way you reference resources and their attributes in Terraform. The address is the unique path to a resource. It includes the resource type, its name, and an optional index or key for multiple resources. For example, aws_instance.web_server refers to a specific resource, while aws_instance.web_server[0] or aws_instance.server["db"] refers to a specific instance in a list or map of resources. This addressing is fundamental to referencing resources in outputs, data sources, or other resource blocks.

174. How do you enforce code reviews for Terraform changes in a team?

You enforce code reviews for Terraform changes by integrating a CI/CD pipeline with your version control system (like Git). All changes must be submitted as a pull request (PR). The pipeline is configured to automatically run terraform plan on every PR and post the plan output as a comment. A team member can then review the proposed changes before approving the PR for a merge. The pipeline is then triggered to automatically run terraform apply only after the PR is merged. This ensures all changes are reviewed before they are deployed.

175. What is the role of terraform login and API tokens?

The role of terraform login is to authenticate the Terraform CLI with a remote service like Terraform Cloud or a private registry. The command securely stores an API token on your local machine. This token allows the CLI to perform actions like managing remote state, accessing a private module registry, and running operations on a remote server without needing to re-authenticate for every command. This provides a secure and seamless way to integrate with remote services.

176. How do you manage cost estimation in Terraform before deployment?

You manage cost estimation in Terraform by using external tools that integrate with your CI/CD pipeline. Tools like Infracost or Terragrunt can parse the output of a terraform plan and provide a detailed cost breakdown of the proposed changes. This allows you to get a clear picture of the cost implications of a change before it is deployed to production, helping to prevent unexpected billing.

177. What is the difference between terraform console and terraform output?

terraform console is an interactive command that allows you to evaluate expressions, test functions, and reference local values in real-time. It’s a powerful debugging tool for testing logic or variable values.
terraform output is a command that displays the values of the output variables from a deployed configuration. It’s used to retrieve and share important information, like a public IP address or a DNS name, after an apply is complete. The console is for testing expressions, while the output command is for retrieving finalized values.

178. How do you manage feature flags in Terraform infrastructure?

You manage feature flags in Terraform by using conditional expressions or by using a dedicated feature flag service. With conditional expressions, you can set a variable (e.g., var.enable_feature_x) to true or false and use that variable to conditionally create a resource or a module. For example: count = var.enable_feature_x ? 1 : 0. For more complex scenarios, you can use a data source to read a flag from a feature flag service, which is a more scalable and dynamic approach.

179. How do you handle resource renaming without forcing recreation?

To handle resource renaming without forcing recreation, you use the terraform state mv command.

Change the name: First, update the resource name in your Terraform configuration file.
Update the state file: Run the terraform state mv "old_name" "new_name" command. This command tells Terraform to update the address of the resource in the state file.
Verify: Run terraform plan to confirm that Terraform recognizes the move and doesn’t propose to destroy and recreate the resource.

This process ensures that your state file is synchronized with your code without affecting the actual infrastructure.

180. What is the difference between .terraformignore and .gitignore?

.gitignore is used by Git to specify files and directories that should be ignored from version control. You would use it to prevent Git from tracking things like the .terraform directory or .tfvars files with sensitive data.
.terraformignore is used by Terraform to specify files that should be ignored by Terraform itself when processing module content. It’s useful for ignoring large binary files or documentation that is not relevant to the module’s core functionality.

Both files serve a similar purpose of ignoring files, but .gitignore is for source control, while .terraformignore is for Terraform’s module processing.

181. Migrate from Terraform OSS to Terraform Cloud/Enterprise

To migrate from Terraform OSS to Terraform Cloud/Enterprise, you first need to configure a remote backend. The process involves a few steps.

Set up the Workspace: Create a new workspace in your Terraform Cloud or Enterprise account. This will be the new home for your state file.
Update Configuration: In your local .tf files, update the backend configuration from local to cloud or remote. You’ll need to specify your organization and the name of the new workspace.
Run terraform init: Execute the terraform init command. Terraform will detect the change in the backend and prompt you to migrate your existing local state file to the remote workspace. Confirm the migration.

Once this is complete, all future plan and apply operations will use the remote backend, providing state locking and a centralized history of your infrastructure.

182. Avoid Storing Credentials in .tfvars Files

To avoid storing credentials inside .tfvars files, you can use several methods:

Environment Variables: This is the most common approach. You set provider-specific environment variables in your shell or CI/CD pipeline (e.g., AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY). Terraform will automatically pick these up during its run.
Credentials Files: You can use provider-specific credentials files (e.g., ~/.aws/credentials). Terraform will look for these files by default.
Secrets Management Systems: This is the best practice for production environments. You can use a secrets management tool like Vault or AWS Secrets Manager to store your credentials. Terraform can then use a data block to fetch the credentials at runtime, ensuring they are never written to the configuration or state file.

183. What Happens if a Terraform Provider is No Longer Maintained?

If a Terraform provider is no longer maintained, you can continue to use the last available version of that provider by pinning it in your configuration. However, you will no longer receive security patches, bug fixes, or updates for new features from the cloud provider. Over time, the provider may stop working as the cloud provider’s API changes. In this situation, your best option is to look for a community-maintained fork or to contribute to a new provider.

184. Create Reusable Patterns for Networking

You can create reusable patterns for networking (VPC, subnets) with Terraform by using modules. A module is a reusable container for Terraform resources that can be called from different configurations.

Create a Module: Define a module that creates a VPC, a public subnet, and a private subnet. The module should have inputs for things like the VPC CIDR block and the number of subnets.
Define Outputs: The module should expose key values like the VPC ID and subnet IDs as outputs.
Call the Module: You can then call this module from any root configuration, specifying the desired inputs. This allows you to create consistent networking in different projects without repeating code.

185. Manage Infrastructure Rollbacks After a Failed Apply

Terraform does not have a built-in rollback command. The standard way to manage infrastructure rollbacks after a failed apply in production is to use a version control system. You revert the code to a previous, known-good commit. Then, you run terraform plan to see the changes required to revert the infrastructure, followed by a terraform apply to execute the rollback.

186. What is the terraform state show command used for?

The terraform state show command is used to display the details of a single resource in the state file. When you provide it with a resource address (e.g., aws_instance.web), it will show all the attributes of that resource as it exists in the state file. This is useful for inspecting the state of a specific resource for debugging purposes without having to view the entire state file.

187. How do you perform selective terraform destroy?

You perform a selective terraform destroy by using the -target flag. The -target flag tells Terraform to only destroy a specific resource. For example, terraform destroy -target=aws_instance.web. While this can be useful for debugging or cleanup, it’s generally considered an anti-pattern for production because it can lead to state inconsistencies and orphaned resources.

188. Monitor and Alert on Terraform State File Changes

You can monitor and alert on Terraform state file changes by using the features of your remote backend. Most remote backends, like Amazon S3 or Azure Blob Storage, have logging and event notification features. You can configure the backend to log all changes to the state file and send a notification to an event system like AWS CloudWatch Events or Azure Event Grid. These events can then trigger a serverless function that sends an alert to your team’s communication channels.

189. Limitations of Terraform with Mutable Resources

Terraform’s primary limitation when dealing with mutable resources is its focus on a declarative, desired state. When a resource is changed manually outside of Terraform, Terraform will often attempt to change it back to the state defined in your code. This can lead to unexpected behavior and a constant cycle of proposed changes. While you can use ignore_changes to tell Terraform to ignore specific attributes, it is an imperfect solution for managing highly dynamic, mutable resources.

190. Orchestrate Terraform with Jenkins/GitHub Actions Pipelines

You orchestrate Terraform with Jenkins/GitHub Actions pipelines by creating a multi-stage CI/CD pipeline.

Plan Stage: A build is triggered on a pull request, and the pipeline runs terraform init, terraform validate, and terraform plan -out=tfplan. The plan output is then posted as a comment for review.
Apply Stage: After a pull request is merged, the pipeline runs the apply stage. This stage is gated by a manual approval step. Once approved, the pipeline runs terraform apply "tfplan", which executes the changes.
Destroy Stage: A destroy stage can also be added to a separate workflow that runs terraform destroy to tear down the environment.

191. What is the difference between terraform taint and -replace flag?

The terraform taint command and the -replace flag are both used to force the recreation of a resource, but they work differently.¹ terraform taint was an older command that marked a resource as tainted in the state file. When you ran terraform plan, Terraform would see the tainted resource and propose to destroy and recreate it. It was a two-step process.

In contrast, the -replace flag, used with the terraform apply command, provides a more direct and modern way to achieve the same result. When you run terraform apply -replace=resource_address, Terraform directly includes the destruction and recreation of that specific resource in the execution plan. It is a single, explicit action that bypasses the need to first “taint” a resource in the state file. Because -replace is a more targeted and safer approach, the terraform taint command has been deprecated.

192. How do you secure Terraform variables in Git-based workflows?

You secure Terraform variables in Git-based workflows by keeping sensitive data out of your Git repository. Never commit .tfvars files that contain sensitive information, such as passwords, API keys, or access tokens.² Instead, use a secrets management system like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. You can then use a data block in your Terraform configuration to dynamically fetch the sensitive values at runtime. For non-sensitive, environment-specific variables, you can use .tfvars files that are loaded via the command line or an environment variable.³

193. How do you manage multiple Terraform versions across projects?

You manage multiple Terraform versions across projects by using a version manager. Tools like tfenv or asdf allow you to install and switch between different versions of the Terraform CLI on your local machine. You can then specify the required Terraform version for each project in a file (e.g., .terraform-version). When you enter a project directory, the version manager will automatically switch to the correct Terraform version, ensuring that each project uses the specific version it was designed for.

194. What are the best practices for naming conventions in Terraform projects?

The best practices for naming conventions in Terraform projects are to be consistent, clear, and descriptive. You should use a simple, predictable structure for resource names that includes the resource type, its purpose, and the environment.

Variables: Use a consistent prefix like var_ for all variables.
Outputs: Use an out_ or output_ prefix.
Resources: Use a naming pattern like [resource_type]_[purpose]_[environment]. For example, aws_instance_web_server_prod. This makes it easier to understand what each resource is for and to search for specific resources in your configuration.

195. How do you integrate Terraform with Kubernetes (using Helm provider)?

You integrate Terraform with Kubernetes using the Kubernetes provider and the Helm provider.

Kubernetes Provider: Terraform uses the Kubernetes provider to provision core Kubernetes resources like namespaces, service accounts, and RBAC roles.
Helm Provider: The Helm provider is then used to deploy Helm charts, which are packages of pre-configured Kubernetes resources. This allows you to provision your infrastructure with Terraform and then use Helm to deploy applications and services on that infrastructure, all within a single workflow.

196. What is the role of terraform providers mirror?

The terraform providers mirror command is used to create a local, self-hosted mirror of Terraform providers.⁵ This is particularly useful in environments with strict security policies or limited internet access, as it allows teams to download provider plugins from a local source instead of the public registry. This ensures that a team can continue to operate and maintain their infrastructure even if the public registry is unavailable or restricted.

197. How do you upgrade state schema after upgrading a provider?

You upgrade a state schema after upgrading a provider by running terraform apply. When a provider is upgraded, it may introduce a new schema format for its resources. During the plan phase, Terraform will detect this change and show a note that it will upgrade the schema. When you run apply, Terraform will apply the new schema format to your state file, but it will not change the actual infrastructure. This process ensures that your state file remains compatible with the new provider version.

198. How do you ensure least-privilege IAM for Terraform execution?

You ensure least-privilege IAM for Terraform execution by creating a dedicated IAM role or service principal for your CI/CD pipeline or your local user. This role or principal should be given the minimum set of permissions required to provision your infrastructure. For example, if you are creating EC2 instances, the role should only have permissions to create EC2 instances and their related resources. By using a dedicated role, you can also easily audit the actions that are performed by your Terraform deployments.

199. How do you avoid Terraform “spaghetti modules” in large organizations?

You avoid “spaghetti modules” in large organizations by implementing a clear modularization strategy and a standardized module structure. Instead of creating a single, overly complex module, you should create multiple smaller, focused modules that each manage a single, logical component of the infrastructure. For example, you would have a vpc module, a database module, and a web-server module. These modules can then be composed in a root module to build the final infrastructure, ensuring a clean, scalable, and maintainable project structure.

200. What are the emerging features in Terraform (like CDKTF, OPA integration)?

Some of the emerging features in Terraform include:

CDKTF (Cloud Development Kit for Terraform): This tool allows you to define your Terraform infrastructure using a general-purpose programming language like Python, TypeScript, or Java. It is designed for developers who are more comfortable with object-oriented programming than HCL.
OPA (Open Policy Agent) Integration: OPA can be used as a policy-as-code tool to enforce security and compliance rules on Terraform plans. It can be integrated into a CI/CD pipeline to check for things like public S3 buckets or unencrypted databases before they are deployed.
Improved for_each and for loops: Terraform is continuously improving its looping capabilities to make configurations more dynamic and concise.
State backend enhancements: The state backend continues to evolve, with new features like cost estimation and a more robust run queue.

1. What is Terraform, and why is it used?

2. Explain the difference between Terraform and other IaC tools like Ansible, Puppet, or Chef.

3. What is the difference between Terraform and CloudFormation?

4. What are Terraform providers, and how do they work?

5. Explain the concept of Terraform state.

6. What are the different types of Terraform state backends?

7. Why do we need a remote backend in Terraform?

8. How does Terraform handle dependencies between resources?

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

10. Explain the purpose of the terraform init command.

11. What are Terraform modules, and why are they used?

12. How do you create and use a Terraform module?

Creating a Module

Using a Module

13. What are input variables in Terraform?

14. What are output variables in Terraform?

15. How do you pass variables to Terraform?

16. What are the different ways to manage secrets in Terraform?

17. What are Terraform workspaces?

18. How do you use workspaces in Terraform?

19. What is the difference between local and remote state in Terraform?

20. What is state locking in Terraform, and why is it important?

21. How does Terraform detect resource drift?

22. What are Terraform data sources?

23. Explain the difference between count and for_each in Terraform.

24. What is the difference between depends_on and implicit dependencies?

25. What are Terraform provisioners, and when should you use them?

26. What are dynamic blocks in Terraform?

27. How do you manage multiple environments in Terraform?

28. What are some best practices for structuring Terraform code?

29. What is the difference between terraform refresh and terraform apply?

30. How do you perform a targeted resource deployment in Terraform?

31. What happens when you delete the Terraform state file?

32. What are some ways to upgrade provider versions in Terraform?

33. What is the purpose of the .terraform.lock.hcl file?

34. How do you import existing infrastructure into Terraform?

35. What are Terraform resource taints?

36. How do you destroy a specific resource in Terraform?

37. What is the difference between soft delete and hard delete in Terraform resources?

38. How do you handle versioning of Terraform modules?

39. What are some common Terraform workflow commands in CI/CD pipelines?

40. What is the difference between local-exec and remote-exec provisioners?

41. What are Terraform functions, and can you give examples?

Examples

42. How do you reference outputs from one module into another module?

Example:

43. What are Terraform expressions?

Examples:

44. What is the difference between terraform state list and terraform show?

45. What is drift detection, and how does Terraform handle it?

46. How do you roll back infrastructure changes with Terraform?

47. What is the difference between declarative and imperative approaches in IaC, and where does Terraform fit?

48. How does Terraform ensure idempotency?

49. What are some limitations of Terraform?

50. How do you debug issues in Terraform?

51. What are the benefits of using Terraform over manual provisioning?

52. Explain the concept of “desired state” in Terraform.

53. What is the role of HCL (HashiCorp Configuration Language) in Terraform?

54. Can Terraform work with multiple cloud providers in the same configuration?

55. How do you define resource dependencies in Terraform?

56. What are Terraform meta-arguments?

57. What is the difference between lifecycle meta-arguments like create_before_destroy and prevent_destroy?

58. How do you use conditional expressions in Terraform?

59. What is the difference between terraform plan -out and terraform apply with a plan file?

60. How do you share Terraform state between team members?

61. How do you handle sensitive data in Terraform outputs?

sensitive Argument

Secrets Management Systems

62. What is the difference between local values and variables in Terraform?

63. How do you restrict provider versions in Terraform?

64. What happens if you change a resource name in Terraform configuration?

65. Explain how Terraform manages immutable and mutable infrastructure changes.

66. What is the difference between resource arguments and attributes in Terraform?

67. How do you organize Terraform projects for a large enterprise setup?

68. What is the difference between a module source from registry, GitHub, and local path?

69. How do you test Terraform code?

70. What is the purpose of terraform validate?

71. How does terraform fmt help in Terraform workflows?

72. What is the purpose of the .terraform directory?

73. How do you roll out infrastructure changes gradually with Terraform?

`sensitive` Argument