Terraform interview questions — live practice quiz

DRY Terraform modules are achieved by defining reusable input variables with sensible defaults, extracting repeated resource blocks into a shared module sourced by multiple configurations, and parameterizing values like region or instance type instead of hard-coding them. Copy-and-pasting resource blocks across environments is the opposite of DRY.

The command you run first in a new or freshly-cloned configuration to initialize the working directory and download providers is terraform **init**.

Writing one parameterized Terraform module and calling it with different tfvars files per environment keeps code DRY because the same module source is reused with different input values, and a bug fix applied to the module benefits all environments. Modules do not replace remote backends or give teams separate editable copies.

To pin the Terraform CLI version used for a configuration, you set the **required_version** argument inside the terraform {} block — for example:

terraform { required_version = ">= 1.5.0, < 2.0.0" }

This tells Terraform to fail fast if the running CLI version does not satisfy the constraint.

In a Terraform version constraint, the pessimistic constraint operator **~>** allows updates within the same minor version band. For instance, **~>** 3.0 permits any release from 3.0.0 up to (but not including) 4.0.0.

The resource type (e.g., aws_instance) and the resource name (e.g., web). Together they form the unique resource address, e.g., aws_instance.web.

The state file maps each resource address in your configuration to the real infrastructure object Terraform created (an instance id, a bucket ARN). Terraform reads it to compute the diff between desired and actual state, so it knows what to create, update, or destroy. It is not where you declare desired infrastructure (that's your .tf files), and it is not a credential or plugin cache.

terraform plan is a dry run: Terraform refreshes state, compares the desired configuration against the real infrastructure, and prints the set of changes (create/update/destroy) it would make, without changing anything. terraform apply actually executes changes to reach the desired state; by default it shows the same plan and asks for confirmation before applying. Running plan first matters because it's the review step — you (and reviewers in a PR) can see exactly what will be created, replaced, or destroyed before any real resource is touched, catching accidental destroys or replacements. Teams often save a plan (-out) and apply that exact plan so what's reviewed is what's executed.

A provider is a plugin that lets Terraform manage a specific platform's API — AWS, Azure, GCP, Kubernetes, Cloudflare, and so on. It defines the resource types and data sources you can use and translates Terraform's create/read/update/delete operations into that platform's API calls. You declare which providers and versions you need in a required_providers block, and terraform init downloads them. Without a provider, Terraform has no resources to manage.

Hard-coding secrets in .tf files exposes them in version control, and Terraform state files store all attribute values — including secrets — in plaintext. The two recommended approaches for passing secret values safely are: (1) inject them at runtime via environment variables (TF_VAR_*), and (2) retrieve them from a dedicated secrets manager (e.g., AWS Secrets Manager, HashiCorp Vault). Separately, mark sensitive outputs with sensitive = true to suppress console display, and store state in a secure, encrypted backend — but note that sensitive = true only hides values from the console; it does NOT protect secrets in the state file.

-/+ means Terraform will destroy the existing resource and then create a new one, because a changed attribute is immutable and cannot be updated in place; # forces replacement flags that attribute. An in-place update shows ~, and +/- (create-then-destroy) is the order produced by create_before_destroy. Spotting -/+ on a stateful resource is the warning that an edit will be destructive.

`{ env = "prod", team = "core" }`

True. Using for_each on a single resource block to create multiple similar resources from a map is the standard DRY pattern in Terraform. It eliminates duplicated block structure, prevents copy-paste drift, and lets you manage all instances through one map, which is exactly the kind of single-source-of-truth design the Terraform style guides recommend.

The correct order is a → b → d → c → e: the secret originates in a secrets manager, Terraform reads it via a data source, passes it to the provider during apply (which calls the cloud API), records the result (marked sensitive) in state only after the API call succeeds, and the target resource then stores and uses it at runtime. Terraform writes state after the provider API call, not before.

Because count addresses instances by numeric index, removing a middle element shifts every later element's index down by one. Terraform then sees those shifted positions as different objects and plans to destroy and recreate them — not just the removed one. for_each avoids this by keying instances on a stable string, so removing one key only destroys that key's resource. Prefer for_each for collections whose membership changes.

The lifecycle block accepts create_before_destroy (reverse the replace order to avoid downtime), prevent_destroy (reject plans that would destroy the resource), and ignore_changes (ignore drift on listed attributes), along with replace_triggered_by. depends_on is also a meta-argument but belongs at the resource level, not inside lifecycle. Placing it inside lifecycle is a frequent mistake.

False. sensitive = true only hides a value from CLI output, showing <sensitive> in plan and apply logs; the value is still stored in plaintext in the state file, and terraform output -json or -raw reveals it. Keeping a value out of state requires an ephemeral output. Real protection comes from encrypting the backend and restricting access to state, not from the sensitive flag.

Line 7 — the resource references its own .id in its arguments, which Terraform cannot resolve because the id isn't known until the resource is created

A local state file means each engineer has their own copy, so the state diverges and is never authoritative; it also isn't backed up and can be lost or committed to git with secrets in it. A remote backend stores a single shared state in a central, durable location so the whole team plans and applies against the same source of truth. Crucially it enables state locking: while one apply holds the lock, others are blocked, preventing two people from writing state at once and corrupting it. It also gives durability/versioning (S3 versioning, backups) and keeps the (plaintext) state off laptops behind access controls and encryption at rest.

Terraform's config-driven import (1.5+) adopts an existing resource through a fixed sequence. The correct order is: first write an import block giving the target resource address and the existing object's id, then run terraform plan -generate-config-out=generated.tf to produce matching configuration, then review and prune that generated config to the arguments you want to manage, then run terraform apply to import the object into state and reconcile it, and finally remove the now-satisfied import block. Being plannable is what makes it reviewable in a PR and safe in CI.

Module factoring. One shared module (modules/service) encodes the infrastructure shape. Each environment is its own root configuration (environments/dev, /staging, /prod) that calls the shared module and passes per-env inputs (instance size, replica count, domain) as variables. The shape is defined once; environments differ only in inputs, so they stay DRY without branching on var.env with conditionals.

State isolation. Each environment root has its own backend state — e.g. the same S3 bucket with a distinct key (dev/terraform.tfstate, prod/terraform.tfstate) or separate buckets/accounts. Because Terraform only ever sees one environment's state at a time, a dev plan/apply physically cannot reference or destroy prod objects. Blast radius is bounded by the state boundary.

Backend & locking. Remote backend (S3 with native lockfile or DynamoDB, or Terraform Cloud) with locking so concurrent applies serialize and can't corrupt state, plus encryption at rest. No local state for a team.

Secrets. No secrets in .tf or committed tfvars. Pull them from a secret manager (SSM/Secrets Manager) via data sources, or inject as CI/TF_VAR variables. Note that any value used still ends up in plaintext state, so state access control and encryption — not sensitive = true — are the real protection.

Workflow. CI runs terraform plan on every PR and posts it for review; on merge it applies the reviewed plan per environment, promoting dev → staging → prod. Providers and the shared module are version-pinned (and a committed lock file) for reproducibility.

Tradeoffs. Directory-per-environment is explicit and isolates state cleanly at the cost of some repetition in the thin root configs. Terraform workspaces keep one config + one backend and switch state by workspace — lighter, but it's dangerously easy to apply to the wrong workspace and they share backend config, so they suit ephemeral/per-developer copies more than long-lived dev/staging/prod. Full duplication of the module per env is the worst of both: lots of drift, no single source of truth.

FALSE. DRY in Terraform means reusing well-scoped, composable modules across environments — not collapsing everything into one heavily parameterized mega-module. A single generic module with complex count/dynamic logic to suppress unused resources is a recognized anti-pattern: it creates fragile code, obscures plan output, and widens the blast radius of every change. Focused modules with clear single responsibilities are preferred.

Provider version constraints are declared in the root module of each workspace via the required_providers block. I recommend the pessimistic constraint operator ~> — for example, version = "~> 5.0" allows 5.x patches and minor releases but blocks 6.0. This gives teams automatic access to bug fixes and new resources within a major version while guaranteeing no breaking-change surprise. For providers with a history of regressions in minor releases, a tighter ~> 5.40 (patch-only) bound is appropriate.

Shared child modules also declare their own required_providers blocks, but with broader constraints — e.g., version = ">= 5.0". Terraform computes the intersection of the root module's constraint and every child module's constraint, so the effective version is the most restrictive set. This lets modules express their minimum compatibility without over-constraining consumers. Modules must never pin exact versions (e.g., = 5.40.2), because that would force every consumer into the same exact version and break the intersection logic when two modules disagree.

The upgrade workflow is version-controlled and gated:

1. A team member opens a PR bumping the required_providers constraint (e.g., from ~> 5.40 to ~> 5.41) and runs terraform init -upgrade to pull the new provider and regenerate .terraform.lock.hcl.
2. CI runs terraform plan against a non-production workspace; the plan diff is reviewed for unexpected resource changes that the provider upgrade might introduce.
3. Automated policy checks (OPA or Sentinel) validate that the new version is within the platform-approved range and that no deprecated resources are referenced.
4. After merge, the same constraint is promoted to production workspaces following the team's normal apply cadence.

The .terraform.lock.hcl file is committed to every workspace repository so that every terraform init reproduces the exact provider version and checksum.

For drift detection, the platform team maintains a centralized scanner (a scheduled CI job or a tool like tf-summarize / a custom script) that clones every workspace repository, parses each .terraform.lock.hcl, and builds a dashboard showing the resolved provider version per workspace. Any workspace whose locked version falls outside the approved range (e.g., below the latest patch for a CVE) is flagged in a tracking issue. The platform team can then open automated PRs to bump the constraint and regenerate the lock file, or notify the owning team with a remediation SLA.

Use flatten() to collapse the per-environment lists of objects into a single flat list, then a for expression to iterate that flat list and build a map keyed by a composite string. The full pattern is: for_each = { for s in flatten([for env, subnets in var.environments : [for sn in subnets : { env = env, name = sn.name, cidr = sn.cidr }]]) : "${s.env}-${s.name}" => s }. flatten() runs first (as the iterable inside the for expression), and the for expression produces the final map. Composite keys are necessary because two environments may define a subnet with the same name (e.g., both have "app"); a map cannot contain duplicate keys, so using only name would silently overwrite entries, causing Terraform to create fewer subnets than intended. The environment prefix guarantees uniqueness across the entire flattened set.

From lowest to highest precedence, Terraform 1.x resolves variable values as: (1) the default in the variable block, (2) TF_VAR_* environment variables, (3) terraform.tfvars / terraform.tfvars.json, (4) *.auto.tfvars / *.auto.tfvars.json (alphabetical), and (5) -var / -var-file command-line flags. Each higher source shadows the one below it, so a committed tfvars file can override an env-var secret, and a -var flag overrides everything.