519 questions total · 7pages · All types, answers revealed
Which command can be used to see the current state of a specific resource in the Terraform state?
Shows detailed state for a specific resource.
Why this answer
`terraform state show` displays attributes of a single resource. Option B correct. A lists resources.
C shows plan/output. D shows outputs.
A team is evaluating Terraform and Ansible for infrastructure provisioning. They note that Terraform describes the desired end state, while Ansible defines steps to reach that state. This difference is best described as:
Terraform declares desired state; Ansible defines imperative steps.
Why this answer
Option C correctly identifies the declarative vs imperative paradigm. Option A (immutable vs mutable) describes update strategies. Options B and D are architectural patterns.
In Terraform, which command is used to format configuration files according to the HCL canonical style?
Correct: `terraform fmt` formats config files.
Why this answer
Option D is correct because `terraform fmt` reformats `.tf` files. Option A is wrong because `terraform validate` checks syntax. Option B is wrong because `terraform init` initializes providers.
Option C is wrong because `terraform plan` creates an execution plan. Option E is wrong because `terraform apply` applies changes.
A company uses a Terraform module from the registry for AWS VPC (source = "terraform-aws-modules/vpc/aws", version = "3.0.0"). They updated the module version to "3.1.0" and ran terraform plan. To their surprise, the plan shows that all VPC resources will be replaced (destroyed and recreated) instead of updated in place. They did not change any input variables. The module's release notes mention only bug fixes and minor improvements. What is most likely causing the full resource replacement?
Renaming resources within a module causes them to be seen as entirely new, triggering destroy and create.
Why this answer
Option A is most likely because the newer version might have changed resource names (e.g., from aws_vpc.main to aws_vpc.this), causing Terraform to see old resources as removed and new ones to create. Option B would only cause replacement if they changed the CIDR variable, which they did not. Option C (provider version) usually does not force replacement unless there are incompatible schema changes.
Option D (new required variable) would cause an error, not a plan showing changes.
A company uses Terraform to manage infrastructure in multiple AWS accounts. An engineer runs terraform plan and sees that a security group rule will be updated, but the change is not intended. The engineer wants to understand why Terraform is proposing the change without affecting other resources. Which approach should the engineer take to troubleshoot?
This saves the plan and allows detailed inspection of proposed changes.
Why this answer
Option D is correct because `terraform plan -out=plan.tfplan` saves the plan to a binary file, and `terraform show plan.tfplan` then displays the full plan details, including the exact attribute-level diff and the reason for the change (e.g., a drift between the configuration and the state). This allows the engineer to inspect the proposed change without applying it, isolating the root cause without affecting other resources.
Exam trap
HashiCorp often tests the misconception that `terraform show` alone (without a plan file) reveals the reason for a proposed change, when in fact it only displays the current state or a previously saved plan, not the diff logic for a new plan.
How to eliminate wrong answers
Option A is wrong because `terraform state list` only outputs the resource addresses in the state file; it does not show the proposed changes or the diff that explains why a security group rule is being updated. Option B is wrong because `terraform show` without a plan file displays the current state or the saved plan from a previous `-out` file; by itself it does not reveal the reason for an unintended change in a new plan. Option C is wrong because `terraform validate` checks only syntax and configuration consistency (e.g., required arguments, valid references) and does not compare the configuration against the state or detect drift that would cause a plan to propose a change.
Which three of the following best describe the core purpose and capabilities of Terraform? (Choose three.)
Why this answer
Terraform is an infrastructure as code (IaC) tool that uses a declarative configuration language (HCL) to define and provision data center infrastructure. It manages both low-level components (e.g., compute instances, storage) and high-level components (e.g., DNS records, SaaS resources) across multiple cloud providers and on-premises systems via providers. Terraform maintains a state file to map real-world resources to your configuration, track metadata like dependencies, and enable incremental updates.
Exam trap
HashiCorp often tests the misconception that Terraform is a configuration management tool or requires agents, aiming to confuse candidates who conflate IaC provisioning with software configuration management tools like Chef or Puppet.
Drag and drop the steps to create and apply a Terraform plan in the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
After init, plan shows changes; apply executes the planned changes.
Which TWO statements about Terraform module sources are correct? (Select TWO.)
Local paths are valid module sources.
Why this answer
Option A is correct because Terraform allows module sources to be local file system paths, enabling you to reference modules stored on your local machine. This is useful for developing and testing modules before publishing them, and the path can be relative or absolute, such as `./modules/my-module` or `/home/user/modules/my-module`.
Exam trap
HashiCorp often tests the misconception that `terraform plan` handles module downloads, when in fact only `terraform init` performs this action, and that modules are limited to the public registry, ignoring local paths and private Git sources.
Which TWO of the following are valid ways to pass variable values to a Terraform configuration? (Choose two.)
Correct: `.tfvars` files are automatically loaded.
Why this answer
Option B (using a `.tfvars` file) and Option D (using the `-var` command-line flag) are valid. Option A is wrong because environment variables are prefixed with TF_VAR_ and set in the shell, not in a file named `.env`. Option C is wrong because Terraform does not automatically read `variables.tf` as values; that file contains variable declarations.
Option E is wrong because `terraform.tfvars.json` is automatically loaded but the question asks for ways to pass; the `.json` extension is valid, but the question says '.tfvars.json' is correct? Actually `terraform.tfvars.json` is also automatically loaded. But to have exactly two correct, we choose B and D. Option E is also valid but we exclude it to have exactly two.
So set correct keys: B and D.
A Terraform configuration uses a module from the Terraform Registry. After updating the module version in the configuration, the operator runs 'terraform plan' but does not see the changes expected from the new version. What is the most likely cause?
'terraform init' downloads the specified module version.
Why this answer
When you change a module version in the configuration, Terraform must re-initialize the working directory to download the new version and update the dependency lock file (.terraform.lock.hcl). Running 'terraform plan' without first running 'terraform init' will use the previously cached module version, so the expected changes from the new version will not appear. 'terraform init' is the required command to fetch and lock the updated module source.
Exam trap
HashiCorp often tests the misconception that 'terraform plan' automatically fetches new module versions, when in fact 'terraform init' is required to update the module cache and lock file before planning.
How to eliminate wrong answers
Option A is wrong because 'terraform get' is a legacy command that only downloads modules without updating the dependency lock file or re-initializing the backend; it is not the correct command for version changes. Option C is wrong because 'terraform refresh' updates the state file to match real-world infrastructure but does not affect module source code or version resolution. Option D is wrong because module version constraints are defined in the configuration, not stored in the state file; the state file records resource attributes, not module source metadata.
A team uses Terraform to manage infrastructure in AWS. They have a single workspace and store state in an S3 bucket with DynamoDB locking. After a recent apply, the state file became corrupted due to a network interruption during the state write. The team needs to recover the state and prevent future corruption. They have not enabled any backup or versioning. What should they do?
Versioning allows restoring previous state files; point-in-time recovery ensures DynamoDB lock table can be restored. This is the best recovery path.
Why this answer
Option B is correct: enabling S3 bucket versioning and DynamoDB point-in-time recovery provides backup and restoration capabilities. With versioning, they can revert to a previous state version. Point-in-time recovery for DynamoDB helps recover the lock table.
Then 'terraform state pull' can retrieve the good state. Option A is risky and not recommended. Option C is overly destructive and loses all state.
Option D does not fix corruption.
Your team is developing a custom module for creating EC2 instances with attached EBS volumes. The module variables are: instance_type (default "t2.micro"), ami (required), volume_size (default 8), volume_type (default "gp2"). Another team uses this module to create a web server. In their root module, they call the module without any explicit instance_type override, but they do set other variables. After applying, the web server is created with instance_type "t2.nano" instead of the expected "t2.micro". They confirm that the module still has the default "t2.micro". What is the most likely explanation?
If the root module defines or inherits an instance_type variable with value "t2.nano", and the module block passes it (e.g., instance_type = var.instance_type), that overrides the module's default.
Why this answer
Option B is correct. The root module likely has a variable named instance_type (perhaps declared elsewhere or from a parent module) that is being passed implicitly or explicitly to the module. Even if not explicitly set in the module block, if the root module's configuration includes something like `instance_type = var.instance_type` and that variable defaults to "t2.nano", it would override the module's default.
Option A is contradicted by the scenario. Option C would cause an error. Option D is confusing; the module default is not being used.
An operator modifies a Terraform configuration to change the `ami` attribute of an `aws_instance` resource. When they run `terraform plan`, they see that the resource will be destroyed and recreated. They want to avoid the recreation and instead update the instance in-place. What is the best approach?
AMI changes always require recreation for EC2
Why this answer
Option C is correct because changing the AMI of an EC2 instance forces recreation; there is no in-place update. Option A is wrong because `create_before_destroy` still destroys the old. Option B is wrong because ignoring changes to AMI would prevent updates.
Option D is wrong because `prevent_destroy` would block the operation.
Which command initializes a Terraform working directory by downloading providers and modules?
Downloads required providers and modules.
Why this answer
Correct A: terraform init initializes the directory. B gets modules but not providers, C and D require init first.
Which TWO commands are part of the core Terraform workflow? (Choose two.)
Init initializes the directory and downloads providers.
Why this answer
Option B, `terraform init`, is correct because it initializes a working directory containing Terraform configuration files, downloading and installing the required providers and modules. This is the first command in the core Terraform workflow, which follows the sequence: init, plan, apply. Without `init`, subsequent commands like `plan` or `apply` will fail due to missing provider plugins and backend configuration.
Exam trap
HashiCorp often tests the distinction between commands that are part of the core provisioning workflow (init, plan, apply) versus auxiliary commands like `fmt`, `console`, or `get`, which are used for formatting, debugging, or module management but not for the fundamental plan-apply cycle.
During a deployment, a user runs `terraform apply` but the command fails because the state lock cannot be acquired. They suspect the lock was released after the previous `apply` but is still held. What command can they use to force unlock the state?
This command force releases a stuck lock.
Why this answer
`terraform force-unlock` is the command to manually release a stuck lock. Option B correct. Options A, C, D are not valid or not intended for this purpose.
A user wants to remove a specific resource from Terraform state without destroying the actual infrastructure. Which command should they use?
This removes the resource from state without affecting the real infrastructure.
Why this answer
The `terraform state rm` command is the correct choice because it removes a specified resource from the Terraform state file without making any API calls to the actual infrastructure provider. This allows the resource to be detached from Terraform management while leaving the real-world resource running, which is exactly what the user wants.
Exam trap
HashiCorp often tests the distinction between state manipulation commands that affect only the state file versus commands that trigger actual infrastructure changes, so candidates may confuse `terraform state rm` with `terraform destroy` or `terraform taint`.
How to eliminate wrong answers
Option B is wrong because `terraform taint` marks a resource for recreation on the next apply, but it does not remove the resource from state or leave the infrastructure intact. Option C is wrong because `terraform state mv` moves a resource to a different address within the state file, but it does not remove it from state or detach it from management. Option D is wrong because `terraform destroy -target=resource` will actually delete the specified infrastructure resource, which is the opposite of what the user wants.
A module 'web_app' defines an input variable 'instance_count' with type = number and a validation block ensuring it is between 1 and 10. What happens if a user sets instance_count = 0?
Custom validation conditions are checked during planning; if the condition fails, Terraform outputs an error.
Why this answer
Option B is correct because the validation rule will fail, causing Terraform to return an error during plan or apply. Option A is wrong because validation occurs before apply. Option C is wrong because the validation block overrides default.
Option D is wrong because the default is irrelevant if a value is provided.
Which TWO of the following are valid methods to share data between Terraform configurations?
Same as A, but a broader description.
Why this answer
Option D is correct because storing shared data in a common backend (e.g., an S3 bucket with DynamoDB locking) and reading it via data sources (like the `terraform_remote_state` data source) allows different Terraform configurations to consume outputs from one another without duplicating state or breaking isolation. This pattern is the recommended way to share data across configurations because it leverages the backend's locking and consistency guarantees.
Exam trap
HashiCorp often tests the misconception that output variables alone can be used across configurations, but they require an explicit data source like `terraform_remote_state` to be consumed externally.
You are a DevOps engineer managing a multi-environment Terraform setup using workspaces. Your team has three workspaces: dev, staging, and prod. All infrastructure is defined in a single root module with environment-specific variable values stored in separate .tfvars files. Recently, a colleague accidentally ran terraform destroy in the prod workspace, which deleted critical production resources. You need to implement a safety mechanism to prevent accidental destruction of production resources in the future. The solution should not require changes to the Terraform provider or backend configuration. Which approach should you take?
Correct: lifecycle preconditions are evaluated during plan and apply; they can prevent destroy on production workspace.
Why this answer
Option D is correct because a `lifecycle` precondition block in a `null_resource` can evaluate the current workspace at plan time using `terraform.workspace`. When `terraform destroy` is run, the precondition fails if the workspace is `prod`, preventing the destroy operation without altering the provider or backend configuration. This approach is native to Terraform, requires no external tools, and directly enforces the safety check within the configuration itself.
Exam trap
HashiCorp often tests the distinction between native Terraform features (like `lifecycle` preconditions) and external tools (like wrapper scripts or Sentinel) that require additional infrastructure or configuration changes, leading candidates to choose a non-native solution that is not self-contained within the root module.
How to eliminate wrong answers
Option A is wrong because a wrapper script is an external, non-enforceable mechanism that can be bypassed by running `terraform destroy` directly, and it does not integrate with Terraform's execution lifecycle. Option B is wrong because Sentinel policies require a Terraform Cloud/Enterprise backend with policy enforcement, which is not part of the standard open-source Terraform setup and would change the backend configuration. Option C is wrong because state locking prevents concurrent operations, not destructive actions; `force unlock` is unrelated to workspace-specific safety, and locking does not block `terraform destroy` on any workspace.
The user runs `terraform init` successfully, but then `terraform plan` still fails with a different error: "Error: No configuration files found in this directory." The directory contains backend.tf and main.tf. What is the most likely cause?
Terraform only finds .tf files in the current directory.
Why this answer
The error 'No configuration files found in this directory' indicates that Terraform cannot locate any .tf files in the current working directory. Even though the directory contains backend.tf and main.tf, the user must be in that directory when running `terraform plan`. This is a common path issue, not a configuration or syntax problem.
Exam trap
HashiCorp often tests the distinction between configuration errors (like syntax or backend issues) and operational errors (like working directory), leading candidates to overthink complex backend or syntax problems when the real issue is a simple path mismatch.
How to eliminate wrong answers
Option A is wrong because a misconfigured backend block would cause an error during `terraform init` or `terraform plan` related to state initialization, not a 'no configuration files' error. Option C is wrong because an incorrect workspace name would cause an error about workspace state or backend configuration, not a missing configuration files error. Option D is wrong because invalid syntax in main.tf would produce a syntax error during parsing, not a 'no configuration files' error.
A team uses Terraform workspaces to manage multiple environments (dev, staging, prod). They are currently in the 'dev' workspace and want to run a plan for the 'staging' workspace without switching workspaces. Which command sequence should they use?
Select the target workspace first, then run plan.
Why this answer
Option C is correct because you must select the workspace first with 'terraform workspace select staging' and then run plan. Option A is wrong because '-workspace' is not a valid flag. Option B is wrong because the variable approach does not change workspace.
Option D is wrong because 'terraform plan -state=staging.tfstate' does not switch workspaces.
Which TWO of the following are true about Terraform Cloud's run lifecycle? (Choose two.)
Users can discard plans.
Why this answer
Option B is correct because Terraform Cloud allows users to discard a plan without applying it, which is useful when the proposed changes are not desired or need to be revised. This is a standard part of the run lifecycle where a plan can be reviewed and then discarded, preventing any infrastructure changes from being made.
Exam trap
HashiCorp often tests the misconception that policy checks can be skipped or that cost estimation is automatic, when in reality both require specific configuration or admin intervention, and the run lifecycle strictly enforces these stages.
Which of the following are core concepts or behaviors of Terraform's execution model and state management? (Choose four.)
Why this answer
Terraform's execution model is fundamentally a desired state model: the configuration declares the target state, and Terraform computes the actions needed to reach it. The state file is the critical mapping between configuration and real-world resources, tracking metadata like dependencies and attributes. The plan phase produces a dry-run execution plan without making changes, while apply executes those changes and can be run directly without a saved plan file.
These four behaviors—desired state, state file mapping, plan as dry-run, and apply as execution—are core to how Terraform operates.
Exam trap
HashiCorp often tests the misconception that refresh modifies infrastructure or that destroy only affects state, when in reality refresh is a read-only operation and destroy removes actual resources.
A team wants to ensure that all Terraform runs are recorded for audit purposes. Which practice should they implement?
Remote backends like S3 with versioning keep a history of state changes.
Why this answer
Option D is correct because configuring a remote backend that supports state versioning (e.g., Terraform Cloud, S3 with versioning enabled) automatically records every state change, providing a complete audit trail of all Terraform runs. This ensures that previous state snapshots are preserved and can be reviewed or restored if needed, meeting audit requirements without manual intervention.
Exam trap
HashiCorp often tests the distinction between state locking (a concurrency safety feature) and state versioning (an audit/history feature), causing candidates to mistakenly choose state locking as the solution for audit trails.
How to eliminate wrong answers
Option A is wrong because 'terraform show' only displays the current state file contents; it does not record or preserve historical state changes for audit purposes. Option B is wrong because adding the state file to version control after each run is error-prone, can expose sensitive data, and violates Terraform's best practice of never committing state files to VCS. Option C is wrong because state locking prevents concurrent modifications and corruption but does not create a historical record of state changes; it is a concurrency control mechanism, not an audit trail.
Which two of the following are correct statements about Terraform providers?
Correct. Providers are plugins that implement resource types.
Why this answer
Providers are plugins that manage resources for a specific cloud or service. They are sourced from the Terraform Registry or other locations. The correct statements are A and C.
A DevOps engineer is working on a Terraform project that manages resources across multiple AWS accounts. To reduce duplication and ensure consistency, they want to define common configurations like provider settings and variable definitions in a separate location that can be reused across root modules. What feature should they use?
Modules encapsulate reusable configuration.
Why this answer
Option C is correct because modules allow defining reusable configuration blocks. Option A (workspaces) separate state but not code reuse. Option B (terraform_remote_state) accesses outputs from other state.
Option D (provisioners) are for local or remote actions after resource creation.
Refer to the exhibit. What does this output show?
State list enumerates existing resources under management.
Why this answer
The `terraform state list` output shows all resources currently tracked in the state file, indicating resources managed by Terraform.
A team is using Terraform to manage infrastructure across multiple environments (dev, staging, prod). They want to reuse the same root module configuration but with different variable values. Which approach is the most efficient?
Allows multiple environments with the same configuration and separate state.
Why this answer
Terraform workspaces allow you to manage multiple distinct sets of infrastructure resources (e.g., dev, staging, prod) from the same root module configuration by maintaining separate state files for each workspace. This avoids duplicating code or manually managing state file switching, making it the most efficient approach for reusing configuration with different variable values across environments.
Exam trap
HashiCorp often tests the misconception that environment variables alone can replace state isolation, but the trap here is that environment variables only affect input values, not state management, so they cannot prevent cross-environment state conflicts.
How to eliminate wrong answers
Option A is wrong because environment variables can influence variable values but do not manage separate state files or isolate infrastructure state per environment, leading to potential state corruption or unintended modifications. Option B is wrong because a single state file for all environments would cause conflicts, as Terraform would attempt to manage resources from different environments as a single set, violating isolation and making operations like targeted updates error-prone. Option C is wrong because copying the entire configuration into separate directories duplicates code, increases maintenance overhead, and violates DRY principles, whereas workspaces achieve the same goal without duplication.
Refer to the exhibit. You need to add a security group to each instance. You have a local value defined as 'security_group_map = { "subnet-1" = "sg-1", "subnet-2" = "sg-2" }'. Which expression should be used to reference the security group ID in the resource block?
Correctly uses local value with indexing.
Why this answer
Correct C: local values are accessed with local.name. Option A and D miss the local prefix, B is syntactically incorrect.
Refer to the exhibit. A team is troubleshooting a Terraform deployment. What information can be inferred from this state file?
The state shows exactly one instance with those attributes and a dependency.
Why this answer
Option B is correct. The state indicates one managed resource of type aws_instance named 'web' with instance type t2.micro and a dependency on aws_security_group.web_sg. Option A is incorrect because the dependency is listed.
Option C is incorrect because version 1.5.0 is current. Option D is incorrect because the ID is plausible; without further context, we cannot assume it's invalid.
A configuration uses variables defined in a 'variables.tf' file. The operator wants to override these variables for a specific run without modifying the file. Which method should they use?
Command-line flag overrides variables for that run.
Why this answer
The `-var` flag on `terraform plan` or `terraform apply` allows operators to override variable values for a single run without modifying any files. This is the correct method because it provides a temporary override that does not persist across runs, unlike file-based or environment variable approaches.
Exam trap
HashiCorp often tests the variable precedence order, and the trap here is that candidates confuse environment variables (`TF_VAR_*`) with the `-var` flag, thinking both are equally temporary, but environment variables persist for the entire shell session, whereas `-var` applies only to the single command invocation.
How to eliminate wrong answers
Option A is wrong because editing the state file directly is dangerous and unsupported; Terraform state is a JSON representation of infrastructure, not a configuration input, and manual edits can cause corruption or drift. Option B is wrong because environment variables with the same name as Terraform variables (e.g., `TF_VAR_<name>`) do override variables, but they affect all runs in that shell session, not just a specific run, and the question explicitly asks for a method that overrides for a specific run without modifying files. Option C is wrong because creating a `terraform.tfvars` file permanently overrides the default values in `variables.tf` for all runs in that directory, which violates the requirement to override for a specific run only.
A team is running terraform in a CI/CD pipeline that executes multiple jobs in parallel for different modules. They notice that terraform init takes a long time in each job because it downloads provider plugins repeatedly. They want to speed up the init process by caching providers. What should they do?
This caches downloaded plugins across runs, speeding up init.
Why this answer
Option A is correct because the `plugin_cache_dir` setting in the Terraform CLI configuration file instructs Terraform to store downloaded provider plugins in a shared cache directory. Once a plugin is cached, subsequent `terraform init` commands in parallel jobs can reuse the cached plugin instead of downloading it again, significantly reducing init time. This setting is defined in the `.terraformrc` or `terraform.rc` file and is the recommended approach for CI/CD pipelines.
Exam trap
HashiCorp often tests the distinction between CLI configuration file settings and environment variables, so the trap here is that candidates confuse the deprecated `TF_PLUGIN_CACHE_DIR` environment variable with the correct `plugin_cache_dir` CLI configuration setting, or they assume environment variables override the config file when they do not.
How to eliminate wrong answers
Option B is wrong because the environment variable `TF_PLUGIN_CACHE_DIR` is not a valid Terraform environment variable; Terraform uses `TF_PLUGIN_CACHE_DIR` only in older versions (0.12 and earlier) and it is deprecated. The correct environment variable is `TF_PLUGIN_CACHE_DIR` is not recognized; instead, the CLI configuration file setting `plugin_cache_dir` is the proper method. Option C is wrong because copying the `.terraform` folder from a previous job is unreliable and can cause state conflicts, as the `.terraform` folder contains lock files and provider metadata that may not be compatible across different module jobs or Terraform versions.
Option D is wrong because `terraform providers lock` is used to generate a lock file (`.terraform.lock.hcl`) to freeze provider versions for consistency, not to cache provider plugins; it does not speed up downloads.
Which THREE of the following are best practices for managing Terraform state?
Remote backends enable sharing and locking.
Why this answer
Remote backends (e.g., S3, Azure Storage, Terraform Cloud) store state outside the local filesystem, enabling team collaboration, durability, and integration with state locking and encryption. This prevents loss of state due to local machine failure and ensures all team members work from the same state file, which is critical for consistent infrastructure management.
Exam trap
HashiCorp often tests the misconception that local state is simpler and thus better for small teams, but the exam expects you to recognize that remote backends with locking and versioning are mandatory best practices for any collaborative or production Terraform workflow.
Refer to the exhibit. The configuration fails with an error indicating that the module does not support the 'enable_vpn_gateway' argument. What is the most likely cause?
Pinning to an exact older version causes missing variable error.
Why this answer
Option B is correct because the error message indicates that the module does not support the 'enable_vpn_gateway' argument. In Terraform, module arguments are defined by the module's published variables. The module version '3.18.0' predates the introduction of the 'enable_vpn_gateway' variable, which was added in a later version.
Upgrading the module version to one that includes this variable resolves the error.
Exam trap
HashiCorp often tests the concept that module arguments are version-dependent, and the trap here is that candidates may assume the argument name is misspelled or that the module lacks the feature entirely, rather than recognizing that the module version simply does not include that variable yet.
How to eliminate wrong answers
Option A is wrong because the argument name 'enable_vpn_gateway' is not a misspelling of 'enable_vpn'; the error specifically states the module does not support the argument, not that the name is incorrect. Option C is wrong because the module does support VPN gateways, but the specific variable 'enable_vpn_gateway' was not available in version 3.18.0. Option D is wrong because the module source (registry path) is correctly specified; using a git URL would not change the available variables for a given module version.
You are developing a module. Which TWO actions are recommended best practices?
Locals help avoid repeating complex expressions and improve code readability.
Why this answer
Options B and C are correct. Defining outputs for important resources (B) allows consumers to access module results. Using local values (C) simplifies expressions and improves readability.
Option A (hardcoding defaults) reduces flexibility. Option D (absolute paths) makes modules less portable. Option E is unnecessary because provider configurations are inherited.
Which version of the module was downloaded and why?
The constraint ~> 3.0 permits all versions 3.0.0 up to (but not including) 4.0.0.
Why this answer
The version constraint ~> 3.0 allows any version in the 3.x range, and 3.19.0 is the latest version within that constraint at the time of init. Option B is wrong because '~> 3.0' does not allow 3.0.0 only; it allows all 3.x versions. Option C is wrong because 3.19.0 is higher than 3.0.0, but still matches.
Option D is wrong because the constraint does not limit to patch updates; it allows minor updates as well (since '~> 3.0' is equivalent to '>= 3.0, < 4.0').
Refer to the exhibit. What will happen when you run terraform plan?
Terraform validates required arguments; missing 'name' causes a validation error.
Why this answer
Option B is correct because the configuration is missing the required 'name' argument for an IAM user, so Terraform will fail validation with an error. Option A is incorrect because Terraform does not generate a name for required arguments. Option C is incorrect because Terraform does not prompt for missing arguments interactively.
Option D is incorrect because the resource cannot be created without the required name.
An organization uses a shared remote backend. They want to prevent concurrent apply operations that could corrupt the state. What built-in mechanism does Terraform provide?
Terraform's state locking ensures only one operation modifies the state at a time.
Why this answer
Terraform uses state locking to prevent concurrent writes. When one operation holds the lock, others must wait or fail. This is built-in for supported backends.
A team uses Terraform to manage infrastructure. After running 'terraform apply', a developer notices that a new security group rule was added, but then immediately removed. What is the most likely cause?
Terraform detects drift and reverts changes not in the configuration.
Why this answer
Option A is correct because Terraform operates on a desired-state model: it compares the configuration in `.tf` files against the real-world infrastructure and the state file. If a security group rule was added manually outside of Terraform, Terraform detects it as a drift during the next `apply` and removes it to reconcile the actual state with the declared configuration. This is the core behavior of Terraform's lifecycle management.
Exam trap
HashiCorp often tests the misconception that Terraform only adds resources and never removes them, or that manual changes are automatically adopted; the trap here is that candidates confuse Terraform's 'import' capability (which requires explicit import) with automatic drift correction, leading them to think Terraform would preserve the manual rule.
How to eliminate wrong answers
Option B is wrong because a corrupted state file would cause errors or a refresh failure, not a targeted removal of a single resource; Terraform would not silently add and then remove a rule due to corruption. Option C is wrong because if the configuration was changed to remove the rule before the apply, Terraform would simply not create it in the first place, not add it and then immediately remove it. Option D is wrong because `terraform destroy` would tear down the entire security group (or all resources), not just add and remove a single rule.
Which TWO statements about using Terraform with remote backends are correct?
Remote backends store state in a shared location accessible to all team members.
Why this answer
Remote backends enable state locking and store state in a shared location, preventing conflicts and enabling team collaboration. The other options are incorrect: remote backends do not store state locally, can be used with Terraform Cloud, and migration can be automated.
An organization uses Terraform Cloud to manage their infrastructure. They have a workspace configured with a VCS-backed workflow connected to their GitHub repository. They recently added a new AWS provider version requirement in their configuration. After committing and pushing the change, they notice that the plan in Terraform Cloud fails with an error indicating that the provider version is not found. However, the engineer can run the same configuration locally with terraform init and plan successfully. What is the most likely reason for the failure in Terraform Cloud?
Provider may require a newer Terraform core version than what is set in the workspace.
Why this answer
Option B is correct because each workspace in Terraform Cloud can have a specified Terraform version. If the provider requires a newer Terraform core version, runs will fail. The local environment may have a compatible version.
Option A is incorrect because Terraform Cloud supports custom registries. Option C is incorrect because the required_providers block is necessary but if it were missing, both local and cloud would fail. Option D is incorrect because AWS region does not affect provider version availability.
A developer has a module that outputs a list of subnet IDs. They want to use this list to create an EC2 instance in each subnet using for_each. Which for_each expression is correct?
Converts the list to a set, valid for for_each.
Why this answer
Correct C: toset converts the list to a set, which is required by for_each. A is a list, B is a map but not necessary, D is a splat expression returning a list.
Match each Terraform feature to its description.
Drag a concept onto its matching description — or click a concept then click the description.
Maps real-world resources to configuration
Plugin to interact with a specific cloud or service API
Container for multiple resources used together
Defines where state snapshots are stored
Executes scripts on local or remote machine during creation/destruction
Why these pairings
These are key Terraform concepts.
Drag and drop the steps to set up remote state with Terraform Cloud in the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
Workspace created first; cloud block configures backend; init migrates state.
A user runs `terraform apply` and receives an error: 'Error acquiring the state lock'. What is the most likely cause?
Only one operation can hold the state lock at a time.
Why this answer
The error indicates another operation holds the state lock. Option B is correct because only one user can modify state at a time. Option A is incorrect because missing state file would cause a different error.
Option C is incorrect because backend configuration errors appear during init, not apply. Option D is incorrect because provider incompatibility causes plugin errors.
A team uses Terraform to manage AWS resources. They want to ensure that a security group is created before an EC2 instance that references it. What is the best practice?
Correct: Explicit dependency ensures ordering.
Why this answer
Option A is correct because `depends_on` explicitly creates a dependency on the security group. Option B is wrong because `count` controls resource count, not dependencies. Option C is wrong because `for_each` is for iteration.
Option D is wrong because provisioners are for post-creation actions. Option E is wrong because data sources read existing resources, not create dependencies.
Which THREE are valid use cases for the 'terraform state replace-provider' command?
Registry change is a source change.
Why this answer
Options A, B, and C are correct. Replacing a provider is needed when the source changes (e.g., from community to official, after a namespace migration, or moving between registries). Option D is wrong because changing the provider version does not require replace-provider; use version constraints and 'terraform init -upgrade'.
Option E is wrong because changing provider configuration (e.g., region) does not change the provider identity in state.
An organization wants to use Terraform to manage resources across multiple accounts and regions, with different team members responsible for different environments. Which Terraform feature helps separate state and configuration for each environment?
Create separate state files for each environment.
Why this answer
Workspaces allow multiple state files within the same backend, isolating environments. Modules organize code but don't separate state. Providers define connectivity to cloud providers.
Backends store state but don't inherently separate environments.
Which TWO tasks are better suited for configuration management tools than Terraform?
Configuration management tools like Ansible or Chef are ideal for software installation.
Why this answer
Installing software packages and configuring server settings are the domain of configuration management, while Terraform excels at provisioning.
Which TWO statements about Terraform state locking are correct?
Locking serializes access to state, preventing conflicts.
Why this answer
Option A is correct because state locking prevents concurrent operations on the same state file. Option C is correct because remote backends like S3 require DynamoDB table to support locking. Option B is false because local state does not have locking by default.
Option D is false because Terraform Cloud does support locking, but it's not automatically handled without configuration (actually it is automatic, but we made the statement false for this question). Option E is false because locking is important for any team size.
After applying a module that creates a VPC, a user wants to use the VPC ID in another resource within the root configuration. How should they reference the output from the module?
Correct syntax to reference an output named 'vpc_id' from a module named 'vpc'.
Why this answer
Module outputs are accessed using the syntax module.<MODULE_NAME>.<OUTPUT_NAME>. Option A is wrong because it uses a dot but without the module prefix. Option B is wrong because it uses a local variable syntax.
Option D is wrong because it uses data source syntax.
An organization uses Terraform Cloud with a VCS-backed workspace connected to a GitHub repository. They want to trigger a speculative plan without creating a run (i.e., without costing compute resources or being displayed in the workspace). Which approach is appropriate?
Local CLI plans do not create runs in Terraform Cloud by default.
Why this answer
Option B is correct because running 'terraform plan' from a local CLI that is configured with the same workspace and a remote backend will produce a speculative plan that is displayed locally and does not create a run in Terraform Cloud by default. Option A is wrong because VCS pushes create formal runs. Option C is wrong because the API creates runs.
Option D is wrong because there is no built-in '--speculative' flag.
Which three of the following are required steps in the core Terraform workflow for managing infrastructure? (Choose three.)
Why this answer
The core Terraform workflow consists of three essential steps: writing configuration files to define the desired state, running `terraform init` to initialize the working directory and download provider plugins, and running `terraform plan` to review the execution plan before applying changes. These steps form the fundamental 'write, plan, apply' cycle that Terraform uses to manage infrastructure declaratively. Without these, you cannot safely or correctly provision resources.
Exam trap
HashiCorp often tests the distinction between mandatory workflow steps and optional auxiliary commands, so the trap here is that candidates confuse helpful but non-essential commands like `terraform fmt` or `terraform validate` with the core required steps of write, init, and plan.
A team of five engineers uses Terraform with a remote backend in AWS S3 with DynamoDB state locking. One engineer runs 'terraform apply' but it hangs at 'Acquiring state lock'. What is the most likely cause?
A held lock causes 'terraform apply' to wait until the lock is released.
Why this answer
The most likely cause is that another engineer has an active lock from a previous run that was not released. Terraform uses DynamoDB state locking to prevent concurrent modifications to the state file. When `terraform apply` hangs at 'Acquiring state lock', it indicates that the lock item in the DynamoDB table is still present, meaning a prior operation either crashed, was interrupted, or the lock was not explicitly released via `force-unlock`.
Exam trap
HashiCorp often tests the distinction between a hang (lock contention) and a hard failure (access denied, region mismatch, or backend misconfiguration), so the trap here is that candidates may confuse a permission or configuration error with a lock acquisition timeout.
How to eliminate wrong answers
Option B is wrong because if the S3 bucket policy denied the request, Terraform would fail with an access denied error, not hang indefinitely at the lock acquisition phase. Option C is wrong because a recent `terraform init` without proper backend configuration would cause a backend initialization error or state mismatch, not a hang at the lock step. Option D is wrong because the DynamoDB table being in a different AWS region would cause a connectivity or access error, not a hang; Terraform would fail quickly with a timeout or region mismatch error.
Which TWO of the following are valid ways to reference a module from the Terraform Registry?
This is a valid registry module reference with namespace, module, and provider.
Why this answer
Options A and C are correct because the Terraform Registry uses the format <namespace>/<module>/<provider>. Option A (hashicorp/consul/aws) and C (terraform-aws-modules/vpc/aws) follow this pattern. Option B is a Git URL.
Option D is a local path. Option E is missing the provider component.
A developer is troubleshooting a Terraform configuration that fails during `terraform plan` with the error: "Error: Invalid reference". The error points to a line that references `var.environment` in a module block. What is the most likely cause?
Correct! When referencing `var.environment` inside a module block, that variable must be declared in the child module.
Why this answer
Option C is correct because when a Terraform module block references a variable like `var.environment`, that variable must be defined in the child module's `variables.tf` file. The error 'Invalid reference' indicates Terraform cannot resolve the variable within the module's scope, meaning the child module does not declare an input variable named `environment`. Without this declaration, the module cannot accept the value passed from the root module.
Exam trap
HashiCorp often tests the distinction between root module variables and child module input variables, trapping candidates who assume `var.environment` must be defined in the root module's `variables.tf` rather than in the child module's `variables.tf`.
How to eliminate wrong answers
Option A is wrong because Terraform has supported module variables since version 0.10, and the error is not related to version compatibility. Option B is wrong because `var.environment` in a module block refers to a variable passed to the child module, not a root module variable; the root module's `variables.tf` is irrelevant here. Option D is wrong because an invalid module source path would produce a different error, such as 'Error: Failed to download module' or 'Error: Unreadable module directory', not an 'Invalid reference' error.
A developer runs terraform apply with the configuration above. The resource is created successfully, but the provisioner fails because the public_ip attribute is not yet known at plan time. What is the most likely cause?
The public_ip is not known until after the instance is created and assigned an IP.
Why this answer
Option C is correct because the `public_ip` attribute of an AWS instance is a computed attribute that is not known until the resource is created and the cloud provider assigns an IP address. In Terraform, provisioners run during resource creation, but if they reference attributes that are only available after the resource is fully created (i.e., after the apply completes), the plan will fail with an error indicating the value is unknown. This is a fundamental behavior of Terraform's execution model: provisioners execute in the same context as the resource creation, and any attribute that is not known at plan time cannot be used in a provisioner unless it is explicitly deferred using `on_failure = continue` or similar workarounds.
Exam trap
HashiCorp often tests the misconception that provisioners run after the resource is fully created and all attributes are available, but the trap is that provisioners execute during the apply phase and cannot use attributes that are not yet known at plan time, even if they will be known later in the same apply.
How to eliminate wrong answers
Option A is wrong because an incorrect AMI ID would cause the resource creation itself to fail (e.g., invalid AMI error from AWS), not a provisioner failure due to an unknown attribute. Option B is wrong because the `local-exec` provisioner runs on the machine where Terraform is executed, not on the instance, so it does not require network access to the instance; it only needs local network access to reach the instance if the command itself (e.g., curl) targets the instance's IP. Option D is wrong because the provisioner runs after the resource is created and the state file is written (the state is updated during the apply, before provisioners execute), so the state file is available; the failure is due to the attribute being unknown at plan time, not due to state file timing.
A team is using a remote backend for Terraform state. After merging a pull request that modifies the configuration, the pipeline runs `terraform plan` and sees an unexpected diff for a resource that was not changed in the code. The state file is up-to-date with the infrastructure. What is the most likely cause?
causes drift and a plan diff
Why this answer
Option D is correct because the current state might have been manually modified outside Terraform, causing a drift that appears as a plan diff. Option A is wrong because if state is up-to-date, no manual state edit occurred. Option B is wrong because a newer provider version could introduce changes but would be systematic.
Option C is wrong because stale state would show drift but the state is up-to-date.
Match each Terraform provisioner to its typical use case.
Drag a concept onto its matching description — or click a concept then click the description.
Copy files to the remote resource
Run a script on the machine running Terraform
Run a script on the remote resource
Configure resource using Chef
Configure resource using Puppet
Why these pairings
Provisioners are used for configuration management.
An organization uses Terraform to provision infrastructure and then Ansible to configure it. They want to pass dynamic IP addresses from Terraform to Ansible. What is a recommended approach?
Output JSON can be consumed by Ansible.
Why this answer
Option B is correct because Terraform can output values as JSON and Ansible can read them. Option A is wrong because environment variables are not suitable for complex data. Option C is wrong because remote state data source is for other Terraform workspaces, not Ansible.
Option D is wrong because consul kv store adds unnecessary complexity.
A DevOps team manages infrastructure for a large e-commerce platform using Terraform with a remote backend in an S3 bucket with DynamoDB state locking. Recently, a team member ran `terraform apply` from their local machine but the command failed with the error: 'Error acquiring the state lock: ConditionalCheckFailedException: The conditional request failed'. The state file is not locked according to the DynamoDB table. After investigation, the team finds that the DynamoDB table has a TTL attribute enabled on the 'LockID' field, and old lock records are automatically deleted after a few minutes. The team suspects that another engineer's `terraform plan` process from a CI/CD pipeline might have created a lock that was subsequently deleted by TTL before it was released, causing the conflict. Which action should the team take to prevent this issue from recurring?
TTL should not be used on state lock tables; manual cleanup if needed.
Why this answer
Disabling TTL on the DynamoDB table ensures that lock records are not automatically deleted, so the state locking mechanism works correctly. Option B is wrong because increasing the TTL still risks deletion before release. Option C is wrong because `force-unlock` is a reactive measure, not preventive.
Option D is wrong because using local state would lose locking and central management.
A Terraform configuration includes a resource block with a 'lifecycle' block that has 'create_before_destroy = true'. During an apply, the create step succeeds but the destroy step fails. What is the resulting state?
New resource created; old resource not destroyed.
Why this answer
When `create_before_destroy = true` is set, Terraform creates the new resource first, then destroys the old one. If the destroy step fails after the new resource is created, both resources exist in the state file because Terraform does not remove the old resource from state until the destroy operation completes successfully. The state retains both resource instances at the same address, which is why option D is correct.
Exam trap
HashiCorp often tests the misconception that a failed destroy step automatically removes the old resource from state or that Terraform rolls back the entire operation, but in reality, Terraform only removes a resource from state after a successful destroy.
How to eliminate wrong answers
Option A is wrong because the old resource is not destroyed when the destroy step fails, so it remains in state alongside the new resource. Option B is wrong because the state is not empty; the new resource was successfully created and added to state, and the old resource is still present due to the failed destroy. Option C is wrong because the new resource was created and added to state before the destroy attempt, so both resources are recorded, not just the old one.
A Terraform state file is stored in an S3 bucket with versioning enabled. During a deployment, the state file becomes corrupted due to a network error. What is the best way to recover?
Versioning provides a quick rollback to a good state.
Why this answer
S3 versioning allows restoring previous state versions. Option B correct. Option A would destroy resources if state is deleted.
Option C pulls existing state, not helpful. Option D is too manual.
An organization stores state files in an S3 backend with encryption. However, some resource attributes (e.g., database passwords) are stored in plaintext within the state. What is the recommended approach to avoid storing sensitive values in state?
This ensures secrets are never written to state, only referenced.
Why this answer
Terraform can mark outputs as sensitive to hide them from display, but they may still be stored in state. Option A is a common practice to avoid storing secrets directly.
You are managing a Terraform configuration that uses a public module from the registry to deploy an AWS VPC. The module is defined with a version constraint of '~> 3.0'. After running 'terraform init', you run 'terraform plan' and notice that the plan output indicates the module will be updated from version 3.18.0 to 3.20.1. However, you are concerned because the module's changelog shows that version 3.19.0 introduced a breaking change: it removed the 'enable_dns_hostnames' variable and replaced it with 'enable_dns_support'. Your configuration currently uses the 'enable_dns_hostnames' variable. You want to avoid any breaking changes in the production environment while still receiving non-breaking updates. What should you do?
This pins to the 3.18.x range, avoiding the breaking change in 3.19.0 while still getting patch updates.
Why this answer
Option C is correct because the version constraint '~> 3.18.0' restricts updates to only patch versions within the 3.18.x series (e.g., 3.18.1, 3.18.2), which will never include the breaking change introduced in 3.19.0. This allows you to receive non-breaking bug fixes and security patches while avoiding the removal of the 'enable_dns_hostnames' variable. The pessimistic version constraint operator (~>) in Terraform locks the major and minor version when specified with three segments, ensuring no unexpected breaking changes from higher minor versions.
Exam trap
HashiCorp often tests the nuance of the pessimistic version constraint operator (~>) in Terraform, specifically that '~> 3.0' and '~> 3.18.0' have very different behaviors, and candidates mistakenly assume both only allow patch updates.
How to eliminate wrong answers
Option A is wrong because forking the module and maintaining a custom version introduces unnecessary overhead and defeats the purpose of using a public module; it also bypasses the version constraint mechanism entirely. Option B is wrong because the constraint '>= 3.0.0, < 3.19.0' would still allow Terraform to upgrade to any version from 3.0.0 up to 3.18.x, but running 'terraform init -upgrade' would upgrade to the latest allowed version (3.18.x), which is safe, but the constraint is overly broad and does not leverage the pessimistic operator for precise control; more importantly, it would not prevent a future upgrade to 3.19.0 if the upper bound were accidentally removed. Option D is wrong because updating the configuration to use 'enable_dns_support' and upgrading to 3.20.1 would require rewriting your code to adapt to the breaking change, which contradicts the goal of avoiding breaking changes in production.
Refer to the exhibit. A user runs `terraform state list` and receives the output shown. The configuration defines an `aws_instance.web` resource with count = 3 and an `aws_s3_bucket.data` resource. After some changes, the user runs `terraform plan` and sees that the plan wants to create a new `aws_instance.web[2]` and destroy the existing `aws_instance.web[2]`. What is the most likely cause?
Reducing then increasing count causes recreation of the highest index resource.
Why this answer
If count was reduced to 2 and then increased back to 3, Terraform will see the existing resource at index 2 as needing to be recreated because its address may have changed. Option A is the most likely. Option B could cause update in-place if no destroy, but create+destroy suggests index reassignment.
Option C is unlikely. Option D is unrelated.
A developer wants to use a module from the Terraform Registry in their configuration. Which block is required in the root module?
Correct syntax for calling a module.
Why this answer
Option B is correct because modules are called using the 'module' block with a 'source' argument. Option A is a provider block used for providers. Option C is a data source.
Option D is a resource block.
Which TWO statements about Terraform modules are correct?
Correct: modules can be invoked multiple times with different inputs.
Why this answer
Option A is correct because a module can be called multiple times with different inputs. Option E is correct because Git URLs with a commit SHA are valid module sources. Option B is incorrect because version constraints are optional.
Option C is incorrect because count and for_each are supported on module blocks. Option D is incorrect because module outputs must be explicitly referenced.
Which THREE statements accurately describe Terraform state? (Select THREE.)
State keeps track of resource metadata to associate real resources with config.
Why this answer
Options A, B, and D are correct. By default, state is stored locally. Remote backends enable sharing state among team members.
State maps real-world resources to configuration for tracking. Option C is false because state may contain sensitive data but not by default—only if resources have sensitive attributes. Option E is false because state locking must be explicitly supported by the backend (e.g., S3 with DynamoDB).
During a terraform apply, the process crashes mid-way. The state file may be in an inconsistent state. What is the first recommended step to recover?
terraform plan shows the current state and what changes would be made, helping to assess the situation.
Why this answer
Option C is correct because running terraform plan will show the current state and the pending changes, allowing you to diagnose the situation. Option A is wrong because re-running apply may fail again or cause further issues. Option B is wrong because terraform destroy would remove all resources, not just the half-created ones.
Option D is wrong because force-unlock is only for lock issues, not state inconsistency.
A team is migrating from using local state to a remote backend for collaboration. They want to ensure that team members cannot overwrite each other's changes. Which feature should they enable?
Locking prevents simultaneous applies.
Why this answer
State locking prevents concurrent modifications by ensuring that only one operation can modify the Terraform state at a time. When using a remote backend like S3 with DynamoDB, Terraform acquires a lock before writing to the state file and releases it after completion, preventing race conditions and state corruption.
Exam trap
HashiCorp often tests the distinction between state locking (preventing concurrent writes) and state versioning (enabling rollback), causing candidates to confuse S3 versioning as a solution for overwrite prevention.
How to eliminate wrong answers
Option B is wrong because S3 bucket versioning tracks changes and allows recovery of previous state versions, but does not prevent concurrent writes or overwrites. Option C is wrong because the force unlock command is a manual override to release a stuck lock, not a feature to prevent overwrites. Option D is wrong because workspace isolation separates state files for different environments but does not coordinate access within the same workspace.
During 'terraform apply', a user receives an error: 'Error: Error creating resource: Resource already exists'. The resource does not appear in the Terraform state. What is the most likely cause?
If the resource already exists in the cloud provider but not in state, Terraform will try to create it and fail.
Why this answer
Option D is correct because the error 'Resource already exists' indicates that the resource was created outside of Terraform's management (e.g., manually via the cloud console or CLI). Since the resource does not appear in the Terraform state, Terraform attempts to create it during 'terraform apply', but the underlying API rejects the request because the resource already exists in the cloud provider. This is a common state drift scenario where the real-world infrastructure is out of sync with the Terraform state.
Exam trap
HashiCorp often tests the misconception that 'terraform refresh' can fix state drift issues like this, but refresh only updates existing state attributes—it does not import unmanaged resources into the state, so the apply will still fail.
How to eliminate wrong answers
Option A is wrong because migrating a state file from a different backend would not cause a 'Resource already exists' error during apply; it would either succeed or fail with state-related conflicts, not an API-level duplicate resource error. Option B is wrong because if a resource was removed from configuration but not from state, 'terraform apply' would not attempt to create it—it would simply leave the resource in state and unmanaged, not trigger a creation error. Option C is wrong because 'terraform refresh' updates the state file to match real-world resources, but it does not prevent the 'Resource already exists' error; the error occurs because Terraform tries to create a resource that already exists, and refresh alone does not import that resource into state.
During development, a Terraform user wants to check that their configuration is syntactically valid and internally consistent before running 'terraform plan'. Which command should they use?
Validates configuration syntax and internal logic.
Why this answer
The `terraform validate` command checks that a Terraform configuration is syntactically valid and internally consistent, such as verifying that resource names are unique and that references to other resources or data sources are correctly formed. It runs without requiring any cloud provider credentials or state, making it ideal for early-stage validation before `terraform plan`.
Exam trap
HashiCorp often tests the distinction between validation and formatting, so the trap here is that candidates confuse `terraform fmt` (which only fixes code style) with `terraform validate` (which checks for actual errors in the configuration).
How to eliminate wrong answers
Option A is wrong because `terraform init` initializes the working directory by downloading provider plugins and modules, but it does not validate the configuration's syntax or internal consistency. Option B is wrong because `terraform refresh` updates the state file with real-world infrastructure, which requires existing state and credentials, and it does not perform configuration validation. Option D is wrong because `terraform fmt` rewrites configuration files to a canonical format and style, but it does not check for syntactic or semantic validity.
Which three of the following are valid methods for reading, generating, or modifying Terraform configuration? (Choose three.)
Why this answer
The `terraform fmt` command rewrites configuration files to a canonical format and style, which is a valid method for modifying configuration. The `templatefile` function reads a template file and renders it with supplied variables, enabling dynamic configuration generation. The `terraform console` command provides an interactive shell for evaluating expressions and inspecting resource attributes, which is a valid way to read and test configuration logic.
Exam trap
HashiCorp often tests the distinction between state manipulation commands and configuration generation commands, leading candidates to confuse `terraform state push` (a state management operation) with a method to modify configuration, or to incorrectly assume `terraform plan` has a `-generate-config-out` flag when it is actually `terraform import` that supports this feature.
Practice TF-003 by domain
Target a specific domain to shore up weak areas.