Free HashiCorp Terraform Associate 004 practice test

Option B is correct: this is Terraform's idempotency in action. On the second apply, Terraform refreshes state, detects that the live resource differs from the desired configuration, and generates a plan to reconcile the drift by updating the address space back to the configured value. Option A is wrong; Terraform does not simply skip existing resources — it compares current state to desired state on every apply. Option C is incorrect; Terraform does not destroy and recreate an entire resource group for a single attribute change unless the specific attribute forces replacement. Option D is false; Terraform handles drift reconciliation automatically and does not redirect users to the console.

Correct (A, C): Version control (A) solves the auditability problem — every change is tracked, attributed, and reversible, which is impossible with manual console clicks. Consistency and repeatability (C) solve configuration drift — the same Terraform configuration always produces the same infrastructure, whereas humans clicking through a console make mistakes and produce subtly different environments. (B) is wrong — Terraform does not analyze or select cloud regions based on cost; that is outside its scope. (D) is wrong — Terraform does not natively compress or encrypt S3 state files; encryption must be configured at the S3 bucket level or via a KMS key in the backend config. (E) is wrong — Terraform produces no compliance PDF reports; that is the domain of separate audit/compliance tools.

Correct (A): This scenario demonstrates Terraform's idempotency. On the second terraform apply, Terraform runs a refresh (comparing the real infrastructure to the state file), detects that the S3 bucket no longer exists, and creates it again to reconcile the real world with the desired state. The configuration has not changed, but the actual infrastructure has drifted. (C) is wrong — Terraform does not compare configuration-to-configuration; it compares desired state to actual state, so it will detect the drift. (B) is wrong — a missing resource does not cause an error during plan/apply; Terraform treats it as a resource that needs to be created. (D) is wrong — Terraform does not require manual user intervention for missing resources; it handles recreation automatically.

Correct: C. The + symbol in a Terraform plan output means the resource is planned for creation — it does not currently exist in the Terraform state and will be provisioned when apply is executed. A is wrong — removing a resource from state without destroying infrastructure is done with terraform state rm, which does not appear as + in a plan. B is wrong — destroy-and-recreate is represented by the -/+ symbol, not +. D is wrong — in-place updates to existing resources are represented by the ~ symbol.

Option C is correct: Terraform's locals block supports arbitrary expressions including references to var.*, data.*, and other local.* values. Terraform resolves locals using dependency ordering, so full_name depending on env_prefix within the same block is perfectly valid — Terraform figures out the correct evaluation order automatically. Option A is wrong — locals can freely reference input variables. Option B is wrong — cross-references within the same locals block are allowed as long as there are no cycles. Option D is wrong — there is no requirement to split dependent locals across separate blocks; a single block is fine.

Correct: A and C. The terraform block serves two primary purposes relevant here: (A) It accepts a required_version constraint that enforces which versions of the Terraform CLI can be used with the configuration, preventing accidental use with incompatible versions. (C) It accepts a backend block (nested within the terraform block) that configures where state is stored (e.g., S3, Azure Blob, HCP Terraform). B is wrong — default_tags is an argument supported within the AWS provider configuration block (under provider "aws"), not in the terraform block itself. D is wrong — the terraform block cannot contain resource definitions; resources are declared in separate top-level resource blocks. E is wrong — required_providers can reference providers from any source, including third-party registries and even local filesystem paths, not only the official HashiCorp registry.

Option C is correct. When depends_on is applied to a resource (or module), Terraform cannot use its normal fine-grained dependency analysis. If the depends_on target has any pending changes, Terraform must treat the dependent resource's attributes as unknown during planning — because any side effect could theoretically change what values are produced. This results in a less informative plan where values show as (known after apply) even when they could otherwise be known. Option B is wrong — depends_on is purely a planning-time directive; Terraform does not pre-validate the existence of the target in real infrastructure. Option A is partially related but is specifically a behavior of depends_on on modules, not resources, and the mechanism described is not quite accurate. Option D is wrong — depends_on does not cause unconditional replacement; it only affects ordering and planning granularity.

Option B is correct: attribute references (e.g., aws_security_group.web.id) implicitly create dependency ordering in Terraform's graph. Adding depends_on on top of an already-implied dependency is redundant. However, Terraform's documentation notes that depends_on can cause Terraform to be more conservative—when depends_on is present, Terraform may replace resources more aggressively if the dependency changes, which is why it is recommended to use depends_on only when necessary. Option D is incorrect: attribute references do create implicit ordering. Option C is incorrect: depends_on does not trigger replacement; it only affects ordering. Option A is a partial truth—Terraform does serialize work when dependencies exist, but adding an already-implied depends_on does not newly prevent parallelism that was not already prevented by the reference.

Correct: B. When a resource expression references another resource's attribute (e.g., aws_security_group.web.id), Terraform automatically infers an ordering dependency. Adding an explicit depends_on for the same resource is therefore redundant—the ordering is already established. The duplicate depends_on does not alter the plan or apply behavior. A is wrong because Terraform's reference-based implicit dependency is sufficient for ordering; depends_on is only needed when a dependency exists that cannot be expressed through references (e.g., a hidden side effect). C is wrong because depends_on affects ordering, not the set of attributes tracked for change detection; it does not cause unnecessary replacements. D is wrong because switching from an implicit to an explicit dependency (or having both) does not trigger a replace—the resource configuration itself has not changed.

Option A is correct: dynamic blocks are specifically designed to programmatically generate repeated nested blocks (like tag blocks in aws_autoscaling_group) based on a collection. Using for_each within the dynamic block iterates over the map and produces one tag block per entry.

Option B is wrong: count controls how many instances of the entire resource are created, not how many nested blocks exist within a single resource instance.

Option C is wrong: multiple locals blocks do not generate nested blocks inside a resource. They only define reusable values within a module.

Option D is wrong: a for expression can produce a list or map value, but the tag argument in aws_autoscaling_group requires repeated blocks, not a list value. You cannot substitute a for expression for repeated block syntax — that is exactly what dynamic blocks solve.

Option A is correct: toset() converts a list (or other collection) to a set, automatically removing duplicate values and dropping order, which matches the set(string) type expected by the resource.

Option C is wrong: distinct() removes duplicate elements from a list but returns a list, not a set. The resource still expects a set(string), so a type mismatch would occur.

Option B is wrong: tolist() converts a set or tuple to a list — it goes in the opposite direction of what is needed here.

Option D is wrong: compact() removes empty strings from a list of strings but does not remove non-empty duplicates, and it returns a list, not a set.

Option B is correct: a map(string) variable is assigned using HCL object literal syntax with key-value pairs inside curly braces. Option D is wrong because it passes a list of strings (using square brackets), which does not match the map(string) type and will cause a type mismatch error. Option A is wrong because module input arguments are specified by the variable name alone (without the var. prefix); var.tags = ... is not valid syntax in a module block. Option C is wrong because passing a single comma-delimited string does not match the map(string) type constraint.

Option D is correct: child module outputs are referenced using the syntax module.<MODULE_NAME>.<OUTPUT_NAME>. Option C is wrong because var. references input variables, not module outputs. Option A is wrong because the .outputs. segment is not part of the reference syntax — Terraform does not use that intermediate key. Option B is wrong because output. is not a valid reference prefix for accessing another module's outputs from the root module.

terraform state pull retrieves the current state from the configured backend (including remote backends like HCP Terraform) and prints it to stdout as raw JSON. This is useful for inspecting state, piping it to tools like jq, or creating a local backup. Option C is wrong: state pull does not perform a diff; it simply retrieves and prints the current state. Option D is wrong: state pull is a read-only operation and does not acquire a lock (state-modifying commands like apply acquire locks). Option A is wrong: state pull writes to stdout, not to a file; if you want to save it, you redirect stdout (e.g., terraform state pull > backup.tfstate).

Option C is correct: with for_each, each resource instance is keyed by the map key ("web", "api", "jobs"). Removing "web" causes Terraform to plan the destruction of only aws_instance.fleet["web"]; the other keyed instances are unaffected because their keys remain stable. Option A is incorrect: this behavior describes the problem with count-based indexing, not for_each. Option D is also a count misconception—index shifting does not apply to for_each. Option B is incorrect: there is no requirement to manually terraform state rm before removing a for_each key; Terraform handles the removal through a normal plan/apply cycle.

Option D is correct. terraform init -upgrade re-resolves provider (and module) version selections to the newest versions allowed by the configuration's constraints, updating .terraform.lock.hcl to record the new selections. Option A is incorrect — terraform providers upgrade is not a real subcommand; terraform providers on its own just reports the provider requirements tree. Option C is incorrect — apply has no -upgrade-providers flag; provider resolution happens during init, not apply. Option B is a real but riskier path — deleting the lock file does force Terraform to re-resolve on the next init, but terraform validate does not perform provider installation or lock-file writing at all, so this sequence wouldn't actually upgrade or re-lock anything by itself.

Option B is correct. terraform state rm deletes a resource's entry from state while leaving the real infrastructure completely untouched, which is exactly 'stop managing this, but don't delete it.' The resource block should also be removed from configuration afterward so a future plan doesn't try to recreate it. Option A is incorrect and dangerous here — terraform destroy -target would delete the actual Redis cluster, not just stop tracking it. Option D is incorrect — -replace destroys and recreates the resource, which is not the goal. Option C is incorrect — terraform state mv only renames or relocates the state entry; the resource would remain fully managed by Terraform under a new address, not released from management.

Option C is correct. A soft-mandatory Sentinel policy failure pauses the run and requires a user with the 'Manage Policy Overrides' permission to explicitly override the failure before the apply step is unlocked. The current operator cannot unblock it themselves due to lacking that permission. Option A is wrong because the run is not discarded—it stays in a paused/needs-override state. Option B is wrong because soft-mandatory failures DO block the run; only advisory failures are non-blocking. Option D is wrong because the apply gating is based on the override permission, not on whether the plan produces changes.

Option B is correct. HCP Terraform's cost estimation feature calculates a projected monthly cost delta—showing the estimated cost before and after the planned changes—for a supported subset of resource types across AWS, Azure, and Google Cloud. Importantly, it is inserted into the run pipeline after the plan but before Sentinel policy checks, allowing policies to act on cost data (e.g., rejecting plans that exceed a cost threshold). Option C is wrong because coverage is not complete for all resource types and does not use real-time billing API queries; it uses static pricing tables. Option A is wrong because cost estimation is prospective (pre-apply), not retrospective. Option D is wrong because cost estimation supports AWS, Azure, and GCP, and does not require any cloud credentials or IAM roles—it works from the plan's resource definitions.

Option C is correct. Advisory enforcement level is purely informational. When an advisory Sentinel policy fails, the failure is recorded and surfaced in the run's policy check section, but it does not gate or pause the run—execution proceeds unimpeded to the apply phase. This level is useful for raising awareness without enforcing hard blockers. Option A is wrong because blocking behavior belongs to soft-mandatory and hard-mandatory levels, not advisory. Option B is wrong because advisory policies never block runs regardless of who is reviewing them. Option D is wrong because HCP Terraform does not have an automatic post-apply rollback mechanism tied to advisory policy violations; Terraform applies are intentionally non-reversible without a separate destroy/re-apply.