Free HashiCorp Terraform Associate 004 Sample Questions

Correct answer: A — Terraform is provider-agnostic, using plugins that let the same core workflow manage resources across many different platforms.

• A. This is correct because Terraform's provider plugin model lets one consistent workflow and language target AWS, Azure, on-premises VMware, and many other platforms at once.
• B. Terraform uses a single core workflow and language across providers; it does not require a separate installation or language per platform, which would defeat the purpose of a unified tool.
• C. Terraform is not limited to public cloud; providers exist for on-premises virtualization platforms like VMware, which is exactly why it fits this multi-environment scenario.
• D. Terraform does not merge providers into one shared API; each provider still exposes its own resources and behavior, while Terraform standardizes how you configure and apply them.

Correct answer: A — Terraform's provider ecosystem lets a single configuration language target AWS, VMware, and other platforms through their respective APIs.

• A. This is correct because Terraform's provider plugins translate the same HashiCorp Configuration Language into calls against each platform's API, letting AWS and VMware resources be managed from one workflow.
• B. This is incorrect because Terraform provisions and manages infrastructure as described in configuration; it does not automatically migrate workloads between platforms.
• C. This is incorrect because on-premises resources are managed through a provider that talks to the platform's existing API or SDK, not through a proprietary agent installed on every server.
• D. This is incorrect because the provider model explicitly extends to on-premises and hybrid platforms such as VMware, not just public cloud vendors.

Correct answer: A — Declare the aws, google, and vsphere providers in the same configuration so each resource block is managed through its matching platform API.

• A. Declaring the aws, google, and vsphere providers together lets one configuration reference resources on all three platforms, with each provider translating its own resource blocks into the right API calls while the team still runs a single plan and apply.
• B. AWS Direct Connect is a network link between AWS and another data center; it does not make Google Cloud or VMware resources addressable through the aws provider, so Terraform still could not manage them without their own providers.
• C. Splitting into three configurations with separate state and manual coordination reintroduces exactly the fragmented, inconsistent process Terraform's multi-provider workflow is meant to remove, and it loses the single review and apply step the team wants.
• D. CloudFormation only manages AWS resources and has no way to provision Google Cloud or VMware infrastructure, so exporting to it would not give the team a single tool covering all three platforms.

Correct answers: A, B, E — Terraform reads the `required_providers` block to determine which provider plugins the configuration needs and downloads them from the resolved source address.; Terraform records the exact installed provider versions and their cryptographic hashes into the `.terraform.lock.hcl` file for future runs.; Terraform caches downloaded provider plugins in a local directory so that later `init` runs in the same environment can skip re-downloading them.

• A. This is correct because provider discovery and installation during `init` starts from the source addresses declared in `required_providers`, which Terraform resolves to locate the matching plugin release.
• B. This is correct because part of `init`'s provider handling is updating the dependency lock file with the specific versions and hashes that were installed, so future runs can reproduce the same install.
• C. This is incorrect because providers are distributed as prebuilt binaries for each platform, not as source code that Terraform compiles; `init` downloads a ready-to-run plugin binary.
• D. This is incorrect because `init` never edits the configuration's `required_providers` version constraints; the constraints are author-controlled, and installed versions are only recorded separately in the lock file.
• E. This is correct because Terraform maintains a local plugin cache so that provider binaries already downloaded for a given platform can be reused instead of being fetched again on subsequent `init` runs.

Correct answers: A, B, E — It records the exact provider version selected together with cryptographic hashes used to verify the downloaded plugin package.; Terraform generates or updates it automatically as part of running `terraform init`, without any separate manual command.; HCP Terraform and Terraform Enterprise runs also honor the provider versions recorded in this file when it is present in the workspace.

• A. This is correct. Each provider entry in the file lists the resolved version plus package hashes, letting Terraform verify that a later download matches what was originally installed.
• B. This is correct. Terraform writes or refreshes this file as a normal part of initialization, with no separate command needed to create or maintain it under ordinary use.
• C. HashiCorp recommends committing this file to version control precisely so collaborators and CI pipelines resolve identical provider versions; ignoring it defeats that reproducibility guarantee.
• D. The lock file only records the outcome of a version resolution; the `required_providers` block still must exist in configuration to declare sources and constraints in the first place.
• E. This is correct. HCP Terraform and Terraform Enterprise runs read this file the same way the CLI does, so remote runs install the same locked provider versions as local ones.
• F. Provider requirements declared by any child module in the configuration are merged into version resolution, so their constraints absolutely can influence which versions end up recorded in the lock file.

Correct answer: A — provider = aws.west

• A. The `provider` meta-argument on a resource takes an unquoted `<PROVIDER_NAME>.<ALIAS>` reference, so `aws.west` correctly points the resource at the aliased configuration.
• B. `alias` is only valid inside a `provider` block to name a configuration; it is not a meta-argument that resources use to select a provider.
• C. The `provider` meta-argument must be an unquoted reference like `aws.west`, not a quoted string; Terraform would treat this as invalid syntax.
• D. `region` is an argument specific to the AWS provider's own configuration, not the meta-argument Terraform uses to bind a resource to a particular provider configuration.

Correct answer: A — `terraform state show aws_db_instance.main` to print the resource's current recorded attribute values from state.

• A. `terraform state show` is built for exactly this: it prints the full set of attribute values recorded in state for one named resource, without changing the state file. It is read-only, matching the engineer's goal.
• B. `terraform state list` only prints resource addresses, one per line, with no attribute detail. It would tell the engineer the resource exists but not show any of its recorded values.
• C. `terraform refresh` updates the state file to match real infrastructure and does not, by itself, print a readable attribute listing for one resource. It also modifies state rather than just displaying it.
• D. `terraform plan -target` shows proposed changes for that resource, not the attribute values currently recorded in state. If there are no pending changes, the plan output would show little of what the engineer wants to inspect.

Correct answer: A — Validation fails with an error because the directory has not been initialized and provider plugins are not yet installed

• A. This is correct: an uninitialized working directory has no downloaded provider plugins or installed modules, and this command needs those to resolve schemas for resource and data blocks. It fails with a clear error pointing at the missing initialization.
• B. This overstates independence from providers: while the command is a local, static check, it still needs installed provider plugins to know each resource type's expected arguments. Without initialization, that schema information is missing.
• C. Silently skipping unconfigured blocks is not the behavior of this command; it does not selectively ignore parts of the configuration. An uninitialized directory produces an explicit error rather than a partial, quiet pass.
• D. This command never attempts to authenticate with a cloud provider, so a missing credential is not the cause of any failure here. The actual failure comes from the missing provider plugins and uninitialized module cache.

Correct answers: A, B, C — `-upgrade`; `-lockfile=readonly`; `-get=false`

• A. This is correct. It causes Terraform to disregard existing lock file selections and install the newest provider and module versions permitted by the configured constraints.
• B. This is correct. It makes Terraform verify installed provider packages against the existing lock file without writing any new selections or checksums to it.
• C. This is correct. It tells Terraform to skip downloading and installing referenced child modules during initialization.
• D. This is incorrect. It controls how long Terraform waits to acquire a state lock during operations that touch state, which is unrelated to installing providers or modules.
• E. This is incorrect. It only suppresses colored output formatting in the terminal and has no effect on what gets downloaded or installed.
• F. This is incorrect. It is a global CLI option that changes the working directory Terraform operates in before any command runs, rather than a flag that changes what init installs.

Correct answer: A — `-replace=ADDRESS` to mark the specific resource instance for forced replacement in the generated plan

• A. This is correct: `-replace` tells Terraform to plan a forced replacement of the named resource instance even when its configuration is unchanged, which is exactly the escape hatch for degraded resources.
• B. `-refresh-only` reconciles state with the real object's current attributes but has no mechanism for forcing a destroy-and-recreate of a resource that matches its configuration.
• C. `-target` only restricts which resources are included in the plan; it does not, by itself, force replacement of a resource whose configuration still matches its current state.
• D. There is no built-in `force_recreate` input variable that providers read to trigger recreation; replacement forcing is a plan-time flag, not a variable convention providers implement.

Correct answer: A — `-` (a single hyphen)

• A. Passing a single hyphen as the target tells `fmt` to read the configuration content from standard input instead of scanning a directory, which matches the documented target syntax.
• B. A dot targets the current directory on disk and causes `fmt` to scan files there; it does not redirect input from stdin.
• C. There is no `--stdin` flag defined for `terraform fmt`; the documented mechanism for piped input is the hyphen target, not a named flag.
• D. Omitting the target entirely makes `fmt` default to scanning the current directory for `.tf` files, not reading from standard input.

Correct answer: A — Remove the `prevent_destroy = true` line from the resource's lifecycle block, apply that configuration change, then run `terraform destroy` or a targeted apply.

• A. This is correct because removing the protective lifecycle line and applying that change is the documented way to lift the guard, after which a normal destroy or targeted apply can remove the resource.
• B. This is incorrect because no such flag exists for overriding this specific protection in one step; the configuration itself has to change before the resource can be destroyed.
• C. This is incorrect because manually editing the state file is unnecessary and risky; once the resource block is removed from configuration, a normal plan and apply reconcile the state without hand-editing it.
• D. This is incorrect because running a plan does not itself change anything, so the protection is still enforced at apply time; the reasoning that a plan-only command is inherently exempt misstates why the workflow succeeds.

Correct answer: A — It records the successfully created resources in the state file and leaves them in place, since Terraform does not automatically roll back a partially completed apply.

• A. Correct. When a provider error interrupts an apply, Terraform records the resources it already created in the state file, releases the state lock, and exits with the error. Terraform has no automatic rollback, so those resources stay in place and the infrastructure may be left partially applied until the operator fixes the problem and runs apply again.
• B. Incorrect. Terraform has no automatic rollback mechanism for a failed apply. Resources that were created successfully stay as they are, and Terraform does not destroy them in reverse dependency order or otherwise restore the pre-apply condition. Removing them requires an explicit action such as `terraform destroy`.
• C. Incorrect. Terraform writes the partial results to state rather than discarding the state file. If it discarded the state, Terraform would lose track of infrastructure that really exists. The next apply would then try to recreate those resources, causing duplicate-resource errors and drift. The next apply actually compares the configuration to the saved state and creates only what is missing.
• D. Incorrect. Terraform does not loop over the already-created resources and retry them until the apply succeeds. Those resources are already created and recorded in state, so there is nothing to retry for them. Some providers retry certain transient API calls internally, but Terraform core does not do this. After a failure, the operator must diagnose the error and re-run `terraform apply`.

Correct answers: A, B, D — Referencing aws_s3_bucket.logs.id inside the policy resource creates an implicit dependency, so Terraform creates the bucket before applying the policy.; Because the reference exists, Terraform automatically includes aws_s3_bucket.logs in the dependency graph for the policy resource, with no separate depends_on argument needed.; Replacing the reference with a hardcoded bucket name string would remove the implicit dependency, so Terraform could no longer guarantee the creation order between the two resources.

• A. The policy resource reads the bucket's id attribute, which only exists once the bucket has been created, so Terraform must order the bucket's creation ahead of the policy. This is a direct example of an implicit dependency inferred from an attribute reference.
• B. Terraform builds its dependency graph by statically analyzing which resources are referenced in each block's arguments, so the bucket is added to the policy's graph node automatically. No depends_on argument is needed because the reference already conveys the relationship.
• C. Whether an argument accepts an id, an arn, or another attribute is defined by the resource schema for that specific argument, not by a general rule about references. Using id here is a valid reference as long as it matches what the bucket argument's schema expects.
• D. A hardcoded string carries no information Terraform can analyze, so removing the reference also removes the graph edge that forced ordering. Terraform would then have no basis for guaranteeing the bucket exists before the policy is applied.
• E. Terraform's plan and apply cycle recalculates the dependency graph and reevaluates affected resources whenever referenced values change, without needing a human to intervene beyond running the normal apply workflow. Attribute references are exactly what drives that automatic reevaluation.
• F. depends_on is meant for dependencies that cannot be expressed through an attribute reference; here the policy resource already references aws_s3_bucket.logs.id directly, so the dependency is already captured without adding depends_on.

Correct answer: A — Terraform accepts both values because an omitted `type` argument defaults to `any`, so no type constraint is enforced.

• A. When a variable block omits the type argument, Terraform treats the constraint as any, so values of differing types can be passed across workspaces without a type-mismatch error at plan time.
• B. Omitting type does not implicitly lock the variable to map; without an explicit constraint there is no type Terraform enforces, so a string value would not be rejected on that basis.
• C. Terraform does not coerce untyped variable values into list form; the any default means whatever type is supplied is accepted as-is, not converted to a specific collection type.
• D. A missing type argument is valid Terraform syntax and does not cause an initialization failure; type is optional on variable blocks, with any as the implicit constraint.

Correct answer: A — map(number)

• A. A map associates each environment name key with its own number value, which directly matches the need to look up an instance count by environment name.
• B. This is incorrect because a list only provides positional, index-based access to numbers and cannot associate each count with an environment name key.
• C. This is incorrect because it hard-codes a single `dev` attribute into the type itself, so the variable could never accept an arbitrary set of environment names like `staging` or `prod`.
• D. This is incorrect because a set only stores unique numeric values with no associated key, so there would be no way to tell which count belongs to which environment.

Correct answers: A, B, F — The trailing ellipsis after name activates grouping mode, which is needed here because the same role value can be produced by more than one iteration.; The resulting value is a map whose keys are the distinct role values, and whose values are lists containing every name that produced that role during iteration.; Replacing srv.role with the ellipsis removed, keeping only name as the value, would raise a duplicate-key error whenever two servers share the same role.

• A. Correct: the trailing ellipsis is exactly the syntax that switches an object-producing for expression into grouping mode, which is required whenever the key expression can repeat across iterations.
• B. Correct: grouping mode produces a map from each distinct key to a list of every value collected under that key during the iteration, matching this expression's structure.
• C. Incorrect: without grouping mode, an object for expression that produces the same key more than once raises a duplicate-key error rather than silently dropping later names.
• D. Incorrect: grouping mode with the trailing ellipsis is used specifically inside curly-brace for expressions that produce maps, not inside square-bracket list expressions.
• E. Incorrect: grouping mode sorts the collected values within each list lexically after grouping, so the order is not guaranteed to match the original iteration order.
• F. Correct: removing the ellipsis turns the expression back into a plain object for expression, and Terraform raises a duplicate-key error whenever two iterations produce the same key, such as the same role.

Correct answer: A — Terraform runs variable validation immediately when the value is assigned, before Terraform generates a plan, so an invalid `image_id` stops the run before any resource is evaluated.

• A. Variable validation executes as soon as the value is known, ahead of plan generation, so a bad `image_id` is rejected before Terraform tries to evaluate any resource that depends on it.
• B. Validation does not wait for the plan to be generated; it runs earlier, so an invalid value never reaches the point where a plan would be produced for review.
• C. Terraform has no rollback mechanism triggered by variable validation, and validation happens far earlier than resource creation, not after resources already exist.
• D. Variable validation applies to every operation that resolves the variable's value, including plan and apply, not only `terraform destroy`, so an invalid `image_id` would block provisioning as well.

Correct answer: A — True

• A. Correct. A data block only queries a provider for information about infrastructure that already exists; Terraform never issues create, update, or delete API calls on its behalf.
• B. Incorrect. Read-only querying is exactly what distinguishes a data block from a resource block, which does create, update, and destroy the object it manages.

Correct answers: A, B, C — Referencing another resource's attribute inside an argument expression, such as `aws_instance.web.id`, which Terraform's graph builder automatically detects.; Adding an explicit `depends_on = [ ... ]` entry that lists the other resource or module, overriding Terraform's automatic inference.; Passing a resource's attribute into a module's input variable, which the module then consumes inside its own resource arguments.

• A. This is correct: an argument expression that reads another resource's exported attribute is the standard mechanism Terraform uses to infer an implicit dependency and add the corresponding graph edge.
• B. This is correct: listing a resource or module in `depends_on` explicitly tells Terraform to add a graph edge for a behavioral dependency that isn't otherwise visible through argument references.
• C. This is correct: when a parent module passes a resource's attribute into a child module's input variable, and that variable is used inside the child module's resource arguments, Terraform's reference tracking still resolves the dependency across the module boundary.
• D. This is incorrect: file layout has no bearing on dependency inference; all files in a module are parsed together, so co-locating two resources in the same file does not, by itself, create any graph edge between them.
• E. This is incorrect: sharing a provider block or alias only determines which plugin instance handles API calls for each resource, and it carries no ordering information that would create a dependency edge.
• F. This is incorrect: Terraform's graph builder analyzes argument expressions, not resource label text, so a shared naming prefix has no effect on dependency inference between two otherwise unrelated resources.

Correct answers: A, C, E — Each Terraform run receives a unique, short-lived IAM credential, so a leaked credential from one run becomes worthless once its lease expires.; Long-lived static credentials no longer need to be distributed to every developer's machine, reducing the number of secrets an attacker could target.; Access can be centrally revoked or re-scoped through Vault's role configuration without rotating credentials on every machine that previously held a static key.

• A. This is a real, documented benefit: dynamic credentials are scoped to a short TTL, so a credential that leaks from a single run has a much smaller window of usefulness than a long-lived static key.
• B. This is incorrect; Vault lease expiry only affects the validity of the credential used to authenticate, not the lifecycle of AWS resources that were already created. Terraform does not tear down infrastructure on lease expiry.
• C. This is a real benefit; centralizing credential issuance in Vault means fewer static secrets are copied onto individual machines, shrinking the set of places an attacker could compromise to obtain access.
• D. This is incorrect; dynamic AWS credentials have nothing to do with where or how Terraform state is stored. Remote state storage and backend access controls remain a separate, still-necessary concern.
• E. This is a real benefit; because access is governed by Vault's role and policy configuration, permissions can be adjusted or revoked centrally without touching every machine that previously held a static credential.
• F. This is incorrect; an AWS provider block is still required to provision AWS resources. The Vault data source only supplies credentials for that provider — it does not provision resources itself.

Correct answer: B — False

• A. This is incorrect: the `version` argument is only evaluated for sources that implement the module registry protocol, so Terraform silently ignores it when the source uses the `git::` prefix.
• B. This is correct: generic Git sources are pinned using a `ref` query parameter appended to the source URL rather than the `version` argument, which only applies to registry-protocol sources.

Correct answers: A, B — version = ">= 1.3.0, < 2.0.0"; version = "~> 1.3"

• A. Correct: an explicit combined range with a floor of 1.3.0 and a ceiling below 2.0.0 admits every 1.x release from 1.3.0 up through the last 1.x version and nothing from the 2.x line.
• B. Correct: with two segments given, the pessimistic operator locks the major number at 1 and lets the minor and patch digits move freely, which admits every release from 1.3.0 through the end of the 1.x line and excludes 2.0.0.
• C. With all three segments given, the pessimistic operator locks the major and minor numbers together at 1.3 and only lets the patch digit increase, so releases like 1.4.0 or 1.9.2 would be excluded even though they fall within the desired range.
• D. This sets only a floor with no ceiling, so it would also admit every 2.x, 3.x, or later release, which the team explicitly wants to exclude.
• E. Combining an exact-equals operator with a separate upper bound is contradictory; equals pins the constraint to a single version, so no range of releases from 1.3.0 upward can actually be satisfied by this string.

Correct answer: A — for_each

• A. Correct. This meta-argument accepts a map or set of strings and creates one module instance per entry, addressable by key such as `module.bucket["prod"]`, matching the scenario's requirement to key instances off named environments rather than list position.
• B. Incorrect. This meta-argument creates instances addressed by numeric index derived from a whole number, which does not preserve the meaningful `dev`/`staging`/`prod` keys the scenario needs to address instances by.
• C. Incorrect. This meta-argument only maps provider configurations into a module instance; it does not control how many instances are created or how they're keyed.
• D. Incorrect. This meta-argument only affects the ordering of operations relative to other resources or modules; it has no role in creating one instance per map entry.

Correct answer: A — Terraform reports an error, because `version` is only valid when `source` points to a module registry, not a local filesystem path.

• A. The `version` argument constrains which release Terraform downloads from a module registry, and it has no meaning for a local path source, so Terraform surfaces an initialization error rather than silently accepting it.
• B. Terraform does not silently discard an invalid argument here; pairing a `version` argument with a local `source` path causes initialization to fail with an explicit error rather than proceeding.
• C. A local filesystem path is never resolved against the registry — the two source types are mutually exclusive, so Terraform cannot substitute a registry module in place of a local one.
• D. Local modules are referenced directly, often via a symlink, rather than downloaded and cached by version number, so no versioned cache directory gets created for a local path.

Correct answers: A, B, C — Shared, centralized state lets every team member see the same up-to-date state without manually passing around a state file.; Built-in state locking prevents two people from running conflicting writes against the same state at the same time.; Sensitive values are kept off contributors' local disks, since state is not persisted locally except on unrecoverable errors.

• A. Centralizing state in a shared backend removes the need to manually copy or email state files around, which is one of the core reasons teams adopt remote state.
• B. Fully-featured remote backends provide a locking API that serializes writes, directly preventing the concurrent-write corruption risk that plain local state files are exposed to.
• C. With a non-local backend, Terraform avoids persisting state to disk except in unrecoverable error cases, which keeps sensitive resource attributes off every contributor's machine.
• D. Canonical formatting of `.tf` files is performed by `terraform fmt`, a separate CLI command that has nothing to do with where state is stored.
• E. Provider plugins are still downloaded and executed locally by the Terraform CLI in the standard workflow; only HCP Terraform's remote execution mode runs providers elsewhere, and that is a separate feature from state storage.
• F. The dependency graph is always built and walked by the Terraform CLI itself; a backend's job is limited to storing state and providing locking, not computing the resource graph.

Correct answer: A — To `state/prod.tfstate`, relative to the directory where Terraform commands are executed

• A. This is correct. The `path` argument in a `local` backend block sets the exact relative location for the primary state file, so Terraform writes and reads state at `state/prod.tfstate`.
• B. The `path` argument governs where the primary state file itself lives, not just the output of a pull command, so the default `terraform.tfstate` name would not be used here.
• C. The local backend stores state alongside the configuration at the given path, not inside the provider plugin cache, which only holds downloaded provider binaries.
• D. Terraform does not cache a separate write location from a prior plan; the `path` argument in the backend block is what determines where state is persisted on every run.

Correct answer: A — Replace the `aws_s3_bucket` resource block with a `removed` block specifying `from = aws_s3_bucket.data` and `lifecycle { destroy = false }`.

• A. This is correct. A `removed` block is a version-controlled configuration construct: it goes through review like any other `.tf` change, and setting `destroy = false` tells Terraform to drop the object from state without issuing a delete call against the real bucket.
• B. Simply deleting the resource block gives Terraform no instruction about intent; by default, Terraform would plan to destroy the bucket to bring real infrastructure back in line with the now-absent configuration, which is the opposite of what's wanted.
• C. `terraform state rm` achieves the state removal without destroying the bucket, but it is an imperative command run once against the backend, not a change captured in configuration that a pull request can review before it takes effect.
• D. A `moved` block declares that two addresses represent the same underlying object; redirecting a real S3 bucket's address to an unrelated `null_resource` type is not a supported use and would not achieve the goal of releasing the bucket from management.

Correct answers: A, B, C — Running `terraform apply` to create, update, or destroy resources according to the current configuration.; Running `terraform destroy` to remove every resource that is currently tracked in the Terraform state file.; Running `terraform refresh` to reconcile the state file with the real infrastructure's current attributes.

• A. Applying changes writes to state as resources are created, updated, or destroyed, so Terraform acquires the lock automatically before this operation begins.
• B. Destroying resources removes their records from state, which is a write operation, so the lock is acquired the same way it is for an apply.
• C. Refreshing updates the state file with the real infrastructure's current attributes, which is a write to state and therefore triggers automatic locking.
• D. Reformatting configuration files only touches `.tf` files on disk and never reads or writes the state file, so no lock is needed.
• E. Validating configuration checks syntax and internal consistency locally without contacting a backend, so there is no state file access that would require a lock.
• F. Listing provider requirements only inspects the configuration's declared providers and does not read or modify the state file, so locking is not involved.

Correct answer: A — Write an `aws_s3_bucket` resource block named `legacy_logs` in the configuration so the import command has a matching address to attach the bucket to.

• A. This is correct. Import needs an existing resource address to attach the object to, so the block must be authored first with a matching type and local name.
• B. This is wrong and destructive; deleting the bucket loses the real object and its data, which defeats the purpose of importing an existing resource.
• C. This is wrong because `init -upgrade` only updates provider plugin versions and never inspects real infrastructure to author configuration blocks.
• D. This is wrong because `terraform.tfvars` supplies values to input variables and has no mechanism for resolving or generating a resource address for import.

Correct answer: A — Review the log file for secrets or sensitive values, redact them, and share the resulting file through a paste service such as a GitHub Gist linked from the issue.

• A. Correct: because TRACE-level logs can be large and may contain sensitive values like credentials, the recommended practice is to redact secrets first and then share the file via a paste service such as a Gist rather than posting it raw.
• B. Incorrect: pasting a large raw log directly into an issue comment is unwieldy for maintainers and risks exposing unredacted sensitive values inline.
• C. Incorrect: omitting the detailed trace log defeats the purpose of capturing it, since the verbose detail is often what helps maintainers diagnose the crash.
• D. Incorrect: private email bypasses the public issue tracker maintainers use for triage, and sending logs unredacted still risks exposing sensitive values.

Correct answers: B, D, F — The command only updates Terraform's internal state bindings and does not call any provider API to modify the real infrastructure object.; Terraform automatically writes a backup of the prior state file before completing the move, and this behavior cannot be disabled.; Running the command with `-dry-run` previews the source-to-destination match without making any changes to the state file.

• A. State locking is enabled by default and works automatically; `-lock=false` is an optional, discouraged way to skip locking, not a requirement for the move to run.
• B. This is accurate: rebinding changes which resource address tracks a given remote object entry in state, but it never calls a provider API to create, modify, or destroy the real infrastructure.
• C. The command operates on a single state's bindings; moving objects between two entirely separate local and remote state files is not something this command performs without additional state-target flags, so this description is not accurate as stated.
• D. This is accurate: like other state-modifying subcommands, every successful move writes a backup of the prior state first, and this safety behavior has no flag to disable it.
• E. This is incorrect; moving a resource into a module address or out of one and back to the root is a documented use case, such as nesting a previously top-level resource under a module path.
• F. This is accurate: this flag reports which existing addresses match the given source pattern without performing the actual rebinding, letting a team confirm scope before committing to the change.

Correct answer: A — CLI-driven workflow

• A. Correct: the CLI-driven workflow lets a developer run familiar `terraform plan` and `apply` commands locally, which HCP Terraform executes remotely while streaming output back to the terminal.
• B. Incorrect: the VCS-driven workflow triggers runs automatically from commits or pull requests in a connected repository, not from a developer typing CLI commands.
• C. Incorrect: the API-driven workflow uploads configuration and triggers runs through direct API calls, typically used for custom tooling rather than the standard `terraform` CLI commands.
• D. Incorrect: no-code provisioning lets users deploy pre-built modules through the HCP Terraform UI without writing or running Terraform commands at all.

Correct answers: A, B, C — Globally, to all existing and future workspaces in the organization; To specific workspaces or Stacks selected individually; To all workspaces and Stacks within a specific project

• A. Global scope is a supported option for an organization-owned variable set: HCP Terraform automatically applies it to every existing and future workspace in the organization.
• B. Applying a set to individually selected workspaces or Stacks is a supported scope, letting teams share variables only with the resources that need them.
• C. A project-owned variable set can be scoped to every workspace and Stack inside that specific project, applying automatically to anything created there.
• D. Variable sets are not scoped to a single state version or run; they persist as configuration attached to workspaces, projects, or the organization, and apply to every subsequent run until removed.
• E. Variable sets are not attached to individual module calls; they operate at the workspace, project, or organization level, and their values flow into the whole configuration rather than a single module block.
• F. Variable sets are not scoped by git branch; scoping is based on workspace, project, or organization membership, regardless of which branch a connected repository is on.

Correct answer: A — Replace the `backend "remote"` block with an equivalent `cloud` block referencing the same organization and workspace, then run `terraform init`; Terraform keeps operating against the same workspace.

• A. This is correct: swapping `backend "remote"` for a `cloud` block that points at the same organization and workspace is the documented upgrade path, and re-running init reconnects to the same workspace with no history loss.
• B. Deleting the workspace throws away run history and forces a manual state re-import, which is unnecessary risk and extra work compared to simply swapping the block type.
• C. Terraform does not support having both a `backend` block and a `cloud` block active at once; the configuration would fail validation rather than synchronizing two workspaces.
• D. Manually exporting and re-uploading state through the UI is unnecessary and risks creating a second, disconnected workspace instead of continuing the existing one.