TF-004 Use Terraform outside the core workflow — Timed 40 Questions

Question 1

Which TWO of the following are valid use cases for using Terraform Cloud's Sentinel policies? (Choose two.)

Accepted Answer

Enforce that all AWS instances are of a specific type. Sentinel policies can enforce that all AWS instances are of a specific type by using a `validate` rule that checks the `aws_instance` resource's `instance_type` attribute against an allowed list. This is a common compliance use case for Sentinel in Terraform Cloud, where policy-as-code ensures infrastructure adheres to organizational standards before provisioning. Similarly, Sentinel can enforce that all resources have required tags by inspecting the `tags` attribute in the Terraform plan and ensuring specific keys and values are present, which is another common compliance and governance use case.

Answer

Provide cost estimates for infrastructure changes

Answer

Enforce that all Terraform code follows a specific formatting style

Answer

Automatically rotate database passwords

Question 2

Which TWO of the following are true about Terraform Cloud's run lifecycle? (Choose two.)

Accepted Answer

A plan can be discarded without applying. Terraform Cloud allows users to discard a plan without applying it, which is useful when the proposed changes are not desired or need to be revised. This is a standard part of the run lifecycle where a plan can be reviewed and then discarded, preventing any infrastructure changes from being made. Additionally, if auto-apply is disabled for a workspace, every plan requires explicit manual confirmation before the apply phase can proceed, giving users control over when changes are deployed.

Answer

Policy checks can be skipped for emergency changes

Answer

Cost estimation is automatically generated for every run

Answer

A plan that fails due to policy violations can still be applied with admin override

Question 3

Which three of the following are valid ways to use Terraform outside the core provisioning workflow? (Choose three.)

Accepted Answer

Using `terraform plan -out=tfplan` to generate a plan file for later application.. The correct options are `terraform import`, `terraform state push`, `terraform plan -out=tfplan`, and `terraform console`. `terraform import` is a non‑provisioning workflow that maps existing infrastructure into Terraform state without creating or destroying resources. `terraform state push` manually uploads a state file to a remote backend, bypassing the normal `apply` workflow. `terraform plan -out=tfplan` generates a plan file that can be applied later, decoupling the planning phase from the apply phase and thus operating outside the core provisioning loop. `terraform console` is a utility for interactively evaluating expressions in the Terraform language, which is also outside the core provisioning workflow.

Answer

Using `terraform fmt` to automatically rewrite configuration files into a canonical format.

Answer

Using `terraform console` to interactively evaluate expressions in the Terraform language.

Answer

Using `terraform validate` to check configuration syntax before any state operations.

Question 4

Which four of the following are valid ways to integrate Terraform into an automated pipeline or use it outside the core manual workflow? (Choose all that apply.)

Accepted Answer

Running `terraform plan` and `terraform apply` in a CI/CD pipeline using environment variables for backend configuration.. All four correct options represent valid methods for using Terraform outside the core interactive manual workflow. Running `terraform plan` and `terraform apply` in a CI/CD pipeline with environment variables for backend configuration is a standard automation pattern. Terraform Cloud's API-driven run workflow allows programmatic triggering of runs, which is essential for integration with external systems. The `-auto-approve` flag skips the interactive approval prompt, enabling non-interactive execution in scripts. Using `terraform output` in shell scripts is a common way to extract and pass infrastructure data to downstream tools.

Answer

Using `terraform init` with the `-from-module` flag to import existing infrastructure into state without a configuration file.

Answer

Editing the `.tfstate` file directly to modify resource attributes before applying changes in automation.

Question 5

A Terraform practitioner wants to ensure that the access keys used by a provider are not visible in plan output. Which Terraform attribute should be used when defining the provider?

Accepted Answer

sensitive. To prevent sensitive information like access keys from appearing in Terraform plan output, the values should be defined as `sensitive` variables. These variables are then referenced within the provider configuration. The `sensitive` attribute itself is applied to the `variable` block (e.g., `variable "access_key" { sensitive = true }`), not directly to the `provider` block. Therefore, none of the provided options are attributes that can be used directly on a `provider` block for this purpose.

Answer

encrypted

Answer

hidden

Answer

secret

Question 6

A team using a remote S3 backend with DynamoDB locking is experiencing frequent 'Error acquiring the state lock' messages in their CI/CD pipeline. The pipeline runs multiple concurrent jobs for different workspaces. What is the most likely cause and solution?

Accepted Answer

The same workspace is being used for concurrent runs; use separate workspaces per environment.. The error 'Error acquiring the state lock' occurs when Terraform cannot obtain a lock on the state file for a specific workspace. In this scenario, the pipeline runs multiple concurrent jobs for different workspaces, but if the same workspace is inadvertently used across concurrent runs, Terraform's DynamoDB-based locking mechanism will prevent simultaneous access to that workspace's state. The solution is to ensure each environment (e.g., dev, staging, prod) uses a separate workspace, avoiding lock contention. Option B correctly identifies this as the most likely cause and solution.

Answer

The DynamoDB table lacks sufficient read/write capacity; increase it.

Answer

The pipeline is running too many jobs; increase the lock wait time.

Answer

The S3 bucket is not versioned; enable versioning.

Question 7

Which TWO of the following are valid ways to pass variables to Terraform in an automated pipeline?

Accepted Answer

Creating a .tfvars file and referencing it with -var-file.. The `-var-file` flag allows you to pass a `.tfvars` file containing variable definitions, which is ideal for automated pipelines where you want to load multiple variables from a version-controlled or dynamically generated file without manual interaction. This approach supports repeatable, non-interactive deployments. The `-var` flag allows you to specify individual variables directly on the command line, which is also suitable for automation, especially for overriding specific values or passing dynamically generated single variables.

Answer

Using interactive prompts during terraform apply.

Answer

Setting environment variables with prefix TERRAFORM_.

Answer

Using the -vars flag to pass JSON string.

Question 8

A DevOps engineer is troubleshooting a failed 'terraform plan' command. The error message is: 'Error: Error acquiring the state lock' followed by a message that the lock is held by another process. The team uses Terraform Cloud with remote state. Which of the following is the most likely cause and correct resolution?

Accepted Answer

Identify the lock holder via Terraform Cloud UI and use 'terraform force-unlock' to release it.. The state lock in Terraform Cloud is held by another run or process; using the 'force-unlock' command with the correct lock ID from the Terraform Cloud UI can release it. Option A is wrong because state locking is a fundamental and non-disableable feature of Terraform Cloud's remote state management, ensuring state consistency. Option B is wrong because waiting may be indefinite if the lock is stuck. Option C is wrong because you cannot disable locking in Terraform Cloud.

Answer

Disable state locking in the backend configuration.

Answer

Wait for the lock to be released automatically.

Answer

Add the '-lock=false' flag to the plan command.

Question 9

A team uses Terraform workspaces to manage multiple environments (dev, staging, prod). They are currently in the 'dev' workspace and want to run a plan for the 'staging' workspace without switching workspaces. Which command sequence should they use?

Accepted Answer

terraform workspace select staging && terraform plan. The explanation correctly states that 'terraform plan' operates within the currently selected workspace and that 'terraform workspace select staging' is necessary to change the active workspace. This accurately describes the functionality and justifies option C as the intended answer, despite the stem's contradictory phrasing. There is no direct flag on 'terraform plan' to target a different workspace without first selecting it.

Answer

terraform plan -workspace=staging

Answer

terraform plan -var=workspace=staging

Answer

terraform plan -state=staging.tfstate

Question 10

Which TWO Terraform backends support remote state locking?

Accepted Answer

s3. The S3 backend supports remote state locking via DynamoDB. When you configure the S3 backend with a `dynamodb_table` parameter, Terraform uses DynamoDB's conditional writes to acquire and release locks. Similarly, the Consul backend also provides native state locking capabilities, leveraging Consul's key-value store for distributed locks, ensuring that only one user or process can modify the state at a time for both backends.

Answer

local

Answer

inmem

Answer

http

Question 11

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

Accepted Answer

Using 'terraform workspace' commands (new, select, delete). Terraform workspaces can be managed through several methods. The `terraform workspace` command provides native CLI methods—`new`, `select`, and `delete`—to create and manage workspaces directly from the command line. For users of Terraform Cloud or Terraform Enterprise, workspaces can also be created and managed programmatically via the Terraform Cloud API or interactively through the Terraform Cloud web UI. Workspaces allow you to manage multiple state files for the same configuration, enabling isolated environments like dev, staging, and prod without duplicating code.

Answer

Using version control branches

Answer

Using tags in AWS

Question 12

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).. `terraform state replace-provider` is designed to update the provider source address in the state file when a provider is moved from one registry to another, such as from the public Terraform Registry to a private registry. This command rewrites the provider's fully qualified source address (e.g., `registry.terraform.io/hashicorp/aws` to `private.example.com/myorg/aws`) without altering the resource configurations or provider versions.

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 13

A DevOps engineer is responsible for maintaining Terraform configurations that manage resources in AWS. The team uses an S3 backend with DynamoDB state locking. The engineer notices that a recent 'terraform plan' command failed with the following error: 'Error: Failed to get existing workspaces: AccessDenied: Access Denied'. Other team members are able to run plans successfully from their machines. The engineer has verified that they have the correct AWS credentials configured via environment variables and that they can list the contents of the S3 bucket using the AWS CLI. The DynamoDB table exists and the engineer can describe it. What is the most likely cause of this error?

Accepted Answer

The IAM policy used by Terraform does not include 's3:ListBucket' permission on the S3 bucket.. The error 'Failed to get existing workspaces: AccessDenied: Access Denied' is typically caused by a missing `s3:ListBucket` permission, as Terraform needs to list objects (workspaces) within the S3 state bucket. However, the stem explicitly states that the engineer *can* list the S3 bucket contents via CLI using the *same* verified credentials. This makes option B, which claims `s3:ListBucket` is missing, incorrect based on the information provided in the stem. Options A, C, and D are incorrect for the reasons stated in the original explanation (A is for DynamoDB schema, C for syntax affecting all, D for region mismatch affecting all). Given the contradiction, the question as currently written is unanswerable with the provided options.

Answer

The DynamoDB table does not have the correct primary key schema.

Answer

The Terraform configuration has a syntax error in the backend block.

Answer

The DynamoDB table is not in the same region as the S3 bucket.

Question 14

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. Terraform Cloud's CLI-driven run workflow allows users to trigger remote operations from their local CLI.

Option B (Centralized state management with automatic locking) is correct because all remote operations, including CLI-driven ones, leverage Terraform Cloud's centralized state management and automatic locking to prevent concurrent modifications.

Option D (Reduced dependency on local environment variables for provider authentication) is correct because the remote execution environment in Terraform Cloud can be configured with workspace variables for provider authentication, eliminating the need to manage sensitive credentials as local environment variables on the user's machine.

Option A (Integration with version control systems for automatic plan and apply) describes the primary benefit of a VCS-driven workflow, where VCS pushes automatically trigger runs. While Terraform Cloud integrates with VCS, the 'automatic plan and apply' is not a direct benefit of the CLI-driven run workflow itself, which is manually triggered from the CLI.

Option C (Support for multiple cloud providers in a single workspace) is a general feature of Terraform and Terraform Cloud, not specific to CLI-driven remote operations.

Option E (Ability to execute `terraform plan -refresh-only` without a run) is incorrect because a `refresh-only` plan is still a type of run.

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 15

A developer runs `terraform plan` and it fails with a provider plugin error. Which command should they run first to resolve the issue?

Accepted Answer

terraform init. The `terraform init` command is the correct first step because it initializes the working directory, downloads the required provider plugins, and sets up the backend configuration. A provider plugin error typically indicates that the provider plugins are missing, outdated, or not properly installed, and `terraform init` resolves this by fetching the correct versions from the Terraform registry.

Answer

terraform validate

Answer

terraform apply

Answer

terraform fmt

Question 16

A team uses Terraform Cloud for remote state management. They want to ensure that state file changes are only made through the Terraform Cloud API and not through direct access to the storage backend. Which feature should they enable?

Accepted Answer

Remote state locking. Remote state locking ensures that only one operation can modify the Terraform state at a time. When using Terraform Cloud as the remote backend, locking is automatically managed and prevents any direct modifications to the state file outside of a Terraform run. Because Terraform Cloud handles locking through its API, any attempt to directly access the storage backend would fail to acquire a lock, thus preventing changes. This effectively enforces that all state modifications go through the Terraform Cloud API.

Answer

Sentinel policy enforcement

Answer

VCS integration

Answer

Team tokens

Question 17

A company uses Terraform with multiple cloud providers and wants to integrate with their existing CI/CD pipeline. They need to enforce that all infrastructure changes go through code review and automated testing before being applied to production. Which approach best meets these requirements?

Accepted Answer

Configure Terraform Cloud with run triggers and policy checks. Terraform Cloud's run triggers and policy checks (e.g., Sentinel) enforce that all infrastructure changes must pass code review and automated testing before being applied. This integrates directly with the CI/CD pipeline by requiring a pull request to trigger a plan, which is then reviewed and approved via Terraform Cloud's governance controls, ensuring no change reaches production without validation.

Answer

Store state in a remote backend and use terraform apply in the pipeline

Answer

Use the Terraform CLI in the CI/CD pipeline with remote state

Answer

Run terraform apply locally after manual approval

Question 18

An operator runs `terraform apply` and receives an error that the state file is locked. What is the most likely cause?

Accepted Answer

Another user is running a Terraform operation. Terraform uses a state locking mechanism (typically via a backend like S3 with DynamoDB, or Consul) to prevent concurrent operations from corrupting the state file. When another user or process is running a Terraform operation (e.g., `apply`, `plan`, `destroy`), the lock is held, and any subsequent `terraform apply` will fail with a 'state file is locked' error. This is a fundamental safety feature to ensure state consistency.

Answer

The state file is outdated and needs refresh

Answer

The configuration has a syntax error

Answer

The user lacks write permissions to the state file

Question 19

An organization wants to use Terraform to manage infrastructure in multiple environments (dev, staging, prod) with the same configuration but different variable values. Which approach should they use?

Accepted Answer

Use Terraform workspaces and separate variable files. Terraform workspaces allow you to manage multiple distinct sets of infrastructure resources within the same configuration by maintaining separate state files. By combining workspaces with separate variable definition files (e.g., `dev.tfvars`, `prod.tfvars`), you can reuse the same configuration code while applying environment-specific variable values, avoiding duplication and ensuring consistency across environments.

Answer

Create separate directories with duplicated configurations

Answer

Use a single state file with environment variables

Answer

Use different versions of Terraform for each environment

Question 20

A team uses Terraform Cloud with a VCS-backed workflow. They notice that a recent commit triggered a run that failed because of an invalid configuration. The team fixed the configuration and wants to re-run the plan without committing again. Which action should they take?

Accepted Answer

Create a new commit with the fix. In a VCS-backed Terraform Cloud workspace, runs are triggered by commits to the linked repository. When a configuration error is found in the code, fixing it requires a new commit that includes the corrected code. The 'Queue Plan' button re-runs a plan using the same commit, so it cannot incorporate local fixes. Creating a new commit (option B) triggers a new run with the fixed configuration.

Answer

Amend the previous commit and force push

Answer

Use the 'Queue Plan' button in the Terraform Cloud UI

Answer

Run terraform plan locally and apply