TERRAFORM-004 Practice Questions: Terraform Fundamentals Domain

When using a backend that supports state locking, only one operation can modify state at a time. If `terraform apply` is hanging, another run likely holds the lock. The correct approach is to coordinate with the person or system holding the lock (C), wait for that run to finish or be canceled, and then rerun your command. Forcing recreation with `-replace=*` (A) does not bypass locking and is dangerous. Manually editing remote state (B) risks corruption and is not supported. Switching to local state (D) to avoid locking can lead to divergent or corrupted state and should not be used as a workaround.

When using a backend that supports locking, Terraform acquires a state lock at the start of operations like `apply` and `plan` (with refresh). The first operation obtains the lock; subsequent operations either block until the lock is released or fail with a locking error, depending on the backend and CLI options. A: Terraform does not merge concurrent state updates. C: Conflicts are prevented by locking, not detected afterward. D: Terraform does not automatically create or switch workspaces to avoid conflicts.

Terraform 1.x supports declarative imports via `import` blocks. B: Correct. An `import` block in configuration documents the mapping between the existing bucket and the Terraform resource; `terraform apply` will perform the import and then manage the bucket. A: The `terraform import` CLI works but is more imperative and less self-documenting than `import` blocks; the exam emphasizes the newer workflow. C: Terraform does not automatically adopt existing resources; without import, it will try to create another bucket or fail. D: Deleting a production bucket is risky and unnecessary when import is available.

To bring an existing resource under Terraform management, you must both define the resource in configuration and associate it with the real infrastructure object. In Terraform 1.x, this is done with `terraform import` (or import blocks). B correctly imports the existing security group into the state for the resource `aws_security_group.web`. A: Terraform will attempt to create a new security group, not adopt the existing one. C: Data sources are read-only and cannot be imported. D: `prevent_destroy` only affects destroy behavior; it does not link to existing resources.

Terraform 1.x supports variable validation blocks to enforce custom conditions. B uses `validation` with `contains()` to restrict `instance_type` to an explicit allowlist and provides a clear error message, causing `terraform plan` (and `apply`) to fail if the condition is not met. A: Provides no validation; any string is accepted. C: Uses the wrong type (list) and only checks non-emptiness, not allowed values. D: `lifecycle` is not valid inside a variable block and `prevent_destroy` applies to resources, not variables.

To assign different `instance_type` values per instance and preserve resources as much as possible, you should refactor from `count` to `for_each` using a map keyed by stable identifiers (for example, `web1`, `web2`, `web3`). Then, use `moved` blocks to tell Terraform how existing instances (by index) map to the new keys. This minimizes recreation. Option C is correct.

A: Refactoring to `for_each` without `moved` blocks will cause Terraform to destroy and recreate resources because the addresses change.
B: Using `count.index` with conditionals quickly becomes brittle and doesn’t scale; it also doesn’t express a clear mapping per instance.
D: Changing `count` length alone does not allow per-instance types and does not preserve identity when the order or size changes.

With local state (the default), Terraform writes `terraform.tfstate` and backup files like `terraform.tfstate.backup` in the working directory. To avoid committing sensitive state to version control, you should add `terraform.tfstate` and `terraform.tfstate.*` patterns to `.gitignore`. Option C is correct.

A: A remote backend would avoid local state, but the scenario explicitly wants local state and simplicity.
B: Ignoring `.terraform/` is good practice (it contains plugins and metadata) but does not prevent committing the state file itself.
D: There is no `TF_STATE_IGNORE` environment variable; Terraform always writes state unless configured with a backend that behaves differently.

When refactoring resources (e.g., moving them into modules) and you want to keep the existing infrastructure, you use `moved` blocks to tell Terraform how the resource address changed. This updates state without destroying and recreating the resource. `-replace` (A) does the opposite: it forces recreation. Deleting `.terraform` and re-initializing (C) does not inform Terraform about address changes. `depends_on` (D) only affects dependency ordering, not state mapping or addresses.

The dependency lock file `.terraform.lock.hcl` records the exact provider versions used. When you change version constraints and want Terraform to select newer versions and update the lock file, you should run `terraform init -upgrade`. This re-evaluates version constraints and updates the lock file accordingly. Deleting the lock file (A) works but discards the benefits of controlled, reproducible versions and is not the recommended workflow. Manually editing the lock file (C) is discouraged; Terraform manages it. `terraform apply` (D) does not ignore the lock file and will not resolve the mismatch correctly without re-initialization.

Terraform 1.x introduced `removed` blocks to declare resources that should be removed from state without affecting real infrastructure. This is ideal when you want Terraform to stop managing a specific instance (e.g., a bucket) while leaving it intact in the provider. A: `prevent_destroy` blocks deletion but does not remove the resource from state. B: `moved` blocks are for refactoring addresses, not for forgetting resources. D: `-replace` forces recreation of a resource; it does not detach it from state and would risk deleting/recreating the bucket.