Courseiva

HashiCorp Terraform Associate TF-003 (TF-003) — Questions 1–75

519 questions total · 7pages · All types, answers revealed

Take a mock examExam hub

Page 1 of 7

Page 2
1
MCQmedium

A team uses Terraform with the `azurerm` backend. A junior engineer accidentally deletes the state file from the storage container. The team has a backup from 2 hours ago in a different container. What is the correct procedure to recover from this state loss?

A.Restore the backup state file to the original location, then run `terraform plan` to check for any drift
B.Re-run `terraform init` and then `terraform refresh` without restoring
C.Delete all resources manually and re-import them using `terraform import`
D.Create a new empty state and use `terraform apply` to recreate everything
AnswerA

This restores the known good state and allows verification.

Why this answer

Restoring the backup and reapplying should recover. Option A is correct. Option B would recreate all resources but may cause downtime.

Option C is risky. Option D is too destructive.

Full explanation →
2
MCQeasy

A company wants to manage both on-premises and cloud infrastructure with a single tool. Which feature of Terraform makes this possible?

A.Provider plugins
B.State files
C.Provisioners
D.Workspaces
AnswerA

Provider plugins interface with different APIs, allowing Terraform to manage diverse infrastructure.

Why this answer

Terraform's provider plugin architecture allows it to manage resources across different platforms by using provider plugins that interface with each platform's API.

Full explanation →
3
MCQhard

After running `terraform state mv` to rename a resource, the resource's state binding is lost and the resource cannot be managed. Which command should be run to restore the state binding?

A.terraform state push
B.terraform state show
C.terraform state rm
D.terraform import
E.terraform import
AnswerE

Importing the specific resource re-establishes its state binding.

Why this answer

If a resource's state is missing after a state operation, `terraform import` can re-import the resource into state. The other commands do not restore state binding.

Full explanation →
4
MCQhard

A team uses Terraform with remote state in an S3 backend and DynamoDB for state locking. A user runs 'terraform apply' and receives the error: 'Error acquiring the state lock'. The lock info shows a lock ID and caller. What is the best immediate course of action?

A.Check if another Terraform process is running; if not, use 'terraform force-unlock' with the lock ID.
B.Delete the state file from S3 and re-run apply.
C.Manually delete the DynamoDB lock table item.
D.Wait for 15 minutes and re-run apply.
AnswerA

Force-unlock should only be used if the lock is orphaned, after verifying no other process is using it.

Why this answer

Option A is correct because the error indicates a state lock is held, typically by another Terraform process or a stale lock. The best immediate course is to verify no other process is running (e.g., via 'ps' or task manager), then use 'terraform force-unlock -lock-id=<LOCK_ID>' to release the lock. This is the safe, documented procedure that preserves the state file and DynamoDB lock table integrity.

Exam trap

HashiCorp often tests the misconception that deleting the state file or DynamoDB item is a valid fix, but the trap here is that candidates confuse state file management with lock management, leading them to choose destructive actions instead of the proper unlock command.

How to eliminate wrong answers

Option B is wrong because deleting the state file from S3 destroys all tracked infrastructure state, causing Terraform to lose track of resources and potentially attempt to recreate everything, leading to duplication or errors. Option C is wrong because manually deleting the DynamoDB lock table item bypasses Terraform's lock consistency checks and can corrupt the lock state, leaving the lock ID in an inconsistent state. Option D is wrong because waiting 15 minutes does not address the root cause; if the lock is stale, it will persist indefinitely, and if another process is running, it may still hold the lock after waiting.

Full explanation →
5
MCQeasy

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

A.Use a remote module source such as a Git repository.
B.Copy the module code into each project's directory.
C.Use 'terraform state push' to share state.
D.Use workspace variables to store module code.
AnswerA

Remote modules are reusable and version-controlled.

Why this answer

Option C is correct because using a remote source like a Git repository allows easy sharing and versioning. Option A leads to duplication. Option B is not a standard sharing method.

Option D is for variables, not modules.

Full explanation →
6
MCQeasy

A team is using a shared backend for Terraform state. After running terraform apply, the state file is locked for an extended period, causing other team members to fail with 'Error acquiring the state lock'. What is the most likely cause?

A.A previous terraform apply command was interrupted or crashed, leaving a stale lock.
B.Another team member is actively running terraform apply on the same state.
C.The backend configuration was changed without running terraform init.
D.The state file contains resources that no longer exist in the cloud provider.
AnswerA

A broken lock file causes the lock to persist indefinitely.

Why this answer

Option A is correct because Terraform uses a locking mechanism (typically via DynamoDB for AWS S3 backends) to prevent concurrent state modifications. If a `terraform apply` is interrupted or crashes, the lock may not be released, leaving a stale lock entry. This causes subsequent operations to fail with 'Error acquiring the state lock' until the lock is manually removed or expires (if TTL is configured).

Exam trap

HashiCorp often tests the distinction between a legitimate lock held by another user (Option B) and a stale lock from a crashed process (Option A), where candidates mistakenly think any lock error means someone else is actively working.

How to eliminate wrong answers

Option B is wrong because if another team member is actively running `terraform apply`, the lock is legitimate and not 'stale' — the error message is expected behavior, not a misconfiguration or bug. Option C is wrong because changing the backend configuration without `terraform init` would cause a backend initialization error, not a state lock error; the lock mechanism is backend-specific and would not be triggered by a config mismatch. Option D is wrong because resources that no longer exist in the cloud provider cause drift or refresh errors during `terraform plan` or `apply`, but do not affect the state locking mechanism, which operates at the backend level independently of resource state.

Full explanation →
7
Multi-Selecthard

Which two statements accurately describe the difference between declarative and imperative IaC approaches? (Choose two.)

Select 2 answers
A.Imperative is only used for scripting, not IaC
B.Declarative tools are always faster than imperative tools
C.Declarative focuses on the desired outcome, while imperative specifies step-by-step commands
D.Imperative can lead to configuration drift because steps may cause unintended states
E.Declarative eliminates the need for idempotency
AnswersC, D

This is the fundamental difference.

Why this answer

Option C is correct because declarative IaC, as used in Terraform with HCL, allows you to define the desired end state of infrastructure (e.g., 'I want an AWS EC2 instance with AMI ami-0c55b159cbfafe1f0 and instance type t2.micro'), and the tool automatically determines the necessary steps to achieve that state. In contrast, imperative IaC, such as using AWS CLI commands or Ansible playbooks with explicit 'command' modules, requires you to specify each step (e.g., 'run aws ec2 run-instances, then wait, then tag'). This fundamental difference in approach is a core concept in the TF-003 exam.

Exam trap

HashiCorp often tests the misconception that declarative IaC eliminates the need for idempotency, but in reality, declarative tools enforce idempotency through state management and plan generation, making it a key feature rather than an omission.

Full explanation →
8
MCQeasy

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

A.To check the validity of provider credentials.
B.To format Terraform configuration files.
C.To check syntax and internal consistency of configuration files.
D.To run unit tests on Terraform modules.
AnswerC

'terraform validate' performs these checks.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between 'validate' (syntax/consistency check) and 'plan' (which actually contacts providers and checks real-world state), leading candidates to mistakenly think 'validate' verifies credentials or remote resources.

How to eliminate wrong answers

Option A is wrong because 'terraform validate' does not check provider credentials; credential validation occurs during 'terraform init' or 'terraform plan' when the provider attempts to authenticate with the cloud API. Option B is wrong because formatting Terraform files is the purpose of 'terraform fmt', not 'validate'. Option D is wrong because 'terraform validate' does not execute unit tests; testing modules is done with external tools like Terratest or the 'terraform test' command (introduced in later versions), not with 'validate'.

Full explanation →
9
MCQhard

A Terraform configuration includes a module from the Terraform Registry. After running `terraform init`, the module is downloaded. However, a subsequent `terraform plan` fails with an error that a required provider is not installed, even though it is declared in the module. What is the most likely cause?

A.The module uses a different Terraform version
B.The provider version constraint is incompatible
C.The `required_providers` block is not declared in the root module
D.The module source URL is incorrect
AnswerC

Terraform may not install providers only declared in modules; root should also declare them.

Why this answer

Option C is correct because in Terraform, the `required_providers` block must be declared in the root module to ensure all providers are installed during `terraform init`. When a module from the Registry declares a provider but the root module does not, `terraform init` may not automatically install that provider, leading to a 'required provider not installed' error during `terraform plan`. The root module acts as the top-level configuration that aggregates all provider requirements.

Exam trap

HashiCorp often tests the misconception that provider declarations in child modules are automatically inherited by the root module, leading candidates to overlook the necessity of a root-level `required_providers` block.

How to eliminate wrong answers

Option A is wrong because a Terraform version mismatch would typically cause a different error (e.g., 'Unsupported Terraform version') during `terraform init` or `plan`, not a missing provider error. Option B is wrong because an incompatible provider version constraint would produce a version conflict error (e.g., 'no available releases match the given constraints'), not a 'not installed' error. Option D is wrong because an incorrect module source URL would cause a download failure during `terraform init`, not a provider installation issue after the module is successfully downloaded.

Full explanation →
10
Matchingmedium

Match each Terraform command to its primary function.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Initialize a working directory with provider plugins

Create an execution plan

Execute the actions proposed in a plan

Destroy previously-created infrastructure

Check configuration for syntax and internal consistency

Why these pairings

These are core Terraform CLI commands and their purposes.

Full explanation →
11
MCQmedium

Refer to the exhibit. An operator runs terraform plan and gets the following output. They have not modified the Terraform configuration since the last successful apply. What is the most likely cause of the planned changes?

A.Terraform provider was updated to a new version.
B.The instance was terminated and recreated.
C.Terraform state was corrupted.
D.The instance was modified manually via the AWS console.
AnswerD

Manual changes outside Terraform cause drift, leading to these proposed updates.

Why this answer

The plan shows changes to the AMI and instance type, which are attributes that were not changed in the configuration. This indicates drift caused by manual modifications outside Terraform. Option A is correct because manual changes via the console cause Terraform to detect differences and propose corrections.

Full explanation →
12
Multi-Selecthard

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

Select 3 answers
A.Block Terraform runs based on the time of day
B.Enforce that resources have mandatory tags
C.Check that resources comply with security best practices
D.Restrict the creation of certain resource types
E.Estimate the cost of infrastructure changes
AnswersB, C, D

Sentinel can validate resource attributes.

Why this answer

Sentinel can enforce tags, restrict resource types, and check compliance. Cost estimation is a separate feature. Time-based blocking is not a built-in Sentinel capability.

Full explanation →
13
MCQhard

A user runs 'terraform plan' and gets an error: 'No state file was found!'. Which is the most likely cause?

A.The backend configuration changed after the last apply.
B.The state file was manually edited in S3.
C.Another user ran 'terraform apply' concurrently.
D.The workspace does not exist.
AnswerD

If the workspace is new or deleted, no state file exists.

Why this answer

Option C is correct because the absence of a state file indicates the workspace does not exist or is empty. Option A would cause corruption, not absence. Option B would cause a backend mismatch.

Option D would cause a lock conflict.

Full explanation →
14
MCQmedium

An operator wants to pass output values from one Terraform configuration to another as input variables. Which approach is recommended?

A.Hardcode the output values in a variables file for the second configuration.
B.Store outputs in a shared file and use 'file()' function to read them.
C.Use a remote state data source to read the outputs from the first configuration's state.
D.Use environment variables to pass the output values.
AnswerC

Data sources allow reading outputs from remote state.

Why this answer

Option C is correct because Terraform's remote state data source (e.g., `terraform_remote_state`) allows one configuration to securely read output values from another configuration's state file stored in a shared backend (like S3, Azure Storage, or Consul). This avoids duplication, manual errors, and ensures that the second configuration always uses the latest outputs from the first, without requiring direct file access or environment variables.

Exam trap

The trap here is that candidates often choose Option B (shared file with `file()`) because it seems simple and familiar, but they overlook that Terraform's `file()` function reads a static file at plan time and does not integrate with state management, leading to stale or inconsistent values across runs.

How to eliminate wrong answers

Option A is wrong because hardcoding output values in a variables file creates a manual, error-prone process that breaks automation and requires updates whenever the first configuration changes. Option B is wrong because using `file()` to read outputs from a shared file introduces a dependency on a static file path, lacks state locking, and does not automatically reflect changes in the first configuration's state; it also bypasses Terraform's native state management. Option D is wrong because environment variables are ephemeral, not tied to Terraform state, and require external orchestration to set them correctly, making them unsuitable for reliable, repeatable infrastructure-as-code workflows.

Full explanation →
15
MCQhard

An organization uses Terraform with the AzureRM backend. The team recently split a large configuration into multiple smaller configurations, each with its own state file. They want to share outputs from one configuration (networking) as inputs to another (compute). Which approach should they use to reference the networking state from the compute configuration without duplicating data?

A.Define output values in the networking configuration and they will be automatically available in the compute configuration.
B.Run 'terraform output' on the networking state and save the values to a JSON file, then use 'terraform_remote_state' to read them.
C.Use a 'data' 'terraform_remote_state' block in the compute configuration to read the networking state.
D.Hardcode the subnet IDs from the networking configuration into the compute configuration.
AnswerC

This data source retrieves the outputs from the specified remote state, enabling cross-configuration references.

Why this answer

Option C is correct because the `terraform_remote_state` data source allows one Terraform configuration to read the root-level output values from another configuration's state file stored in the AzureRM backend. This enables sharing of networking outputs (e.g., subnet IDs) into the compute configuration without duplicating data or manually exporting values. The data source retrieves the state directly from the configured backend, ensuring the compute configuration always uses the latest networking outputs.

Exam trap

HashiCorp often tests the misconception that `terraform output` or automatic sharing between configurations is sufficient, but the correct approach is always to use the `terraform_remote_state` data source to read outputs from a separate state file.

How to eliminate wrong answers

Option A is wrong because Terraform does not automatically share outputs between separate configurations; each configuration has its own state file and outputs must be explicitly referenced. Option B is wrong because while `terraform output` can produce a JSON file, the `terraform_remote_state` data source reads the state file directly from the backend, not from a local JSON file; saving to a JSON file introduces manual steps and risks stale data. Option D is wrong because hardcoding subnet IDs violates the principle of infrastructure as code, creates duplication, and requires manual updates whenever networking changes.

Full explanation →
16
MCQhard

You have two modules that create resources in different providers. Module A creates a VPC in AWS, Module B creates a Kubernetes cluster that requires the VPC ID. You want to ensure Module B runs after Module A but avoid hardcoding the VPC ID. Which approach is most appropriate?

A.Use a data source in Module B to look up the VPC.
B.Output the VPC ID from Module A and pass it as input to Module B.
C.Use terraform graph to order modules.
D.Use module dependency via depends_on in the root module.
AnswerB

This creates both a data dependency and an ordering requirement, ensuring Module B receives the correct VPC ID.

Why this answer

Option B is correct because using outputs from Module A and passing them as inputs to Module B establishes both ordering and data flow. Option A (depends_on) ensures ordering but does not pass data. Option C (data source) would require the VPC to already exist.

Option D (terraform graph) only visualizes, not enforces.

Full explanation →
17
Multi-Selecthard

Which THREE of the following are necessary steps to configure OIDC (OpenID Connect) for authenticating Terraform in a CI/CD pipeline?

Select 3 answers
A.Generate a long-lived API token and store it as a secret.
B.Set up an OIDC provider in the target cloud (e.g., AWS IAM OIDC provider).
C.Configure remote backend with static credentials.
D.Add a provider block with assume_role and web_identity_token attributes in Terraform configuration.
E.Create an IAM role in the cloud that the CI job can assume.
AnswersB, D, E

Trust must be established between cloud and CI.

Why this answer

Option B is correct because to authenticate Terraform in a CI/CD pipeline using OIDC, you must first establish trust between the CI platform and the cloud provider by creating an OIDC identity provider (e.g., an AWS IAM OIDC provider). This provider validates the JSON Web Token (JWT) issued by the CI platform (e.g., GitHub Actions, GitLab CI) and maps it to an IAM role, enabling token-based authentication without long-lived secrets.

Exam trap

HashiCorp often tests the misconception that OIDC requires storing a long-lived token (Option A) or that the remote backend must use static credentials (Option C), when in fact OIDC replaces both with a trust-based, token-exchange mechanism that uses the `assume_role` and `web_identity_token` attributes.

Full explanation →
18
Multi-Selectmedium

Which of the following accurately describe core purposes and benefits of using Terraform in a cloud infrastructure environment? Choose all that apply. (There are four correct answers.)

Select 4 answers
.Enables infrastructure as code by allowing users to define resources in declarative configuration files.
.Automates the provisioning and lifecycle management of infrastructure across multiple cloud providers.
.Provides a built-in drift detection mechanism that automatically reverts unauthorized manual changes to infrastructure.
.Supports state management to track the current state of infrastructure and plan changes incrementally.
.Generates real-time billing and cost optimization recommendations for deployed resources.
.Facilitates collaboration through remote state backends and version-controlled configuration files.

Why this answer

Terraform's core purpose is to enable Infrastructure as Code (IaC) by allowing users to define cloud resources in declarative HCL (HashiCorp Configuration Language) files. It automates provisioning and lifecycle management across multiple providers (AWS, Azure, GCP, etc.) using a single workflow. State management is fundamental: Terraform maintains a state file to track real-world resources, enabling incremental planning and safe updates.

Collaboration is facilitated by storing state remotely (e.g., in S3, Terraform Cloud) and using version control for configuration files, ensuring team consistency and auditability.

Exam trap

HashiCorp often tests the misconception that Terraform automatically reverts drift or provides cost optimization, when in fact drift detection is read-only and cost management is outside Terraform's scope.

Full explanation →
19
MCQmedium

You have a list of VPC configurations and want to create multiple VPCs using a single module block with for_each. Which statement is true?

A.for_each on a module is not supported.
B.You can use for_each on a module block only if the module is published in the registry.
C.When using for_each, the module's outputs will be a map of output values for each instance.
D.for_each on a module block requires the module to support count.
AnswerC

Each instance's outputs are collected into a map with keys matching the for_each keys.

Why this answer

Option C is correct. When using for_each on a module block, the module's outputs become a map of output values keyed by the for_each keys. Option A is false; for_each works with any module.

Option B is false; for_each does not require count support. Option D is false; for_each is supported on module blocks since Terraform 0.13.

Full explanation →
20
MCQeasy

Refer to the exhibit. What is the purpose of this output block?

A.To store the public IP in a local file.
B.To set the public IP as a variable for use in other configurations.
C.To create a DNS record with the public IP.
D.To display the public IP address of the instance after apply.
AnswerD

Outputs are meant to show values after apply.

Why this answer

Correct A: Output blocks display values to the user after apply. They do not set variables, create records, or store files by default.

Full explanation →
21
MCQhard

An organization stores their Terraform modules in a private Git repository. They need to reference a module that resides in a subdirectory called 'modules/rds' within the repository 'infra-modules' on the main branch. Which source argument should be used?

A.source = "git::https://github.com/org/infra-modules.git//modules/rds"
B.source = "git::https://github.com/org/infra-modules.git"
C.source = "git::https://github.com/org/infra-modules.git:modules/rds"
D.source = "git::https://github.com/org/infra-modules.git//rds"
AnswerA

Correct format: double-slash // separates repository URL from subdirectory path.

Why this answer

The generic Git source format with a double-slash (//) to specify a subdirectory is correct. Option A is wrong because it uses a single slash and would reference the root of the repository. Option C is wrong because the subdirectory path should come after // not before.

Option D is wrong because it uses an incorrect format with a colon before the //.

Full explanation →
22
Multi-Selecteasy

Which TWO statements about Terraform data sources are correct?

Select 2 answers
A.Data sources can be used in count and for_each.
B.Data sources can fetch information from external systems.
C.Data sources are only available after applying the configuration.
D.Data sources are used to create new infrastructure.
E.Data sources cannot be used inside modules.
AnswersA, B

Data sources can be used in metap arguments like count and for_each.

Why this answer

B is correct because data sources fetch external info. D is correct because they can be used with count/for_each. A is false (they read, not create), C is false (they are read during plan), E is false (they can be used in modules).

Full explanation →
23
MCQeasy

What is the primary purpose of Terraform's state file?

A.Provide a GUI
B.Execute scripts
C.Map configurations to real-world resources
D.Store secrets
AnswerC

State is the source of truth for existing infrastructure.

Why this answer

The state file maps Terraform configurations to real-world resources, allowing Terraform to track resource metadata and detect drift.

Full explanation →
24
MCQeasy

A developer is new to Terraform and wants to understand the core workflow. Which sequence of commands correctly represents the basic Terraform workflow?

A.terraform init, terraform apply
B.terraform plan, terraform init, terraform apply
C.terraform init, terraform plan, terraform apply
D.terraform validate, terraform plan, terraform destroy
AnswerC

Correct order: init initializes the backend and provider plugins, plan creates an execution plan, and apply executes the plan.

Why this answer

Option C is correct because the basic Terraform workflow follows a strict three-step sequence: `terraform init` to initialize the working directory and download required providers/modules, `terraform plan` to preview the changes Terraform will make against the current state, and `terraform apply` to execute the planned changes. Skipping `init` or `plan` would either fail due to missing providers or apply changes without a reviewable execution plan, violating the standard workflow.

Exam trap

HashiCorp often tests the misconception that `terraform plan` is optional or that `terraform init` can be skipped if providers are already cached, but the exam requires strict adherence to the documented workflow sequence.

How to eliminate wrong answers

Option A is wrong because it omits `terraform plan`, which is essential for reviewing proposed infrastructure changes before applying them; running `terraform apply` without a plan can lead to unintended modifications. Option B is wrong because it places `terraform plan` before `terraform init`, but `init` must run first to download providers and set up the backend; without `init`, `plan` will fail with a 'no provider' error. Option D is wrong because it includes `terraform destroy` instead of `terraform apply`, and `destroy` is a separate workflow for tearing down infrastructure, not part of the basic creation/update workflow; additionally, `validate` is optional and not a core step.

Full explanation →
25
Multi-Selecteasy

Which two are benefits of using Infrastructure as Code? (Choose two.)

Select 2 answers
A.Guaranteed cost optimization
B.Removes need for cloud providers
C.Reproducible environments
D.Automated documentation
E.Elimination of all manual errors
AnswersC, D

IaC allows exact replication of infrastructure.

Why this answer

A (Reproducible environments) and C (Automated documentation) are key benefits. B is false because manual errors are reduced but not eliminated. D is false because cost optimization is not a direct benefit of IaC.

E is false because IaC still requires cloud providers.

Full explanation →
26
MCQhard

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?

A.Disable state locking in the backend configuration.
B.Wait for the lock to be released automatically.
C.Add the '-lock=false' flag to the plan command.
D.Identify the lock holder via Terraform Cloud UI and use 'terraform force-unlock' to release it.
AnswerD

The lock ID is available in the UI, and force-unlock can release it.

Why this answer

Option D is correct because 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 there is no such option on the apply command. 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.

Full explanation →
27
MCQhard

An organization manages multiple environments (dev, staging, prod) using Terraform. They want to minimize code duplication while allowing environment-specific variable values. Which approach best achieves this goal?

A.Use a separate Git branch for each environment, each with its own Terraform configuration.
B.Write a single Terraform configuration that uses count and conditional expressions to create resources based on environment variable.
C.Use Terraform workspaces with a single configuration and define all variable values in one .tfvars file.
D.Organize the repository with a shared modules directory and separate subdirectories for each environment that call the same modules with environment-specific .tfvars files.
AnswerD

This structure maximizes reuse and keeps environment-specific variables separate.

Why this answer

Option D is correct because it leverages Terraform's module system to define reusable infrastructure components in a shared directory, while each environment (dev, staging, prod) has its own subdirectory with a root configuration that calls those modules and passes environment-specific `.tfvars` files. This minimizes code duplication by keeping the module logic in one place, and allows per-environment variable values without mixing concerns. It follows the recommended pattern for multi-environment management in Terraform, avoiding the pitfalls of branches, workspaces, or conditional logic that can lead to complexity or state corruption.

Exam trap

HashiCorp often tests the misconception that Terraform workspaces are the correct way to manage multiple long-lived environments, but workspaces are actually designed for short-lived or temporary infrastructure, not for permanent dev/staging/prod separation, because they share the same backend configuration and can lead to accidental state corruption if not carefully isolated.

How to eliminate wrong answers

Option A is wrong because using separate Git branches for each environment leads to configuration drift, merge conflicts, and makes it difficult to promote changes consistently across environments; Terraform state is not designed to be managed across branches. Option B is wrong because using `count` and conditional expressions within a single configuration to create resources based on an environment variable results in a monolithic state file, making it hard to apply changes to one environment without affecting others, and it violates the principle of separating environments for safety and isolation. Option C is wrong because Terraform workspaces share the same configuration and backend, but defining all variable values in one `.tfvars` file forces all workspaces to use the same variable file, which defeats the purpose of environment-specific values; workspaces are better suited for temporary or testing scenarios, not for managing distinct environments like dev, staging, and prod with different variable sets.

Full explanation →
28
MCQhard

A company uses Terraform to manage multi-cloud infrastructure. They have separate Terraform configurations for AWS and Azure, each with its own state file. They want to share a common set of networking variables (e.g., allowed IP ranges) between these configurations without duplicating data. Which approach best achieves this?

A.Create a module that contains the variable definitions and reference it in both configurations.
B.Define the variables in a 'terraform.tfvars' file and copy it to each configuration directory.
C.Store the variables in a JSON file and use the 'jsondecode' function in each configuration.
D.Use a remote state data source to read the outputs from a dedicated 'globals' workspace.
AnswerD

This allows sharing outputs from a single source of truth without duplication.

Why this answer

Option D is correct because using a remote state data source allows you to read outputs from a dedicated 'globals' Terraform workspace that stores shared networking variables. This approach avoids data duplication and ensures that both AWS and Azure configurations can dynamically consume the same canonical set of values without manual copying or file sharing. It leverages Terraform's native remote state mechanism to securely and consistently share data across separate configurations.

Exam trap

HashiCorp often tests the misconception that modules or variable files can share actual runtime data between separate configurations, when in fact they only define structure or require manual distribution, whereas remote state data sources provide dynamic, centralized sharing without duplication.

How to eliminate wrong answers

Option A is wrong because creating a module with variable definitions only provides a reusable template for declaring variables; it does not share actual values between configurations, so each configuration would still need to supply its own data. Option B is wrong because copying a 'terraform.tfvars' file to each configuration directory duplicates the data, violating the requirement to avoid duplication and introducing drift risk. Option C is wrong because storing variables in a JSON file and using 'jsondecode' still requires the file to be present in each configuration's working directory, leading to duplication and synchronization challenges.

Full explanation →
29
MCQmedium

What is the most likely cause of this error?

A.The module requires a version constraint.
B.The module source path does not exist.
C.The required_version is incompatible with the module.
D.The module input variable 'vpc_id' is not defined in the module.
AnswerB

Correct: the module directory './modules/networking' is missing.

Why this answer

Option C is correct because the error message indicates the module directory does not exist. Option A is incorrect because a version constraint is not relevant for local paths. Option B is incorrect because the required_version is satisfied.

Option D is incorrect because the error is about module sourcing, not variable definition.

Full explanation →
30
MCQeasy

Refer to the exhibit. A developer runs `terraform init` and then `terraform plan`. The plan output shows that Terraform will create the AWS instance. However, the state file is expected to be stored in S3 under the key "prod/terraform.tfstate". Which statement is true?

A.The state will be stored locally because the S3 backend configuration is invalid
B.The state will be stored in S3 in the us-west-2 region because the provider overrides the backend region
C.The state will be stored in S3 in the us-east-1 region, and the EC2 instance will be created in us-west-2
D.The `terraform plan` will fail because the S3 bucket is not created yet
AnswerC

Correct! Backend region is separate from provider region.

Why this answer

Option C is correct because the backend configuration specifies the S3 bucket and key 'prod/terraform.tfstate' for state storage, and the AWS provider region (us-west-2) is independent of the backend region. The backend block does not include a 'region' argument, so Terraform defaults to us-east-1 for state storage, while the EC2 instance is created in the provider's configured region (us-west-2).

Exam trap

HashiCorp often tests the misconception that the provider region automatically applies to the backend, leading candidates to incorrectly assume the backend uses the provider's region instead of the default us-east-1.

How to eliminate wrong answers

Option A is wrong because the S3 backend configuration is valid; the backend block specifies bucket and key, and Terraform will use the default region (us-east-1) if no region is explicitly set in the backend. Option B is wrong because the provider region does not override the backend region; the backend region is determined by the backend configuration or defaults to us-east-1, not the provider's region. Option D is wrong because `terraform plan` does not fail if the S3 bucket does not exist; the plan runs locally and only attempts to access the backend during `terraform apply` or `terraform init` (if partial configuration is used), but `terraform plan` can proceed with a local state if the backend is unreachable.

Full explanation →
31
Multi-Selecthard

Which THREE of the following are valid ways to reference a module output value within the same Terraform configuration?

Select 3 answers
A.In the count or for_each of another module or resource.
B.In a resource argument, e.g., subnet_id = module.vpc.public_subnet_ids
C.In a data source definition as a filter.
D.In a provider block to set endpoints.
E.In a locals block to perform transformations.
AnswersA, B, E

Module outputs can control the number of instances or the iteration set of other resources.

Why this answer

Options A, B, and D are correct. A: Direct reference in resource arguments. B: Use in count or for_each arguments of resources.

D: Use in locals block for complex expressions. C is wrong because module outputs aren't used in provider configurations. E is wrong because data sources are for external data, not module outputs.

Full explanation →
32
Multi-Selectmedium

Which TWO of the following are valid steps in the core Terraform workflow?

Select 2 answers
A.Run terraform import to bring existing resources under management
B.Run terraform init to initialize the working directory and download providers
C.Run terraform output to retrieve output values
D.Run terraform apply to create or update infrastructure
E.Run terraform destroy to remove resources
AnswersB, D

Init is the first step to set up the environment.

Why this answer

Option B is correct because `terraform init` is the first step in the core Terraform workflow, which initializes the working directory, downloads the required provider plugins, and sets up the backend configuration. Without this step, subsequent commands like `terraform plan` or `terraform apply` cannot function, as the providers and state backend are not yet configured.

Exam trap

HashiCorp often tests the distinction between the core workflow (init, plan, apply) and auxiliary commands (import, output, destroy, state), so candidates mistakenly select commands that are commonly used but not part of the three-step core workflow.

Full explanation →
33
MCQmedium

A user wants to import an existing AWS EC2 instance into Terraform state so it can be managed. After writing the resource block matching the instance, what is the correct next step?

A.Run 'terraform import' with the resource address and ID of the instance.
B.Run 'terraform plan' to see if the import is necessary.
C.Run 'terraform refresh' to sync state with the existing resource.
D.Run 'terraform apply' directly; Terraform will detect the existing resource and import it.
AnswerA

Import brings the existing resource into Terraform state so it can be managed.

Why this answer

After writing the resource block that matches the existing EC2 instance, the correct next step is to run 'terraform import' with the resource address and the instance ID. This command maps the real-world infrastructure to the Terraform state, allowing Terraform to manage the resource without destroying or recreating it. Without this explicit import, Terraform has no knowledge of the existing instance in its state file.

Exam trap

HashiCorp often tests the misconception that 'terraform apply' or 'terraform refresh' can automatically discover and import existing resources, when in fact only 'terraform import' explicitly maps external resources into state.

How to eliminate wrong answers

Option B is wrong because 'terraform plan' compares the current state with the configuration, but if the resource is not yet in state, it will show that the resource needs to be created, not that an import is needed. Option C is wrong because 'terraform refresh' updates the state with real-world attributes for resources already in state, but it cannot import a resource that is not yet tracked in state. Option D is wrong because 'terraform apply' will attempt to create a new resource from scratch, not detect and import an existing one; Terraform has no built-in auto-discovery or import-on-apply behavior.

Full explanation →
34
MCQhard

A Terraform configuration uses a for_each expression to create multiple subnets. After applying, one subnet's configuration needs to be modified. The engineer updates the resource block's map key for that subnet. What will terraform plan show?

A.No changes because the subnet configuration is the same.
B.Only deletion of the old subnet.
C.An in-place update to the subnet.
D.Destruction of the existing subnet and creation of a new one.
AnswerD

The map key is part of the resource address; changing it causes destroy+create.

Why this answer

Option D is correct: changing the map key results in destruction of the old subnet and creation of a new one because for_each uses keys as resource addresses. Option A is wrong because the key change is not an in-place update. Option B is wrong because it only shows deletion, not creation.

Option C is wrong because it suggests no changes.

Full explanation →
35
Multi-Selectmedium

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

Select 3 answers
A.Manually edit state files to fix configuration drift.
B.Commit state files to version control.
C.Use workspaces to manage different environments.
D.Store state file in a remote backend with locking enabled.
E.Use 'terraform state rm' to remove resources from state when needed.
AnswersC, D, E

Workspaces isolate state for environments.

Why this answer

Options A, C, and E are correct. A ensures state is shared and locked. C enables environment separation.

E allows removing resources from state for import or drift correction. B is wrong because state files contain sensitive data and should not be in VCS. D is wrong because manual editing is error-prone.

Full explanation →
36
MCQhard

A company has a monolithic Terraform configuration that manages all of its AWS infrastructure. They want to break it into smaller, manageable configurations without causing downtime or resource duplication. Which approach best follows the core Terraform workflow?

A.Create separate configurations from scratch and manually recreate all resources by running `terraform apply`
B.Use `terraform state mv` to move resources from the monolithic state to new state files for the smaller configurations
C.Import all existing resources into the new configurations before removing the old configuration
D.Delete the monolithic state and apply all new configurations at once
AnswerB

Correct! This allows incremental migration without resource recreation.

Why this answer

Option B is correct because `terraform state mv` allows you to move resources from the monolithic state file into separate state files for the new, smaller configurations without destroying or recreating resources. This adheres to the core Terraform workflow by preserving the existing infrastructure state, avoiding downtime, and preventing resource duplication. The command updates the state mapping so that Terraform continues to manage the same real-world resources under the new configuration structure.

Exam trap

HashiCorp often tests the misconception that you must destroy and recreate resources to reorganize configurations, when in fact Terraform's state manipulation commands allow safe refactoring without impacting live infrastructure.

How to eliminate wrong answers

Option A is wrong because creating configurations from scratch and running `terraform apply` would attempt to create duplicate resources, causing conflicts or requiring manual deletion of existing resources, which risks downtime and violates the principle of state-driven management. Option C is wrong because importing existing resources into new configurations before removing the old configuration would result in duplicate state entries for the same resources, leading to Terraform attempting to manage them twice and potentially causing errors or resource duplication. Option D is wrong because deleting the monolithic state breaks Terraform's tracking of existing resources; applying new configurations would then try to create new resources, ignoring the existing ones, which can cause downtime or resource conflicts.

Full explanation →
37
Multi-Selectmedium

Which THREE actions should be taken when migrating Terraform state from local to a remote backend?

Select 3 answers
A.Remove the local state file before running terraform init.
B.Run terraform init to initialize the backend and migrate state.
C.Manually import all existing resources into the remote state.
D.Confirm migration by typing 'yes' when prompted.
E.Add a backend block to the configuration.
AnswersB, D, E

This command handles the migration.

Why this answer

Option B is correct because `terraform init` is the command that initializes the backend configuration and, when a backend block is added to the configuration, automatically prompts to migrate the existing local state file to the new remote backend. This command handles the state migration seamlessly without requiring manual intervention, ensuring the state file is copied and the backend is configured correctly.

Exam trap

HashiCorp often tests the misconception that you must manually delete or move the local state file before initializing a remote backend, when in fact `terraform init` handles the migration automatically and safely.

Full explanation →
38
Multi-Selecteasy

Which TWO of the following are valid ways to reference a value from a Terraform configuration?

Select 2 answers
A.var.environment
B.local.example.value
C.module.example.arn
D.provider.aws.region
E.aws_instance.example.id
AnswersA, E

Correct syntax for variable.

Why this answer

Option A is correct because `var.environment` is the standard syntax to reference an input variable defined in a Terraform configuration. Input variables are declared with a `variable` block and accessed using the `var.` prefix, making this a valid reference within any Terraform configuration file.

Exam trap

HashiCorp often tests the distinction between valid reference namespaces (var, local, module, data) and invalid ones (provider, resource attributes without proper syntax), trapping candidates who confuse provider configuration with data sources or resource references.

Full explanation →
39
MCQmedium

A company uses Terraform Cloud and wants to enforce policy checks before any apply. They have a set of Sentinel policies. Where should they configure these policies to run automatically on all runs?

A.In the terraform apply command with -policy flag.
B.Configure a webhook in the VCS to run policy checks.
C.Create a Policy Set in Terraform Cloud and attach to workspaces.
D.Deploy a Terraform Enterprise instance with custom policy.
AnswerC

Policy Sets run before apply.

Why this answer

Option B is correct because Policy Sets in Terraform Cloud are managed at organization or workspace level. Option A is wrong because sentinel apply is not a command. Option C is wrong because Terraform Enterprise is on-prem, not cloud.

Option D is wrong because VCS integration is for triggering runs, not policies.

Full explanation →
40
MCQmedium

A team uses Terraform to manage multiple AWS EC2 instances with a 'count' meta-argument. They need to reference the ID of the third instance in another resource's configuration. Which expression should they use?

A.aws_instance.example[1].id
B.aws_instance.example[2].id
C.element(aws_instance.example.*.id, 3)
D.aws_instance.example[3].id
AnswerB

Index 2 is the third instance (zero-based).

Why this answer

Option D is correct because indices are zero-based, so 'aws_instance.example[2]' refers to the third instance. Option A (index 3) is the fourth. Option B (index 1) is the second.

Option C uses 'element' with index 3, also the fourth.

Full explanation →
41
MCQhard

A large organization uses Terraform to manage infrastructure across multiple AWS accounts. They have a shared module for VPC stored in a private Git repository (git::https://github.com/org/terraform-aws-vpc.git?ref=v1.0.0). After updating the module source to ref=v1.2.0, they run terraform init and then terraform plan. The plan still shows the old module's resources and behavior. They confirm the new tag exists and the module code has changed. The root module source line is correct. What is the most likely cause?

A.They forgot to run terraform get.
B.The module source URL is incorrect.
C.Terraform cached the previous module version and did not download the new one.
D.The module's outputs changed and they need to update the root module.
AnswerC

Terraform caches modules; running terraform init with -upgrade or clearing the .terraform directory forces a fresh download.

Why this answer

Option C is correct. Terraform caches modules locally; after changing the source ref, terraform init must be run to download the new version. If the user forgot to include the -upgrade flag or did not clean the cache, Terraform may use the cached version.

Option A is not a standard command. Option B would cause an error. Option D (output changes) would not cause the plan to show old behavior if the module code is new.

Full explanation →
42
Drag & Dropmedium

Drag and drop the steps to destroy infrastructure managed by Terraform in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

Destroy plan previews removal; destroy command with confirmation tears down infrastructure.

Full explanation →
43
Multi-Selecthard

Which TWO statements are correct about Terraform state when using the S3 backend with DynamoDB for state locking?

Select 2 answers
A.The DynamoDB table must exist before running terraform init
B.The S3 bucket should be versioned to provide consistency checks and recovery options
C.State can be stored without specifying a key in the backend configuration
D.State is encrypted at rest by default using SSE
E.State locking prevents any read operations on the state file
AnswersB, D

Versioning is recommended for state integrity and recovery.

Why this answer

The S3 backend by default uses server-side encryption (SSE) for state at rest, and enabling bucket versioning provides consistency and recovery. The DynamoDB table must be created manually before use.

Full explanation →
44
MCQhard

Refer to the exhibit. A user encounters this error while running 'terraform plan'. What is the best course of action?

A.Run 'terraform force-unlock' with the lock ID after verifying no other process holds the lock
B.Change the backend to local and run plan again
C.Delete the state file and run terraform init
D.Wait for 5 minutes and retry
AnswerA

Force-unlock releases the stale lock if no other process is using it.

Why this answer

The lock appears to be stale (operation type invalid). After verifying that no other process is using Terraform, force-unlock is the appropriate action. Deleting state is dangerous.

Waiting might work but is not best practice. Changing backend could cause state mismatch.

Full explanation →
45
Multi-Selectmedium

Which TWO module source types support version constraints in Terraform?

Select 2 answers
A.HTTP URL to a zip archive
B.Terraform Public Registry
C.Local file path
D.Git URL with a branch reference
E.Terraform Cloud Private Registry
AnswersB, E

The public registry allows version constraints like >= 1.0.0, ~> 2.0.

Why this answer

Only module registries (public and private) support version constraints. Local paths, Git URLs with branches, and HTTP URLs do not support version constraints because they point directly to a specific version. Option C and D and E are wrong for not supporting version constraints.

Full explanation →
46
MCQhard

You are managing a Terraform configuration for a multi-tier application that includes AWS EC2 instances, an RDS database, and an Application Load Balancer. The configuration uses multiple modules and remote state stored in an S3 bucket with DynamoDB locking. Recently, a colleague made changes to the configuration and applied them successfully. However, you now need to make additional changes and, when you run 'terraform plan', you receive an error: "Error: Error acquiring the state lock". The error message indicates that the lock is held by a different user. You have confirmed that your colleague is not currently running Terraform. What is the most appropriate course of action to proceed with your changes?

A.Edit the state file to remove the lock metadata.
B.Run 'terraform init -reconfigure' to reset the backend and release the lock.
C.Delete the lock file from the S3 bucket manually.
D.Run 'terraform force-unlock <lock_id>' to remove the stale lock.
AnswerD

This is the proper Terraform command to release a lock.

Why this answer

Option D is correct because Terraform uses DynamoDB for state locking to prevent concurrent modifications. When a lock becomes stale (e.g., due to a crash or network interruption), `terraform force-unlock <lock_id>` is the proper command to manually release it. This preserves the integrity of the state file and avoids manual S3 or DynamoDB edits, which could corrupt the state or break the locking mechanism.

Exam trap

HashiCorp often tests the misconception that manual S3 or DynamoDB manipulation is acceptable, when in fact Terraform provides a safe, built-in command (`force-unlock`) to handle stale locks without risking state corruption.

How to eliminate wrong answers

Option A is wrong because editing the state file directly to remove lock metadata is unsafe; it can corrupt the state and bypass Terraform's consistency checks. Option B is wrong because `terraform init -reconfigure` reinitializes the backend configuration but does not release an existing lock; it may even fail if the lock is still present. Option C is wrong because deleting the lock file from the S3 bucket manually does not remove the DynamoDB lock entry, so the lock remains active and the error persists.

Full explanation →
47
Multi-Selecthard

Which THREE are considered Terraform's best practices?

Select 3 answers
A.Use variables to parameterize configurations
B.Use latest version of all modules
C.Store state securely
D.Use remote state locking
E.Use provisioners for all software installs
AnswersA, C, D

Variables allow reuse and flexibility across environments.

Why this answer

Storing state securely, using variables for parameterization, and enabling remote state locking are key best practices.

Full explanation →
48
MCQmedium

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?

A.Create separate directories with duplicated configurations
B.Use Terraform workspaces and separate variable files
C.Use a single state file with environment variables
D.Use different versions of Terraform for each environment
AnswerB

Reuses configuration with isolated state and variables.

Why this answer

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.

Exam trap

HashiCorp often tests the misconception that workspaces are the only way to manage multiple environments, but the trap here is that candidates may overlook the need for separate variable files alongside workspaces, or incorrectly think that a single state file with environment variables is sufficient for isolation.

How to eliminate wrong answers

Option A is wrong because creating separate directories with duplicated configurations violates the DRY (Don't Repeat Yourself) principle, leading to configuration drift and increased maintenance overhead. Option C is wrong because using a single state file with environment variables would cause all environments to share the same state, resulting in conflicts and potential corruption when applying changes concurrently. Option D is wrong because using different versions of Terraform for each environment introduces unnecessary complexity and version incompatibility risks, and Terraform version does not solve the need for separate state or variable isolation.

Full explanation →
49
Multi-Selecthard

Which TWO of the following are valid methods to acquire a state lock in Terraform Cloud?

Select 2 answers
A.Automatic lock when a run is queued
B.Using a DynamoDB table configured in the backend block
C.Setting `lock=true` in the configuration file
D.Manual force-unlock via API or UI
E.Using a Consul session
AnswersA, D

Terraform Cloud automatically locks state for runs.

Why this answer

Terraform Cloud provides built-in locking. Options A and C are correct.

Full explanation →
50
MCQhard

A DevOps team manages Terraform configurations for a multi-environment infrastructure (dev, staging, prod). They maintain a central repository of reusable modules stored in a Git repository. Developers often update modules in the master branch to add features or fix bugs. Recently, after a developer updated the 'vpc' module in the master branch, the staging environment's infrastructure was destroyed and recreated during a terraform apply, causing an outage. The team needs to prevent such unintended changes across environments. They currently reference modules using the source argument with a git URL pointing to the master branch: source = "git::https://github.com/org/terraform-modules//vpc?ref=master". The team is looking for a solution that allows controlled updates and ensures each environment uses a fixed version of a module until explicitly upgraded.

A.Use module version constraints in the configuration, such as source = "git::https://github.com/org/terraform-modules//vpc?ref=v1.0.0" and update the ref tag when ready.
B.Create separate Git branches for each environment and reference the branch in the module source.
C.Use Terragrunt to manage module dependencies and lock versions.
D.Use the Terraform Registry to host modules with semantic versioning and pin versions.
AnswerA

Correct: pinning to a specific tag ensures each environment uses a fixed version until explicitly updated.

Why this answer

Option D is correct because pinning to a specific Git tag ensures that each environment uses a known, fixed version of the module until the tag is updated. Option A is incorrect because using separate branches still exposes environments to changes in those branches. Option B is incorrect because setting up a registry is a larger undertaking and not an immediate fix.

Option C is incorrect because Terragrunt is an external tool that adds complexity without directly solving the version pinning issue in a native Terraform way.

Full explanation →
51
Multi-Selectmedium

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

Select 3 answers
A.Using version control branches
B.Using tags in AWS
C.Using 'terraform workspace' commands (new, select, delete)
D.Using the Terraform Cloud API
E.Using the Terraform Cloud web UI
AnswersC, D, E

CLI commands directly manage workspaces.

Why this answer

Options A, B, and C are correct. The CLI commands provide direct workspace management. The Terraform Cloud UI allows managing workspaces via GUI.

The Terraform Cloud API allows programmatic management. Option D is wrong because version control branches do not directly manage workspaces. Option E is wrong because tags are not used for workspace management.

Full explanation →
52
MCQmedium

A company is managing multiple cloud environments (dev, test, prod) using Terraform. They want to ensure consistent configurations across environments while allowing environment-specific values. Which IaC practice best supports this?

A.Using data sources only
B.Hardcoding values
C.Duplicating configuration files
D.Using variables and workspaces
AnswerD

Variables allow customization, and workspaces isolate state for each environment, maintaining consistency.

Why this answer

Using variables and workspaces (C) allows parameterization and separation of environments without duplicating code. Duplicating configuration (A) leads to drift. Data sources (B) fetch data but don't manage environments.

Hardcoding (D) is inflexible.

Full explanation →
53
MCQhard

An organization uses Terraform with AWS S3 backend and DynamoDB for state locking. During a plan, you receive an error: 'Error acquiring the state lock'. The lock information in DynamoDB shows a lock from a previous session that crashed. What is the most appropriate next step?

A.Run terraform unlock
B.Run terraform force-unlock with the lock ID
C.Wait for the lock to expire automatically
D.Delete the lock item from DynamoDB table directly
AnswerB

This command releases the lock from the previous session.

Why this answer

The correct answer is B because when a Terraform process crashes while holding a state lock, the lock remains in DynamoDB and must be manually released. The `terraform force-unlock` command with the specific lock ID is the designed mechanism to override a stale lock, as it directly interacts with the DynamoDB locking table to remove the lock item. This is the safest and most appropriate method, as it ensures the lock is released in a controlled manner without risking state corruption.

Exam trap

HashiCorp often tests the distinction between `terraform unlock` (a non-existent command) and `terraform force-unlock` (the actual command), trapping candidates who assume a generic 'unlock' verb exists without knowing the exact syntax.

How to eliminate wrong answers

Option A is wrong because `terraform unlock` is not a valid Terraform command; the correct command is `terraform force-unlock`. Option C is wrong because DynamoDB state locks do not have a built-in automatic expiration or TTL; they persist indefinitely until explicitly removed, so waiting is ineffective. Option D is wrong because manually deleting the lock item from the DynamoDB table bypasses Terraform's safety checks and could lead to state corruption or concurrent access issues if another process is actively using the lock.

Full explanation →
54
MCQmedium

Your company manages infrastructure for multiple environments (dev, staging, prod) using Terraform. You have a shared networking module stored in a private Git repository. The module is used by several root configurations. The current workflow requires developers to manually update the module version in each root module's source attribute when a new version is tagged. This has led to configuration drift and occasional use of incompatible module versions. You want to implement a more reliable approach that ensures all environments use the same consistent version of the module, while still allowing controlled upgrades. Which approach best addresses this concern?

A.Publish the module to the public Terraform Registry and use a version constraint in each root module.
B.Pin each root module to a specific Git tag (e.g., ref=v1.2.3) and manually update each root module when a new tag is created.
C.Remove the version constraint from the module source so that Terraform always fetches the latest commit from the default branch.
D.Use a version constraint like "~> 1.2" in the module source and adopt a workflow to update the constraint across all root modules simultaneously only when ready.
AnswerD

This allows controlled updates: patch updates are automatic, but major/minor updates require explicit version constraint changes across all environments.

Why this answer

Option D is correct because it uses a version constraint (e.g., `~> 1.2`) to allow automatic patch-level updates while preventing major or minor breaking changes, and it enforces a coordinated workflow where all root modules update the constraint simultaneously. This eliminates configuration drift and ensures consistent module versions across environments, while still enabling controlled upgrades. The approach leverages Terraform's built-in version constraint syntax to balance consistency with flexibility.

Exam trap

HashiCorp often tests the misconception that removing version constraints or using the latest commit is a valid way to ensure consistency, but the trap here is that this actually introduces unpredictability and breaks controlled upgrades, which is the opposite of what the scenario requires.

How to eliminate wrong answers

Option A is wrong because publishing to the public Terraform Registry is not required for version control; it also introduces security and compliance risks by exposing private infrastructure code publicly. Option B is wrong because pinning each root module to a specific Git tag and manually updating each one does not solve the drift problem—it perpetuates the same manual, error-prone process described in the scenario. Option C is wrong because removing the version constraint and always fetching the latest commit from the default branch eliminates all control over upgrades, leading to unpredictable breaking changes and no ability to coordinate updates across environments.

Full explanation →
55
Multi-Selecteasy

Which TWO statements accurately describe the `terraform plan` command? (Select TWO.)

Select 2 answers
A.It can be used to destroy infrastructure if the `-destroy` flag is set
B.It applies changes to infrastructure
C.It requires no configuration files in the directory
D.It automatically refreshes the state before creating the plan
E.It can output a plan to a file using the `-out` option
AnswersD, E

By default, `terraform plan` refreshes state (unless `-refresh=false`).

Why this answer

`terraform plan` creates an execution plan and can optionally save it to a file. It does not apply changes; it only shows what will happen. It supports refresh option.

Full explanation →
56
MCQmedium

An organization uses Terraform Cloud for remote state management. A user runs `terraform apply` locally but receives an error that the state is locked. What is the most likely cause?

A.The Terraform configuration has a syntax error.
B.The user does not have access to the remote state backend.
C.Another user or process is currently running a Terraform operation that modifies the same state.
D.The remote backend is temporarily unavailable.
AnswerC

State locking prevents concurrent writes.

Why this answer

Option C is correct because Terraform Cloud uses a state locking mechanism to prevent concurrent modifications that could corrupt the state file. When a user runs `terraform apply` locally, the command first attempts to acquire a lock on the remote state. If another user or process (e.g., a Terraform Cloud run, a CI/CD pipeline, or another local apply) is already holding that lock, the new operation will fail with a 'state is locked' error.

This is a fundamental safety feature to ensure state consistency.

Exam trap

The trap here is that candidates often confuse a 'state locked' error with a 'backend unavailable' error (Option D) or an 'access denied' error (Option B), but Cisco specifically tests the understanding that a lock error is a concurrency control mechanism, not a connectivity or permission issue.

How to eliminate wrong answers

Option A is wrong because a syntax error in the Terraform configuration would cause a validation failure during `terraform plan` or `terraform apply`, not a state lock error; the lock error is a backend-level issue, not a configuration-level one. Option B is wrong because if the user lacked access to the remote state backend, the error would typically be an authentication or authorization failure (e.g., 'AccessDenied' or '403 Forbidden'), not a state lock message; the lock error implies the user can reach the backend but the state is already locked. Option D is wrong because if the remote backend were temporarily unavailable, the error would be a network or timeout error (e.g., 'RequestError' or 'unable to reach the backend'), not a specific 'state is locked' message; the lock error indicates the backend is reachable and actively reporting a lock.

Full explanation →
57
MCQhard

A team is migrating from local state to an S3 remote backend. They have existing state files in the working directory. After configuring the backend block and running `terraform init`, what is the correct next step to migrate the existing state?

A.Execute `terraform init` and confirm yes when prompted to copy existing state
B.Run `terraform state push` to upload the local state
C.Delete the local state file and run `terraform apply` to recreate
D.Manually copy the state file to S3 using AWS CLI
AnswerA

Terraform detects the backend change and offers to copy state during init.

Why this answer

When migrating from local to remote state, Terraform automatically prompts to copy state during `terraform init` if the backend block changes. Option C correctly identifies this.

Full explanation →
58
MCQhard

A module block references a module with version constraint '>= 2.0, < 3.0'. An older version 1.5 is already cached from a previous init. The team wants to ensure they use a newer version. After running terraform init -upgrade, what happens?

A.Terraform upgrades to version 3.0 because it is the latest.
B.Terraform returns an error because version 1.5 is incompatible with the constraint.
C.Terraform uses the cached version 1.5 because it is already present.
D.Terraform upgrades to the latest version in the range 2.x that is not yet cached.
AnswerD

The -upgrade flag forces Terraform to download the newest version matching the constraint.

Why this answer

Option B is correct because terraform init -upgrade re-checks the source and uses the latest version matching the constraint. Option A is wrong because it ignores the cache if -upgrade is used. Option C is wrong because it will upgrade within constraint.

Option D is wrong because no error occurs.

Full explanation →
59
MCQeasy

A team uses Terraform to manage infrastructure. They have multiple configuration directories for different environments (dev, staging, prod). They want to reuse common modules across environments. Which approach aligns with the core Terraform workflow best practices?

A.Use a single configuration with separate state files and variable files for each environment
B.Use workspaces with state stored in a local backend
C.Copy the configuration into each environment directory and modify as needed
D.Create separate Terraform configurations for each environment with hardcoded values
AnswerA

This is the recommended approach for environment isolation.

Why this answer

Option A is correct because it follows the core Terraform workflow of separating configuration from state and using variable files to manage environment-specific differences. By maintaining a single configuration directory with separate state files (e.g., via different backends or state file paths) and variable files (e.g., `dev.tfvars`, `prod.tfvars`), the team avoids duplication and ensures that all environments use the same module versions and resource definitions, which is a best practice for consistency and maintainability.

Exam trap

HashiCorp often tests the misconception that workspaces are the primary mechanism for managing multiple environments, but the trap here is that workspaces with a local backend lack the isolation and locking required for team-based workflows, making variable files with separate remote state backends the recommended practice.

How to eliminate wrong answers

Option B is wrong because workspaces with a local backend store all state files in the same directory, which can lead to state file corruption or accidental overwrites when multiple team members run Terraform simultaneously, and it does not provide the isolation needed for production-grade environments. Option C is wrong because copying configurations into each environment directory violates the DRY (Don't Repeat Yourself) principle, leading to configuration drift, increased maintenance overhead, and potential inconsistencies between environments. Option D is wrong because creating separate configurations with hardcoded values eliminates reusability, makes updates error-prone, and contradicts Terraform's design of using variables and modules to parameterize infrastructure.

Full explanation →
60
Multi-Selectmedium

During terraform init, which TWO of the following actions occur? (Choose two.)

Select 2 answers
A.Validate the configuration.
B.Create the state file.
C.Download provider plugins.
D.Generate a plan.
E.Initialize the backend.
AnswersC, E

terraform init downloads required providers into .terraform directory.

Why this answer

Option C is correct because `terraform init` downloads the provider plugins specified in the configuration from the Terraform Registry or other configured sources. This is a core function of the init command, ensuring the required plugins are available locally before any operations like plan or apply are executed.

Exam trap

HashiCorp often tests the misconception that `terraform init` validates the configuration or creates the state file, when in fact those actions belong to `terraform validate` and `terraform apply` respectively.

Full explanation →
61
MCQhard

You are a DevOps engineer at a large e-commerce company. The infrastructure team uses Terraform to manage AWS resources across multiple accounts. Recently, they introduced a new module that creates an S3 bucket with a bucket policy. The module is used in several environments (dev, staging, prod). After merging a pull request that updates the bucket policy to grant cross-account access to a new partner account, the 'terraform apply' in the dev environment fails with: 'Error: Error putting S3 policy: AccessDenied: Access Denied'. The team is using a remote backend (S3) with DynamoDB locking. The CI/CD pipeline runs as an IAM role with permissions to manage infrastructure. The module uses 'aws_iam_policy_document' data source to construct the policy. The error occurs only in dev, not staging or prod. What is the most likely cause and the correct course of action?

A.Verify that DynamoDB state locking is not causing the error.
B.Run 'terraform validate' to check the policy document syntax.
C.Check the bucket policy for syntax errors by comparing with staging and prod.
D.Check the IAM permissions associated with the dev environment's role to ensure it has 's3:PutBucketPolicy' on the bucket.
AnswerD

The AccessDenied indicates the IAM role lacks permission to set the policy on that bucket.

Why this answer

Option D is correct because the error 'AccessDenied' when calling 's3:PutBucketPolicy' indicates the IAM role used by the CI/CD pipeline in the dev environment lacks the necessary permission to apply the bucket policy. The module uses 'aws_iam_policy_document' to construct the policy, which is validated at plan time, so syntax errors would surface earlier. The fact that the error occurs only in dev, not staging or prod, points to an environment-specific IAM permissions issue rather than a policy syntax or state locking problem.

Exam trap

HashiCorp often tests the distinction between policy syntax errors (which would appear in all environments) and IAM permission errors (which are environment-specific), leading candidates to incorrectly focus on policy validation or state locking instead of the IAM role's permissions.

How to eliminate wrong answers

Option A is wrong because DynamoDB state locking errors produce messages like 'Error acquiring the state lock' or 'ConditionalCheckFailedException', not 'AccessDenied' from S3 API calls. Option B is wrong because 'terraform validate' checks configuration syntax and internal references, but it cannot validate S3 bucket policy syntax against the AWS IAM policy language; that validation occurs when the policy is applied via the API. Option C is wrong because comparing bucket policies between environments would not resolve an 'AccessDenied' error; the error is an authorization failure, not a syntax error, and the policy is constructed dynamically via the data source, so syntax issues would be consistent across environments.

Full explanation →
62
Multi-Selectmedium

Which TWO of the following are valid ways to import existing infrastructure into Terraform management? (Choose TWO.)

Select 2 answers
A.Use 'terraform validate' to automatically import resources.
B.Use 'terraform state rm' to remove resources from state, then re-add them.
C.Use the 'terraform import' command with the resource address and ID.
D.Write the configuration manually and run 'terraform plan' to refresh state, then adjust.
E.Run 'terraform apply' with an empty configuration to detect resources.
AnswersC, D

This is the primary method for importing existing resources.

Why this answer

Option C is correct because 'terraform import' is the dedicated command to bring existing infrastructure under Terraform management by associating a real-world resource ID with a resource address in state. Option D is correct because you can manually write configuration that matches the existing resource, then run 'terraform plan' to refresh state and detect any drift, allowing you to adjust the configuration until the plan shows no changes.

Exam trap

HashiCorp often tests the misconception that 'terraform validate' or 'terraform apply' can import resources, when in fact only 'terraform import' (or manual configuration with plan refresh) accomplishes this, and candidates confuse validation or apply with the import workflow.

Full explanation →
63
MCQhard

Refer to the exhibit. A developer creates a new Terraform configuration with this backend block and runs terraform init. What will happen?

A.Terraform will initialize with a local backend because the remote backend configuration is incomplete.
B.Terraform will return an error and fail to initialize.
C.Terraform will use default values for the missing arguments and initialize successfully.
D.Terraform will prompt the developer interactively for the missing arguments.
AnswerB

The configuration is invalid; terraform init will fail with the error shown.

Why this answer

The backend block is missing required arguments (like bucket and region). Terraform will return an error during initialization and will not proceed.

Full explanation →
64
MCQhard

A team renamed a module from 'module.network' to 'module.vpc' in their configuration. They run 'terraform plan' and see that Terraform wants to destroy the old network resources and create new ones. They want to preserve the existing resources without downtime. What should they do?

A.Add a 'moved' block to the configuration to map the old module address to the new one.
B.Use 'terraform state mv' to move the resources to the new module address.
C.Update the module source to a new version.
D.Accept the destroy and recreate since it's the only way.
AnswerA

The 'moved' block tells Terraform to treat the renamed module as the same set of resources, preventing destroy/recreate.

Why this answer

Using the 'moved' block is the recommended way to refactor module names without destroying/recreating resources. Option A is wrong because 'terraform state mv' would also work but requires manual commands; 'moved' is declarative. Option B is wrong because changing the source would change the module content, not just the name.

Option C is wrong because destroying and recreating causes downtime.

Full explanation →
65
MCQhard

Refer to the exhibit. What is the most likely cause of this error?

A.The provider block version constraint conflicts with the installed provider version.
B.The required_version block in the configuration is too strict.
C.The .terraform.lock.hcl file is corrupted.
D.The Terraform CLI version is incompatible with the provider.
AnswerA

Correct. The configuration requires provider version >= 3.0, but the installed version is 2.70.

Why this answer

The error indicates that the provider version installed (2.70) does not satisfy the version constraint specified in the configuration (>= 3.0). This typically happens when the configuration requires a newer version than what is installed.

Full explanation →
66
MCQmedium

Refer to the exhibit. A team is using this S3 backend configuration. During a deployment, they receive an error that the state file is locked. What is the most likely cause?

A.The S3 bucket does not exist
B.The region is incorrect
C.The DynamoDB table is not provisioned or the IAM role lacks permissions
D.The key path is incorrect
AnswerC

DynamoDB is used for state locking; if it's missing or inaccessible, lock fails.

Why this answer

Option C is correct because the error message 'state file is locked' directly indicates that Terraform is attempting to acquire a lock on the state using DynamoDB, but the lock table either does not exist or the IAM role used by Terraform lacks the required permissions (dynamodb:PutItem, dynamodb:GetItem, dynamodb:DeleteItem, dynamodb:DescribeTable). Without a properly provisioned DynamoDB table or sufficient IAM permissions, the locking mechanism fails, producing this specific error.

Exam trap

HashiCorp often tests the distinction between S3 access errors and DynamoDB lock errors, so candidates mistakenly attribute the lock error to S3 bucket issues (like missing bucket or wrong region) rather than recognizing it as a DynamoDB-specific failure.

How to eliminate wrong answers

Option A is wrong because if the S3 bucket did not exist, Terraform would return an error such as 'bucket does not exist' or 'NoSuchBucket', not a state lock error. Option B is wrong because an incorrect region would cause an 'InvalidAccessKeyId' or 'region not found' error when trying to access S3, not a lock-related error. Option D is wrong because an incorrect key path would result in a 'NoSuchKey' error when trying to read the state file, not a lock contention issue.

Full explanation →
67
Multi-Selectmedium

A team is evaluating Terraform for managing their multi-cloud infrastructure. Which TWO statements accurately describe Terraform's purpose and capabilities? (Choose two.)

Select 2 answers
A.Terraform requires all configuration files to be placed in a single directory named 'terraform'.
B.Terraform can provision, update, and destroy infrastructure resources across multiple providers.
C.Terraform's configuration language (HCL) is designed to be human-readable and machine-friendly.
D.Terraform uses an imperative language to specify the exact steps to create resources.
E.Terraform is primarily a configuration management tool for installing software on servers.
AnswersB, C

Terraform manages the full lifecycle of infrastructure resources.

Why this answer

Option B is correct because Terraform is designed as an infrastructure-as-code tool that can provision, update, and destroy resources across multiple cloud providers (e.g., AWS, Azure, GCP) and other services using a declarative configuration. This multi-provider capability is a core differentiator from single-cloud tools, enabling consistent workflows for hybrid and multi-cloud environments.

Exam trap

HashiCorp often tests the distinction between declarative (Terraform) and imperative (e.g., Ansible playbooks) approaches, and candidates may confuse Terraform's purpose with configuration management tools like Chef or Puppet.

Full explanation →
68
MCQhard

An organization has a policy that all AWS S3 buckets must have versioning enabled. They want to ensure that even if someone removes the `versioning` block from the configuration, the bucket still has versioning enabled after `terraform apply`. Which lifecycle configuration should they add to the `aws_s3_bucket` resource?

A.`ignore_changes = [versioning]`
B.`replace_triggered_by = [aws_s3_bucket_versioning.this]`
C.`prevent_destroy`
D.`create_before_destroy`
AnswerA

ignores changes to versioning attribute

Why this answer

Option C is correct because setting `ignore_changes` to the versioning block will ignore changes to versioning in the configuration, preserving the current setting. Option A is wrong because `create_before_destroy` is for ordering during recreation. Option B is wrong because `prevent_destroy` prevents deletion, not changes to attributes.

Option D is wrong because `replace_triggered_by` triggers replacement based on another resource.

Full explanation →
69
MCQmedium

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?

A.Cost estimation
B.Sentinel policies
C.Workspace variables
D.Run tasks
AnswerB

Sentinel enforces policies on configurations before apply.

Why this answer

Sentinel policies allow you to define rules that check configurations before they are applied. Workspace variables store values, cost estimation estimates costs, run tasks integrate third-party tools – none of them enforce tagging rules.

Full explanation →
70
MCQmedium

Refer to the exhibit. What does this output indicate?

A.The state file contains multiple resources.
B.The resource is not in the state.
C.The configuration has a resource named web.
D.There is one resource managed by Terraform in this state.
AnswerD

Correct. The output lists one resource, indicating it is the only resource in the state.

Why this answer

The output shows a single resource address in the state file, meaning there is one managed resource of type aws_instance with name web.

Full explanation →
71
Multi-Selectmedium

Which four of the following statements about Terraform state management are correct? (Choose all that apply. There are four correct answers.)

Select 4 answers
.Using remote state storage with a backend like S3 or Azure Storage provides locking to prevent concurrent modifications.
.The `terraform state rm` command can be used to remove a resource from state without destroying the real infrastructure.
.Sensitive data stored in state files can be protected by encrypting the state backend at rest.
.The `terraform import` command updates the state file to include an existing resource, enabling Terraform to manage it.
.Terraform automatically backs up the previous state file every time a new state is written.
.The `terraform state list` command can modify the state file to rename a resource.

Why this answer

Remote state backends like S3 or Azure Storage support state locking (via DynamoDB or Azure Blob lease) to prevent concurrent modifications, ensuring consistency. The `terraform state rm` command removes a resource from state without destroying the real infrastructure, which is useful for detaching management. Encrypting the state backend at rest (e.g., S3 server-side encryption or Azure Storage encryption) protects sensitive data like passwords or keys stored in the state file.

The `terraform import` command updates the state file to include an existing resource, allowing Terraform to take over its management without recreating it.

Exam trap

HashiCorp often tests the misconception that `terraform state list` can modify state or that automatic backups are built-in, when in fact Terraform requires explicit backend versioning or manual backup configuration.

Full explanation →
72
MCQeasy

Refer to the exhibit. A developer modifies the configuration by changing the resource name from 'aws_instance.web' to 'aws_instance.web2'. After running terraform plan, the output indicates that a new resource 'aws_instance.web2' will be created, but no resource will be destroyed. What should the developer do to update the state to match the configuration?

A.Run terraform state mv to rename the resource in state.
B.Run terraform refresh to synchronize the state.
C.Run terraform state rm to remove the old resource and then run terraform import.
D.Run terraform apply, which will automatically update the state.
AnswerA

terraform state mv renames the resource address in state, so plan will treat it as the same resource.

Why this answer

Option A is correct because terraform state mv updates the resource address in the state file to match the new configuration name. Option B is wrong because removing and re-importing is unnecessary and more complex. Option C is wrong because terraform apply would try to create the new resource and destroy the old one, causing potential downtime.

Option D is wrong because terraform refresh only updates attributes, not resource addresses.

Full explanation →
73
MCQhard

After applying the configuration above, the user changes the AMI to a new value and runs 'terraform apply'. Assuming the new AMI triggers a recreate, what happens during the apply?

A.The existing instance is deleted before the new one is created.
B.Both instances run simultaneously only if the instance type allows it.
C.The new instance is created first, then the old one is deleted.
D.The plan fails because AMI change with create_before_destroy is not allowed.
AnswerC

Create_before_destroy ensures the new resource is ready before removing the old.

Why this answer

Option C is correct because Terraform's default lifecycle behavior for most resources is 'create_before_destroy = false', meaning the old resource is destroyed before the new one is created. However, when a resource's configuration change triggers a recreate (like an AMI change for an AWS instance), Terraform first creates the new instance, then destroys the old one, ensuring minimal downtime. This is the standard behavior for resources that support replacement, as Terraform plans the creation of the new resource before destroying the old one to maintain availability.

Exam trap

HashiCorp often tests the misconception that Terraform always destroys before creating, but the trap here is that for resources requiring replacement (like an AMI change), Terraform defaults to creating the new resource first to minimize downtime, unless explicitly configured otherwise.

How to eliminate wrong answers

Option A is wrong because Terraform does not delete the existing instance before creating the new one when a recreate is triggered; it creates the new instance first to avoid downtime, unless 'create_before_destroy' is explicitly set to false or the resource type defaults to destroy-before-create. Option B is wrong because both instances running simultaneously is not dependent on the instance type; it is a result of Terraform's default 'create_before_destroy' behavior for resources that support replacement, and the instance type does not control this lifecycle ordering. Option D is wrong because an AMI change with 'create_before_destroy' is fully allowed and is a common scenario; Terraform supports this lifecycle configuration and will plan the creation of the new instance before destroying the old one.

Full explanation →
74
MCQmedium

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?

A.Sentinel policy enforcement
B.Remote state locking
C.VCS integration
D.Team tokens
AnswerA

Enforces policies that prevent direct state modifications outside the API.

Why this answer

Option A is correct because Sentinel policy enforcement allows the team to define rules that restrict direct modifications to the state file in the storage backend, ensuring that all state changes must go through the Terraform Cloud API. This prevents bypassing Terraform Cloud's access controls and audit logging, which is essential for maintaining integrity and compliance in remote state management.

Exam trap

HashiCorp often tests the distinction between operational controls (like locking) and policy-based enforcement (like Sentinel), so the trap here is assuming that remote state locking alone prevents unauthorized direct access to the storage backend.

How to eliminate wrong answers

Option B is wrong because remote state locking prevents concurrent operations on the same state file but does not prevent direct access to the storage backend; it only manages locking during Terraform runs. Option C is wrong because VCS integration automates runs from version control commits but does not restrict direct state file access via the storage backend API. Option D is wrong because team tokens authenticate API calls but do not enforce that state changes must originate from the Terraform Cloud API; they can be used to directly access the storage backend if permissions allow.

Full explanation →
75
MCQeasy

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

A.The state file is outdated and needs refresh
B.The configuration has a syntax error
C.Another user is running a Terraform operation
D.The user lacks write permissions to the state file
AnswerC

State locking prevents concurrent operations.

Why this answer

Option C is correct because 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.

Exam trap

The trap here is that candidates confuse state locking with file permissions (Option D) or assume the error is due to a stale state (Option A), but Cisco specifically tests the understanding that locking is a concurrency control mechanism, not a permission or syntax issue.

How to eliminate wrong answers

Option A is wrong because an outdated state file does not cause a lock error; it would instead cause a refresh prompt or drift detection, not a lock conflict. Option B is wrong because a syntax error in the configuration would be caught during `terraform validate` or `plan`, not during `apply` as a state lock error. Option D is wrong because insufficient write permissions would result in a permissions error (e.g., 'AccessDenied' or 'permission denied'), not a lock error; locking is a separate mechanism from filesystem permissions.

Full explanation →

Page 1 of 7

Page 2

All pages

1234567

Practice TF-003 by domain

Target a specific domain to shore up weak areas.

Understand IaC conceptsUnderstand Terraform basicsUnderstand Terraform's purposeUse Terraform outside the core workflowInteract with Terraform modulesUse the core Terraform workflowImplement and maintain stateRead, generate and modify configuration
See all domains with question counts →