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

Question 1

Which THREE of the following are best practices for Terraform state management?

Accepted Answer

Use workspaces to manage different environments.. Terraform workspaces allow you to manage multiple distinct state files for the same configuration, enabling environment separation (e.g., dev, staging, prod) without duplicating code or backends. Each workspace maintains its own state, preventing cross-environment interference and simplifying infrastructure lifecycle management.

Answer

Manually edit state files to fix configuration drift.

Answer

Commit state files to version control.

Question 2

Which TWO are valid methods to import existing infrastructure into Terraform?

Accepted Answer

Run 'terraform import' with the resource address and ID.. `terraform import` is the primary command for bringing existing infrastructure under Terraform management. It requires both the resource address (as defined in your configuration) and the provider-specific ID of the real-world object. This command maps the existing resource into the Terraform state, enabling subsequent `apply` operations to manage it.

Answer

Use 'terraform state rm' to remove existing state before running apply.

Answer

Use 'terraform console' to inspect and import.

Answer

Use 'terraform init -migrate-state' to import from another backend.

Question 3

Refer to the exhibit. A Terraform plan fails with the error shown. What is the most likely cause?

Accepted Answer

Another Terraform run is currently in progress.. The error message indicates that Terraform cannot acquire a state lock. This typically occurs when another Terraform run is already in progress and holds the lock on the state file. Terraform uses a locking mechanism (often via DynamoDB) to prevent concurrent modifications; if a lock is already held, subsequent runs will fail with this error until the lock is released or expires.

Answer

The S3 bucket does not have versioning enabled.

Answer

The DynamoDB table is not configured correctly.

Answer

The state file is corrupted.

Question 4

Refer to the exhibit. A team deploys this configuration. They run 'terraform apply' once and the instance is created. Later, they modify the instance type and run 'terraform apply' again. They notice the provisioner does not run on the second apply. Why?

Accepted Answer

Provisioners run only when the resource is created, not on subsequent updates.. Provisioners in Terraform are designed to run only during resource creation, not during subsequent updates. When the instance type is modified and 'terraform apply' is run again, Terraform updates the existing resource in place without triggering the provisioner again. This behavior is intentional because provisioners are typically used for initial setup tasks like bootstrapping, not for ongoing configuration changes.

Answer

Provisioners run only when the resource is destroyed.

Answer

The provisioner should be 'remote-exec' to run on updates.

Answer

The command syntax is incorrect.

Question 5

A team needs to share a Terraform module across multiple projects within their organization. What is the best practice?

Accepted Answer

Use a remote module source such as a Git repository.. Using a remote module source such as a Git repository is the best practice because it allows the module to be versioned, centrally maintained, and consumed by multiple projects without duplication. Terraform's module system supports sources like Git, Mercurial, and HTTP URLs, enabling teams to pin specific versions via tags or refs, ensuring consistency across environments.

Answer

Copy the module code into each project's directory.

Answer

Use 'terraform state push' to share state.

Answer

Use workspace variables to store module code.

Question 6

A company uses Terraform with a remote backend (AWS S3). They want to ensure that the state file is encrypted at rest. Which configuration approach guarantees this?

Accepted Answer

Configure the S3 backend with server-side encryption enabled (e.g., 'encrypt = true' and 'kms_key_id').. The S3 backend configuration block supports the `encrypt` and `kms_key_id` arguments, which enable server-side encryption (SSE-S3 or SSE-KMS) for the state file stored in the S3 bucket. This ensures that the state file is encrypted at rest, meeting the requirement without any additional steps or external commands.

Answer

Enable encryption in the AWS provider block.

Answer

Use 'terraform state encrypt' command.

Answer

Use 'terraform init -encrypt-state' flag.

Question 7

A company wants to integrate Terraform with their CI/CD pipeline to automatically deploy infrastructure. Which Terraform feature should they use to ensure state files are stored securely and accessible by the pipeline?

Accepted Answer

Terraform Cloud remote state. Terraform Cloud remote state stores the state file in a managed, access-controlled backend that CI/CD pipelines can authenticate to via API tokens, providing secure storage, locking, and versioning. This satisfies the requirement that state be stored securely and be reliably accessible to the pipeline without committing it to source control.

Answer

Terraform import

Answer

Local state with .gitignore

Answer

terraform state push

Question 8

A team is using Terraform Cloud and wants to enforce that all AWS resources created by Terraform have a specific tag. Which feature should they use?

Accepted Answer

Sentinel policies. Sentinel policies are Terraform Cloud's policy-as-code framework that allows teams to enforce mandatory rules on infrastructure configurations before they are applied. By writing a Sentinel policy that checks for the presence and value of a specific tag on all AWS resources, the team can reject any run that does not comply, ensuring consistent tagging across all resources created by Terraform.

Answer

Cost estimation

Answer

Workspace variables

Answer

Run tasks

Question 9

Which Terraform command is used to validate the syntax of configuration files without accessing any cloud provider?

Accepted Answer

terraform validate. `terraform validate` checks syntax and internal consistency of configuration files. `init` initializes backends and providers, `plan` accesses remote state, `fmt` formats code.

Answer

terraform fmt

Answer

terraform plan

Answer

terraform init

Question 10

A team uses an S3 backend with DynamoDB for state locking. They notice that sometimes terraform plan fails because the state is locked. What is the best practice to handle this in an automated pipeline?

Accepted Answer

Serialize pipeline runs to avoid concurrent execution. Serializing pipeline runs is the best practice to prevent concurrent Terraform operations from competing for the same state lock. When multiple pipeline jobs attempt to run `terraform plan` or `terraform apply` simultaneously, DynamoDB-based state locking ensures only one operation holds the lock at a time, causing the others to fail. By enforcing sequential execution (e.g., via CI/CD stage dependencies or a mutex), you avoid lock contention entirely without risking data corruption or bypassing safety mechanisms.

Answer

Use force-unlock before each plan

Answer

Increase the lock timeout

Answer

Use -lock=false in the pipeline

Question 11

A developer wants to see the list of resources currently managed by Terraform in the state file. Which command should they use?

Accepted Answer

terraform state list. `terraform state list` is the dedicated command to list all resources tracked in the Terraform state file. It reads the state directly and outputs the resource addresses (e.g., `aws_instance.web`), giving the developer a clear view of what Terraform currently manages.

Answer

terraform graph

Answer

terraform output

Answer

terraform show

Question 12

A company uses Terraform Cloud and wants to ensure that only approved modules from the private registry are used in configurations. How can they enforce this?

Accepted Answer

Use Sentinel policies to check module sources. Sentinel is HashiCorp's policy-as-code framework that can enforce governance rules on Terraform Cloud runs. By writing a Sentinel policy that inspects the `module` block's `source` attribute, you can restrict configurations to only use modules from the approved private registry, rejecting any run that references external or unapproved sources.

Answer

Restrict module sources in VCS

Answer

Configure workspace variables to limit module paths

Answer

Use run tasks to scan for module types

Question 13

A Terraform configuration uses a module from the public registry. After a provider update, the module's resources fail to create. What is the most probable cause?

Accepted Answer

The module is incompatible with the new provider version. C is correct because modules from the public registry often declare a `required_providers` block with version constraints. When the provider is updated outside those constraints (e.g., from v3.x to v4.x), the module may rely on deprecated attributes or changed resource schemas, causing resource creation to fail. Terraform will not automatically adjust module code to match provider API changes.

Answer

The provider binary is corrupted

Answer

The state file is corrupted

Answer

The backend configuration is incorrect

Question 14

Which TWO of the following are best practices when using Terraform in a CI/CD pipeline? (Choose two.)

Accepted Answer

Use version control for configurations. Option B is correct because storing Terraform configurations in version control (e.g., Git) provides an auditable history, enables peer review via pull requests, and allows the pipeline to trigger on commits, which is fundamental to any CI/CD workflow. Option D is correct because remote state with locking (e.g., an S3 backend with DynamoDB state locking, or Terraform Cloud) prevents concurrent pipeline runs from corrupting the state file and keeps state out of individual machines, which is essential for reliable automated deployments. Option A is not a best practice because automatically applying after plan without a manual approval gate or policy check can push unintended changes to production; a plan should be reviewed before apply. Option C is wrong because committing state to the source repository risks exposing secrets in plaintext and causes conflicts when multiple pipeline runs modify state. Option E is not a CI/CD best practice per se; terraform import is a one-off remediation command for bringing existing resources under management, not a routine pipeline practice.

Answer

Run terraform apply automatically after plan

Answer

Store state in the source repository

Answer

Use terraform import to manage existing resources

Question 15

Which THREE of the following are capabilities of Terraform Cloud's Sentinel policy framework? (Choose three.)

Accepted Answer

Enforce that resources have mandatory tags. Sentinel is a policy-as-code framework embedded in Terraform Cloud that evaluates plan data before apply, so option B is correct because a policy can inspect planned resource attributes and fail the run when required tags (e.g., CostCenter, Environment) are missing. Option C is correct because Sentinel policies can encode organizational security rules—such as requiring encrypted S3 buckets, private subnets, or approved instance types—and reject non-compliant plans. Option D is correct because Sentinel can match on resource type (e.g., aws_instance, azurerm_virtual_machine) and forbid or conditionally allow their creation. Option A is not a Sentinel capability because policies evaluate Terraform configuration/plan data, not wall-clock scheduling; time-based run control would come from CI/CD or API triggers. Option E is not a Sentinel capability because cost estimation in Terraform Cloud is provided by the separate cost estimation feature (run tasks/infracost-style integrations), not by Sentinel policy logic.

Answer

Block Terraform runs based on the time of day

Answer

Estimate the cost of infrastructure changes