45+ Advanced Terraform Interview Questions for 5+ Experienced

A **remote backend** stores the Terraform state file in a shared, remote location (like an S3 bucket, GCS bucket, or Azure Blob Storage). By default, Terraform stores state in a local file named `terraform.tfstate`.

It’s crucial for teams because:

• Shared State: It provides a single source of truth for the infrastructure’s state, allowing all team members to work from the same up-to-date information.
• State Locking: Most remote backends support locking. When one person runs `terraform apply`, the state is locked, preventing other team members from running concurrent `apply` commands and corrupting the state.
• Security: It keeps potentially sensitive information out of local developer machines and source control.

Read the documentation on Remote Backends.

• `terraform refresh`: Reconciles the state file with the real-world infrastructure. It queries the cloud provider to check for any “drift” (changes made outside of Terraform) and updates the state file to match reality. This command is now implicitly run as part of a `plan`.
• `terraform plan`: Creates an execution plan. It compares the desired state (your HCL code) with the current state (in the state file, after a refresh), and shows you what actions Terraform will take (create, update, or destroy) to make the real infrastructure match your code. It does *not* make any changes.
• `terraform apply`: Executes the plan generated by `terraform plan`. It performs the actual create, update, and delete operations on your cloud resources.

A **provisioner** is a feature that lets you execute scripts or configuration management tools on a local or remote machine as part of resource creation or destruction. Examples include `local-exec` (runs a command on the machine running Terraform) and `remote-exec` (runs a command on the newly created resource via SSH).

They are a last resort because Terraform cannot model the state of the actions they perform. If a provisioner fails, Terraform may not be able to recover cleanly and can leave the state file in a tainted, unknown state. The preferred approach is to use cloud-native initialization mechanisms like `user_data` scripts (for EC2) or to build custom machine images (e.g., with Packer) that already have the required software installed.

Read about Provisioners in the official docs.

A Terraform provider is a plugin that is responsible for understanding API interactions and exposing resources for a specific service (like AWS, GCP, or even Datadog).

Its key components are:

• Resources: The primary component. A resource definition maps to an object that can be created, read, updated, and deleted (CRUD), like an `aws_instance`.
• Data Sources: Allow Terraform to fetch information about existing resources that are managed outside of the current Terraform configuration.
• Provider Configuration: The block that configures the provider itself, such as setting the region or providing credentials.

`terraform init` is the first command you run in a new or cloned Terraform project. It performs several initialization steps:

1. Backend Initialization: Configures the backend where the state file will be stored (e.g., S3).
2. Provider Plugin Installation: Scans the code for provider requirements, downloads the necessary plugins from the Terraform Registry, and installs them in the `.terraform` directory.
3. Module Installation: If the configuration uses modules from external sources (like Git or the Registry), it downloads them into the `.terraform/modules` directory.

Both `count` and `for_each` create multiple instances of a resource.

• `count`: Creates a list of identical resources. The instances are identified in the state file by an integer index (e.g., `aws_instance.server[0]`, `aws_instance.server[1]`). If you remove an item from the middle of the list, Terraform will see it as a change to all subsequent items, potentially causing them to be destroyed and recreated.
• `for_each`: Iterates over a map or a set of strings. The instances are identified in the state file by the map key or set string (e.g., `aws_instance.server[“app-a”]`, `aws_instance.server[“app-b”]`).

**`for_each` is almost always preferred** because it creates a stable mapping between your configuration and the resources. If you remove an item, only that specific resource is destroyed, and the others are unaffected. This makes your configuration more resilient to changes.

Read the documentation on `for_each`.

A **dynamic block** allows you to dynamically generate nested configuration blocks (like `ingress` rules in a security group or `setting` blocks in an App Service) inside a resource argument.

It solves the problem of needing to create a variable number of these nested blocks. Without dynamic blocks, you would have to resort to complex workarounds or create separate resources for each variation. A dynamic block iterates over a complex data structure (like a list of objects) and renders a configuration block for each item, making your code much cleaner and more reusable.

Explore Dynamic Blocks in the documentation.

A `locals` block is used to define local variables within a module. Its purpose is to reduce repetition and improve readability. You can use it to assign a short, descriptive name to a complex expression or to combine several values into a new data structure. Unlike input variables, local values cannot be overridden from outside the module. They are purely for making the code inside a module cleaner and easier to maintain.

• `try(…)`: Evaluates a series of expressions and returns the result of the first one that succeeds without errors. If all expressions fail, it returns a specified fallback value. It’s useful for gracefully handling cases where an attribute might not exist.
• `can(…)`: Evaluates an expression and returns `true` if it can be evaluated successfully, or `false` if it produces an error. It’s a boolean check used for conditional logic where you need to know if a value is available before attempting to use it.

The standard way to create a conditional resource is to use the `count` meta-argument. You can set `count` based on a boolean variable. If the condition is true, `count` is set to 1, creating one instance of the resource. If the condition is false, `count` is set to 0, and no instances are created.

Example: `count = var.create_public_ip ? 1 : 0`

For resources created with `for_each`, you can achieve a similar effect by passing a conditionally filtered map to `for_each`.

A complex object is a data structure with nested attributes, like a map of objects or a list of maps. You define a variable for it using a type constructor like `object(…)` or `map(…)`.

Example for a variable that expects a map of user objects:

variable "users" {
  type = map(object({
    email = string
    is_admin = bool
  }))
}

Defining the type explicitly makes the configuration more robust and provides better validation and IDE support.

• Reusability: Package common infrastructure patterns into a reusable unit that can be called multiple times.
• Organization: Break down a complex configuration into smaller, more manageable pieces.
• Encapsulation: Hide the complexity of a set of resources behind a simple interface (the module’s input variables).
• Consistency: Enforce standards and best practices by providing a standardized way to deploy a certain piece of infrastructure.

You can source modules from various locations:

• Local Paths: A directory on your local filesystem (e.g., `source = “./modules/vpc”`).
• Terraform Registry: The public or a private Terraform Registry (e.g., `source = “terraform-aws-modules/vpc/aws”`).
• Git Repository: Any Git repository over protocols like HTTPS or SSH. You can specify a branch, tag, or commit hash (e.g., `source = “git::https://example.com/vpc.git?ref=v1.0.0″`).
• HTTP URLs: A URL that points to a `.zip` archive of a module.

You define outputs in a module’s `outputs.tf` file using an `output` block. This exposes specific values from the resources created inside the module. In the parent module that calls this module, you can then access these outputs using the syntax `module..`. This is the only way to access resource attributes from within a child module.

By default, a child module inherits the provider configurations from its parent. However, if you need to use a different provider configuration (e.g., deploying a resource into a different AWS region or account), you can pass it explicitly. You define multiple provider blocks in the parent module with an `alias`, and then pass the aliased provider to the child module via the `providers` meta-argument in the `module` block.

• Directories: Each environment (dev, staging, prod) has its own directory with its own set of `.tf` files and its own state file. This provides strong isolation but can lead to code duplication. This is often the recommended approach for production systems.
• Workspaces: Allows you to manage multiple states from a single directory of configuration files. Each workspace has its own separate state file. This is useful for feature branch development or temporary environments but can be problematic for managing distinct long-lived environments like dev/prod, as all environments share the same code and a change cannot be easily promoted from one to another.

Read When to use Multiple Workspaces.

Terragrunt** is a thin wrapper around Terraform that provides extra tools for working with multiple Terraform modules. It helps solve common problems in large-scale Terraform projects:

• DRY (Don’t Repeat Yourself): It allows you to define your backend configuration, provider versions, and input variables once in a parent `terragrunt.hcl` file and inherit them across multiple modules, reducing boilerplate.
• Orchestration: It helps manage dependencies between different Terraform modules, allowing you to `apply` or `destroy` multiple modules in the correct order.
• State Management: It simplifies the management of remote state configuration for multiple environments.

Visit the official Terragrunt website.