TF-004 Use Terraform outside the core workflow Practice Test 6 — 15 Questions

Question 1

A company uses Terraform with remote state stored in an S3 bucket. An operator accidentally runs 'terraform destroy' on a production workspace and wants to recover the state before the operation. What is the best course of action?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Restore the state file from the S3 bucket's versioning if enabled.. S3 bucket versioning, when enabled, automatically retains all versions of an object, including overwrites and deletions. By restoring the previous version of the state file (e.g., via the AWS console, CLI, or SDK), the operator can recover the exact state that existed before the 'terraform destroy' command was run, allowing Terraform to resume managing the infrastructure correctly.

Answer

Re-run 'terraform apply' to recreate resources.

Answer

Restore the state file from a DynamoDB backup.

Answer

Use 'terraform state pull' to retrieve the last known state.

Question 2

Which Terraform command is used to bring existing infrastructure that was created outside of Terraform under Terraform management?

Accepted Answer

terraform import. `terraform import` is the dedicated command to bring existing infrastructure that was created outside of Terraform under Terraform management. It maps the real-world resource ID to a Terraform resource address in state, allowing Terraform to track and manage that resource without recreating it.

Answer

terraform state push

Answer

terraform apply

Answer

terraform refresh

Question 3

An organization uses Terraform Cloud with a VCS-backed workspace connected to a GitHub repository. They want to trigger a speculative plan without creating a run (i.e., without costing compute resources or being displayed in the workspace). Which approach is appropriate?

Accepted Answer

Run 'terraform plan' from a local CLI configured with the same workspace and a remote backend.. Running 'terraform plan' from a local CLI configured with the same workspace and a remote backend triggers a speculative plan that is computed on Terraform Cloud but does not create a run record or consume run credits. This allows the user to preview changes without affecting the workspace's run history or incurring costs.

Answer

Push a new commit to the GitHub repository with a 'plan' label.

Answer

Use the 'plan -out' flag with a special path to avoid creating a run.

Answer

Use the Terraform Cloud API to queue a plan with 'auto-apply' disabled.

Question 4

What is the purpose of the 'terraform validate' command?

Accepted Answer

To check syntax and internal consistency of configuration files.. The 'terraform validate' command checks the syntax and internal consistency of Terraform configuration files, ensuring that the code is syntactically valid and that references between resources, data sources, and variables are correctly formed. It does not interact with providers or cloud APIs, so it cannot verify credentials or run tests.

Answer

To check the validity of provider credentials.

Answer

To format Terraform configuration files.

Answer

To run unit tests on Terraform modules.

Question 5

A developer accidentally deleted a resource from the Terraform state file using 'terraform state rm'. The resource still exists in the cloud provider. How can the developer re-import the resource without affecting other resources?

Accepted Answer

Use 'terraform import' with the resource address and ID.. `terraform import` is the designated command to bring an existing cloud resource back under Terraform management without affecting other resources. It requires the resource address (as defined in the configuration) and the provider-specific resource ID, allowing Terraform to write the current state into the state file without modifying the actual infrastructure.

Answer

Re-run 'terraform apply' to recreate the resource.

Answer

Use 'terraform state push' with a previous state backup.

Answer

Run 'terraform refresh' to discover and add the resource.

Question 6

A company uses Terraform with a backend configured to store state in Azure Blob Storage. They want to view the current state of resources without performing a plan or apply. Which command should be used?

Accepted Answer

terraform state list. (terraform state list) is correct because it directly queries the Terraform state file stored in Azure Blob Storage and lists all resources tracked in that state without triggering a plan or apply. This command is part of the 'terraform state' family, designed specifically for inspecting state outside the core workflow, and it requires no infrastructure changes or API calls to cloud providers.

Answer

terraform output

Answer

terraform show

Answer

terraform plan

Question 7

Which TWO Terraform backends support remote state locking?

Accepted Answer

s3. The S3 backend (A) supports remote state locking by using a DynamoDB table to acquire and release a lock, which prevents concurrent Terraform runs from corrupting state; this is configured via the dynamodb_table argument. The Consul backend (C) also supports remote state locking natively, since Consul's key-value store provides a locking mechanism (sessions and acquire/release operations) that Terraform uses to lock the state path. The local backend (B) stores state on the local filesystem and does not provide remote locking, only local file-based locking. The inmem backend (D) keeps state in memory for testing purposes and offers no locking. The http backend (E) is a read-only backend for retrieving state over HTTP and does not support state locking.

Answer

local

Answer

inmem

Answer

http

Question 8

Which THREE are valid methods to create and manage Terraform workspaces?

Accepted Answer

Using 'terraform workspace' commands (new, select, delete). Option C is correct because the Terraform CLI provides the native 'terraform workspace' subcommands — 'terraform workspace new', 'terraform workspace select', and 'terraform workspace delete' — which create, switch between, and remove workspaces within a working directory, storing state per workspace. Option D is correct because Terraform Cloud exposes a REST API that lets you programmatically create, list, and delete workspaces (e.g., via the /organizations/:organization_name/workspaces endpoints), enabling automation and CI/CD integration. Option E is correct because the Terraform Cloud web UI allows users to create and manage workspaces through the graphical interface, including setting variables, VCS connections, and team access. Option A is not a valid Terraform mechanism: version control branches are a general Git practice and are not tied to Terraform workspace state management. Option B is not valid either: AWS tags are metadata applied to cloud resources and have no role in creating or managing Terraform workspaces.

Answer

Using version control branches

Answer

Using tags in AWS

Question 9

Which THREE are valid use cases for the 'terraform state replace-provider' command?

Accepted Answer

Migrating a provider from one registry to another (e.g., from registry.terraform.io to a private registry).. Option A is correct because 'terraform state replace-provider' rewrites the provider source address recorded in the state file, which is exactly what is needed when a provider moves from registry.terraform.io to a private registry. Option D is correct because migrating from a community provider to an official provider is a change of provider source address in state, and this command updates those references without forcing resource re-creation. Option E is correct because changing the provider source from one namespace to another (e.g., hashicorp/aws to mycompany/aws) is precisely the provider address substitution the command performs. Option B is not correct because upgrading a provider to a new major version is done by changing the version constraint and running 'terraform init -upgrade', not by replacing the provider source in state. Option C is not correct because changing a provider's configuration region is a configuration change in the provider block, not a state provider address replacement.

Answer

Upgrading the provider to a new major version.

Answer

Changing the provider's configuration region from us-east-1 to eu-west-1.

Question 10

A company uses Terraform with multiple workspaces (dev, staging, prod) and a remote backend in an S3 bucket with a DynamoDB lock table. The backend configuration is defined in the main.tf with partial configuration. Developers are required to provide the backend configuration via command-line flags during 'terraform init'. One developer accidentally ran 'terraform init' without the required flags on a Monday morning. The init succeeded and created a local state file in the project directory. Over the next few days, other team members made changes to the workspace and pushed updates to the remote state. The developer who ran local init then runs 'terraform plan' and sees a plan that would recreate all resources. They realize their mistake. How can this situation be prevented in the future?

Accepted Answer

Implement a CI/CD pipeline that runs 'terraform init' with the correct backend config and enforces that only pipeline-initiated runs are allowed.. A CI/CD pipeline that runs terraform init with the correct backend configuration and restricts runs to the pipeline prevents developers from accidentally initializing with a local backend, which is the root cause of the drift. By centralizing init and plan/apply in an automated, auditable environment, the remote S3 backend and DynamoDB lock table are always used, and local state files cannot be created. This is the only option that structurally prevents the mistake rather than detecting it after the fact.

Answer

Enable state locking on the local backend to prevent conflicts.

Answer

Add a 'terraform plan -check' step that warns if state is not remote.

Answer

Use 'terraform workspace' commands to switch to the correct workspace before running init.

Question 11

A small startup uses Terraform to manage infrastructure on AWS. They store the state file directly in a Git repository (gitignored but accidentally committed) and have no remote backend. The team has two engineers: Alice and Bob. They both run Terraform from their local machines. Recently, they experienced state conflicts where Alice's apply would succeed but subsequently Bob's apply would fail due to state drift. They want a simple solution without adding too much complexity. What should they do?

Accepted Answer

Configure an S3 backend with DynamoDB locking and have both engineers use the remote state.. Configuring an S3 backend with DynamoDB locking provides a remote state file that both engineers can access, along with state locking to prevent concurrent modifications. This directly solves the state conflicts without adding excessive complexity. Option A (adding .gitignore) does not address the conflict issue since the state is still local and not shared. Option C (coordination via Slack) is unreliable and does not prevent race conditions. Option D (Terraform Cloud) is a valid solution but adds more complexity than the simple S3+DynamoDB setup, which is the recommended approach for small teams.

Answer

Add the state file to .gitignore and stop versioning it.

Answer

Continue with the current setup but ask Alice and Bob to coordinate via Slack before running apply.

Answer

Switch to Terraform Cloud with remote execution for automated locking.

Question 12

Which TWO are benefits of using Terraform Cloud's remote operations with a CLI-driven run workflow?

Accepted Answer

Centralized state management with automatic locking. Option B is correct because Terraform Cloud remote operations store the workspace state centrally on Terraform Cloud's servers rather than on the local machine, and the platform automatically locks state during runs to prevent concurrent modifications and state corruption. Option D is correct because with remote operations the run executes inside Terraform Cloud's disposable environment, where provider credentials and secrets are supplied via workspace variables (environment variables, Terraform variables, or dynamic provider credentials) rather than relying on the practitioner's local shell environment. The unmarked options do not belong: A describes VCS-driven workflows, not the CLI-driven run workflow, which triggers runs from the local CLI via `terraform plan`/`terraform apply`; C is not a benefit specific to remote operations, since a single workspace still maps to one provider configuration and multi-provider support exists regardless of execution mode; and E is false because `terraform plan -refresh-only` is a Terraform CLI command that still requires a run to be initiated and executed, whether locally or remotely.

Answer

Integration with version control systems for automatic plan and apply

Answer

Support for multiple cloud providers in a single workspace

Answer

Ability to execute `terraform plan -refresh-only` without a run

Question 13

A DevOps team manages infrastructure for a large e-commerce platform using Terraform with a remote backend in an S3 bucket with DynamoDB state locking. Recently, a team member ran `terraform apply` from their local machine but the command failed with the error: 'Error acquiring the state lock: ConditionalCheckFailedException: The conditional request failed'. The state file is not locked according to the DynamoDB table. After investigation, the team finds that the DynamoDB table has a TTL attribute enabled on the 'LockID' field, and old lock records are automatically deleted after a few minutes. The team suspects that another engineer's `terraform plan` process from a CI/CD pipeline might have created a lock that was subsequently deleted by TTL before it was released, causing the conflict. Which action should the team take to prevent this issue from recurring?

Accepted Answer

Disable the TTL attribute on the DynamoDB table that stores lock information.. The error occurs because the DynamoDB table has a TTL attribute that automatically deletes lock records before the lock is released. Disabling TTL on the DynamoDB table ensures lock records persist until the lock is intentionally released, preventing false lock conflicts. Option A is incorrect because local state eliminates locking and central management. Option C is incorrect because increasing TTL only delays deletion but does not guarantee the lock won't be deleted during a long-running operation. Option D is incorrect because force-unlock is a manual recovery step, not a preventive measure.

Answer

Switch to using local state files to avoid the locking issue entirely.

Answer

Increase the TTL value to 24 hours to ensure locks are not deleted during normal operations.

Answer

Use `terraform force-unlock` before each `terraform apply` to clear any stale locks.

Question 14

A small startup is using Terraform to deploy AWS resources. They have two separate environments: development and production. Currently, they manage two sets of Terraform configuration files in different directories, each with its own state file stored locally. The CEO wants to reduce duplication and simplify management. The team decides to restructure into a single configuration with workspaces. After implementing workspaces, they run `terraform workspace new dev` and `terraform workspace new prod`, then `terraform apply` in the dev workspace. However, when they switch to prod and run `terraform apply`, the plan shows that Terraform wants to recreate all resources instead of managing the existing production resources. What is the most likely reason for this behavior?

Accepted Answer

The team did not migrate the existing production state into the 'prod' workspace.. When the team restructured into a single configuration with workspaces, they created new empty workspaces (`dev` and `prod`) but did not migrate the existing production state file into the `prod` workspace. Terraform workspaces maintain separate state files, so without importing the existing production state into the `prod` workspace, Terraform has no record of the existing production resources and plans to create them from scratch. The `terraform workspace new` command creates a fresh, empty state for that workspace.

Answer

Workspaces cannot be used for different environments; only for temporary feature branches.

Answer

The Terraform configuration uses the same resource names in both workspaces, causing conflicts.

Answer

The team must configure a remote backend for workspaces to function correctly.

Question 15

Which TWO statements about using Terraform with remote backends are correct?

Accepted Answer

Remote backends store state in a shared location.. Option B is correct because a remote backend (for example, an S3 bucket, Azure Storage Account, GCS bucket, or Terraform Cloud workspace) stores the Terraform state file in a shared, remote location rather than on the local machine, allowing teams to collaborate on the same infrastructure. Option E is correct because most remote backends support state locking — such as S3 with a DynamoDB table, Azure Blob Storage, or Consul — which prevents concurrent runs from corrupting the state file. Option A is incorrect because migrating state to a remote backend is typically handled automatically by running `terraform init` with the new backend configuration, which offers to copy existing local state; manual migration is not a requirement. Option C is incorrect because storing state in the local filesystem describes the default local backend, not a remote backend. Option D is incorrect because Terraform Cloud itself is a supported remote backend (configured via the `cloud` block or `remote` backend), so remote backends can absolutely be used with it.

Answer

Remote backends require manual state migration.

Answer

Remote backends store state in the local filesystem.

Answer

Remote backends cannot be used with Terraform Cloud.