Reading, Generating and Modifying Configuration — Terraform Associate 004 practice questions

Which statement about output values is correct?

1. An output is computed by the parent module and then consumed inside the child module
2. An output cannot reference resource attributes; only literals and variables are permitted
3. An output exposes a module value to its caller, or prints it at the CLI in the root module
4. An output block is required on every resource so that its attributes can be read from elsewhere

Answer: C — An output exposes a module value to its caller, or prints it at the CLI in the root module

C is right: outputs are a module's return values. A caller reads them as module.<name>.<output>, and in the root module they are printed after apply and readable with terraform output. A reverses the direction — values flow into a module through variables and out through outputs. B is false; exposing resource attributes is their main use. D invents a requirement: outputs are optional, and you declare only what callers need.

When should you use 'for_each' instead of 'count'?

1. Never - count supersedes for_each and for_each remains only for backwards compatibility
2. Only when the value being iterated is a boolean that switches a resource on or off once
3. Only when the collection is a list of numbers, since for_each cannot accept string keys
4. Only when querying an external database, where each row becomes one managed resource
5. When iterating a map or set, so instances keep stable keys as members are removed

Answer: E — When iterating a map or set, so instances keep stable keys as members are removed

E is right: for_each keys each instance by a string, so removing one member leaves the others untouched, whereas count reindexes and forces needless replacements. A reverses current guidance. B describes the classic count = var.enabled ? 1 : 0 idiom. C is false - string keys are exactly the point. D is unrelated to either meta-argument.

Which lifecycle argument errors any plan that would destroy a resource?

1. prevent_destroy, which makes any plan proposing destruction fail with an error
2. ignore_destroy, which drops destroy actions silently from the generated plan
3. no_destroy, which requires an override flag on the command line to proceed
4. lock, which holds the state lock open so that no other run can destroy it

Answer: A — prevent_destroy, which makes any plan proposing destruction fail with an error

A is right: with prevent_destroy set to true, a plan that would remove the resource fails outright rather than proceeding. B and C are invented names, and B additionally describes silent suppression, which would be far more dangerous than an error. D confuses a lifecycle guard with state locking. Note that deleting the resource block still produces an error rather than a quiet destroy, so you must remove the guard deliberately.

Which statement about count vs for_each is correct?

1. count requires a set or map; for_each requires an integer.
2. count and for_each are interchangeable and produce identical resource addresses.
3. count requires an integer; for_each requires a map or set of strings.
4. Both require a list of objects.

Answer: C — count requires an integer; for_each requires a map or set of strings.

Trick: A is the direction-reversal. count = N (number). for_each = map or set of strings. Their resource addresses differ: aws_instance.x[0] vs aws_instance.x["key"].

Terraform configuration files use which file extension?

1. .yaml, parsed with the same loader that Kubernetes manifests and Ansible playbooks use
2. .json only, since Terraform dropped its native syntax in favour of a portable format
3. .tf for native HCL, or .tf.json for the JSON variant; both load from the same directory
4. .py, because configurations are Python programs evaluated to produce a resource graph
5. .ts, compiled to a provider-independent representation before the plan is calculated

Answer: C — .tf for native HCL, or .tf.json for the JSON variant; both load from the same directory

C is right: Terraform loads every .tf and .tf.json file in the working directory as one configuration; conventional names such as main.tf, variables.tf and outputs.tf are habit, not a requirement. A is a different ecosystem. B is false - HCL remains the native form. D and E describe CDKTF-style tooling, not core Terraform.

Which command-line flag passes a variables file at runtime?

1. -var-file=PATH
2. -vars=PATH
3. -from-file=PATH
4. -load-vars=PATH

Answer: A — -var-file=PATH

Trick: the flag is -var-file (singular hyphenated form). -var=name=value sets a single variable.

Which is correct HCL for joining a list of strings with commas?

1. join(",", var.names)
2. concat(var.names, ",")
3. merge(var.names, ",")
4. split(",", var.names)

Answer: A — join(",", var.names)

Trick: each of B, C, D is a different function. concat joins lists, merge joins maps, split is the inverse of join. join(SEP, LIST) → string.

Which pairing of custom condition and evaluation moment is INCORRECT?

1. check assert — during plan and apply, without failing the run
2. variable validation — after all resources have been planned
3. precondition — before the containing object is acted upon
4. postcondition — after the object is created or refreshed

Answer: B — variable validation — after all resources have been planned

A) Check assertions are evaluated during plan and apply and only produce warnings. B) Correct — this is the false pairing: variable validation runs when variable values are evaluated, well before resource planning. C) Preconditions do run before Terraform acts on the containing object. D) Postconditions do run after creation or refresh of the object.

A team wants Terraform to verify that a newly created object came out with the properties they expect, failing the run if not. The MOST appropriate placement is:

1. A postcondition in the lifecycle block
2. A precondition in the resource lifecycle block
3. A check block placed next to the resource
4. A validation block in the variable that feeds the resource

Answer: A — A postcondition in the lifecycle block

A) Correct — postconditions are evaluated after the object is created or refreshed and fail the run when the resulting attributes violate the assumption. B) Preconditions run before creation, when the resulting attributes are still unknown. C) Check blocks would only warn, not fail. D) Variable validation constrains only the input, not the object the provider actually produced.

A stateful database resource must never be destroyed by an accidental apply. Which approach gives the strongest configuration-level guardrail?

1. Store the resource in a separate CLI workspace
2. Add every attribute of the resource to the lifecycle ignore_changes list
3. Mark all of the resource's outputs as sensitive
4. Set prevent_destroy = true in the resource lifecycle block

Answer: D — Set prevent_destroy = true in the resource lifecycle block

A) A separate workspace isolates state but a destroy in that workspace still succeeds. B) ignore_changes suppresses attribute drift but does nothing about a destroy. C) Sensitivity affects output display only and has no bearing on destruction. D) Correct — prevent_destroy makes Terraform error out at plan time if the plan would destroy that object, forcing a deliberate config change first.

Variable precedence (highest to lowest)?

-var/--var-file (CLI), terraform.tfvars + auto.tfvars, TF_VAR_* env, default in variable block.

Implicit dependencies?

Terraform infers from references. resource_a uses resource_b's attribute.

create_before_destroy?

Create new before destroying old. Useful for zero-downtime updates.

Variables?

variable "<name>" { type = ... default = ... }. Inputs to configuration.