HashiCorp Terraform Associate TF-003 (TF-003) — Questions 451519

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

Page 6

Page 7 of 7

451
MCQmedium

A company wants to manage its infrastructure as code using Terraform. The team has a mix of on-premises servers and cloud resources in AWS and Azure. Which of the following best describes Terraform's purpose in this scenario?

A.Terraform is a configuration management tool for installing software on existing servers.
B.Terraform is a cloud-specific orchestration tool that only works with AWS.
C.Terraform is a monitoring and logging tool for cloud resources.
D.Terraform is an infrastructure-as-code tool for provisioning and managing any infrastructure across multiple providers.
AnswerD

Correctly defines Terraform's purpose.

Why this answer

Option D is correct because Terraform is explicitly designed as an infrastructure-as-code tool that uses declarative configuration files to provision and manage resources across multiple providers, including on-premises servers (via providers like vSphere or Hyper-V) and cloud platforms like AWS and Azure. Its provider model allows it to abstract away the underlying APIs, making it provider-agnostic and suitable for hybrid environments.

Exam trap

HashiCorp often tests the misconception that Terraform is a configuration management tool (like Ansible) or that it is limited to a single cloud provider, so candidates must remember that Terraform is a provisioning tool for infrastructure resources across multiple providers, not for software configuration or monitoring.

How to eliminate wrong answers

Option A is wrong because Terraform is not a configuration management tool like Ansible, Puppet, or Chef; it does not install software or manage state on existing servers—it provisions infrastructure resources. Option B is wrong because Terraform is not cloud-specific; it supports over 100 providers, including AWS, Azure, GCP, and on-premises solutions, through its plugin-based architecture. Option C is wrong because Terraform does not perform monitoring or logging; tools like CloudWatch, Azure Monitor, or Prometheus handle those tasks, while Terraform focuses on the lifecycle (create, read, update, delete) of infrastructure resources.

452
MCQeasy

A junior DevOps engineer is learning about Infrastructure as Code (IaC) and asks why Terraform is preferred over manual configuration in cloud consoles. Which of the following is the primary benefit of using Terraform for infrastructure management?

A.It can only manage infrastructure on major cloud providers like AWS, Azure, and GCP.
B.It automatically rolls back any failed infrastructure changes.
C.It enables version-controlled, repeatable, and automated infrastructure provisioning.
D.It uses an imperative approach where you specify exact commands to execute.
AnswerC

IaC allows infrastructure to be managed as code, enabling versioning, review, and automation.

Why this answer

Option C is correct because Terraform's core value proposition is enabling infrastructure as code (IaC), which allows teams to define infrastructure in declarative configuration files, version control them with Git, and provision consistently across environments. This repeatability and automation eliminate the drift and manual errors inherent in clicking through cloud consoles, making infrastructure management auditable, collaborative, and scalable.

Exam trap

The trap here is that candidates confuse declarative (Terraform) with imperative (e.g., Ansible or shell scripts) approaches, or assume Terraform's state management includes automatic rollback, when in fact it only provides a plan and requires explicit user action to revert changes.

How to eliminate wrong answers

Option A is wrong because Terraform is not limited to major cloud providers; it uses a plugin-based provider architecture that supports hundreds of providers, including on-premises solutions like VMware, OpenStack, and custom APIs via the Terraform Provider SDK. Option B is wrong because Terraform does not automatically roll back failed changes; it creates a state file to track resources and can detect drift, but rollbacks require manual intervention or a separate 'terraform destroy' and re-apply of a previous configuration. Option D is wrong because Terraform uses a declarative approach, not imperative; you define the desired end state in HCL (HashiCorp Configuration Language), and Terraform determines the necessary actions to reach that state, unlike imperative tools that require step-by-step commands.

453
MCQmedium

Based on the exhibit, what can be inferred about the Terraform state and configuration?

A.The aws_instance.db resource is in state but not in configuration, so it will be destroyed.
B.The configuration for aws_instance.db has been added back to the .tf files.
C.The aws_instance.db resource was manually deleted from the AWS console.
D.The aws_instance.web resource is being imported into Terraform management.
AnswerA

Terraform plans to destroy resources that are in state but removed from configuration.

Why this answer

The `terraform plan` output shows that `aws_instance.db` exists in the state file but is absent from the current configuration. Terraform interprets this as a resource that should be removed to align the real-world infrastructure with the configuration, so it will be destroyed. This is a core behavior of Terraform's desired-state management: any resource in state but not in configuration is marked for deletion.

Exam trap

HashiCorp often tests the distinction between resources missing from configuration (destroy) versus resources missing from the real world (re-create), and the trap here is confusing manual deletion with configuration removal.

How to eliminate wrong answers

Option B is wrong because if the configuration for `aws_instance.db` had been added back, the plan would show an update or no change, not a destroy. Option C is wrong because manual deletion from the AWS console would cause Terraform to detect the resource as missing and plan to re-create it, not destroy it. Option D is wrong because importing a resource would produce a plan that shows the resource being added to state without a destroy action, and the exhibit shows a destroy, not an import.

454
Multi-Selectmedium

Which TWO scenarios could cause 'terraform plan' to show 'No changes' even though the configuration file was recently modified? (Choose two.)

Select 2 answers
A.The user ran 'terraform plan' from a different directory that does not contain the modified configuration.
B.A lifecycle block with ignore_changes was applied to the modified attribute.
C.The resource was manually updated in the cloud provider console.
D.A new resource block was added.
E.The provider version was changed in the required_providers block.
AnswersA, B

Plan only reads .tf files from the current directory.

Why this answer

Option A is correct because `terraform plan` operates on the configuration files in the current working directory. If the user runs the command from a different directory that does not contain the modified configuration, Terraform will compare the state against the unmodified files in that directory, resulting in 'No changes'. Option B is correct because a `lifecycle` block with `ignore_changes` tells Terraform to disregard changes to specified attributes when planning, so even if the configuration file modifies that attribute, Terraform will not detect a diff and will report 'No changes'.

Exam trap

HashiCorp often tests the misconception that manual cloud console changes always cause plan output to show changes, but the trap here is that `ignore_changes` can suppress those diffs, and running `terraform plan` from the wrong directory can cause the command to read unmodified files, both leading to a false 'No changes' result.

455
Multi-Selectmedium

Which three practices help maintain consistency and reduce configuration drift in IaC? (Choose three.)

Select 3 answers
A.Storing state files remotely and locking them
B.Implementing CI/CD pipelines with automated testing
C.Regularly running terraform plan and apply
D.Using manual changes to fix minor issues
E.Allowing multiple team members to run apply simultaneously
AnswersA, B, C

Remote state with locking prevents concurrent modifications that could cause drift.

Why this answer

Regularly running terraform plan/apply (B) enforces desired state. Storing state remotely with locking (D) prevents concurrent modifications. CI/CD pipelines with automated testing (E) validate changes.

A is wrong because manual changes cause drift. C is wrong because simultaneous applies cause conflicts.

456
MCQeasy

A developer runs terraform apply to create an AWS EC2 instance using an AMI sourced from the aws_ami data source with most_recent = true. Immediately after apply completes, the developer runs terraform plan again. The plan shows that Terraform intends to replace the EC2 instance. What is the most likely cause?

A.A new AMI was released after the apply, causing the data source to return a different AMI ID.
B.The developer did not run terraform init before the second plan.
C.The instance type was changed in the configuration between apply and plan.
D.The Terraform state file was corrupted during the apply.
AnswerA

Correct. The most_recent = true causes the data source to fetch the latest AMI each plan, so a new AMI release will change the value, triggering replacement.

Why this answer

The data source with most_recent = true fetches the latest AMI each time plan runs. If a new AMI is released after the apply, the AMI ID changes, forcing replacement of the EC2 instance because the AMI change requires resource replacement.

457
Multi-Selectmedium

A team runs terraform plan and sees changes that are unexpected. Which TWO actions should they take to investigate before applying?

Select 2 answers
A.Run terraform providers mirror to ensure provider versions are consistent.
B.Save the plan with terraform plan -out=plan.tfplan and then use terraform show plan.tfplan to examine details.
C.Delete the state and re-import all resources.
D.Manually edit the state file to match the configuration.
E.Revert the configuration to the previous commit and re-run plan.
AnswersA, B

Inconsistent provider versions can cause unexpected drift.

Why this answer

Options B and D are correct. Option B: terraform show with a saved plan file reveals detailed changes. Option D: terraform providers mirror can help verify provider versions are consistent.

Option A is wrong because reverting may lose intended changes. Option C is wrong because manual state editing is risky. Option E is wrong because deleting state would lose all management.

458
Multi-Selecthard

A team uses an S3 backend for state storage with DynamoDB locking. They want to migrate to a new S3 bucket. Which two steps are necessary to perform a successful state migration? (Choose two.)

Select 2 answers
A.Run `terraform plan` to verify no resource changes before migration.
B.Delete the old state file after migration.
C.Run `terraform init -reconfigure` to update the backend configuration.
D.Manually copy the state file from the old bucket to the new bucket.
E.Update the `backend` block in the Terraform configuration with the new bucket name.
AnswersC, E

This command initializes the new backend and copies state.

Why this answer

To migrate state to a new backend, update the backend configuration (D) and run `terraform init -reconfigure` (A) to initialize the new backend and copy state automatically. Option B is not needed because `init` copies state. Option C is dangerous.

Option E is good practice but not necessary.

459
MCQmedium

A team is using Terraform to manage infrastructure across multiple environments (dev, test, prod). They want to reuse the same configuration but vary resource configurations like instance size and number of instances. Which Terraform feature should they use?

A.Separate directories with symlinks
B.Remote backends with different state files
C.Terraform modules with variables
D.Terraform workspaces
AnswerC

Correct. Modules allow you to create a reusable component and call it with different variable values per environment, typically via separate root modules or variable files.

Why this answer

Terraform modules with variables allow you to define reusable infrastructure and pass environment-specific variable values. This is the recommended approach for code reuse across environments.

460
MCQmedium

A team has two resources: an AWS security group and an EC2 instance that uses it. Terraform does not automatically detect the dependency. Which argument should be added to the instance resource?

A.depends_on = [aws_security_group.sg.*]
B.depends_on = aws_security_group.sg
C.depends_on = [aws_security_group.sg]
D.depends_on = [aws_security_group.sg.id]
AnswerC

Correctly specifies the dependency as a list of resource addresses.

Why this answer

Correct D: depends_on requires a list of resource addresses. Option D is correct syntax. Others are incorrect.

461
MCQeasy

When running `terraform plan`, an engineer sees that Terraform proposes to destroy an existing resource even though the configuration file appears unchanged. What is the most likely cause?

A.The resource's `count` or `for_each` meta-argument was removed from the configuration
B.Another user ran `terraform destroy` without the engineer's knowledge
C.The state file was corrupted and lost the resource
D.The resource was manually deleted from the cloud provider console
AnswerA

Correct! Removing the count or for_each reduces the number of instances, leading to planned destruction.

Why this answer

Option A is correct because removing the `count` or `for_each` meta-argument from a resource block causes Terraform to interpret the resource as no longer being managed by the configuration. Since Terraform tracks resources by their logical address in the state, the absence of the meta-argument means the existing resource (previously indexed, e.g., `resource.name[0]`) no longer matches any configuration block, so Terraform plans to destroy it. This is a common source of unexpected destruction when the resource count is reduced or the loop construct is removed entirely.

Exam trap

HashiCorp often tests the misconception that state corruption or manual deletion causes destruction plans, but the trap here is that candidates overlook how removing `count` or `for_each` changes the resource address, leading to an unexpected destroy without any change to the resource's own attributes.

How to eliminate wrong answers

Option B is wrong because if another user ran `terraform destroy`, the resource would already be removed from the state and infrastructure, so Terraform would not propose to destroy it again; instead, it would show a creation plan if the configuration still exists. Option C is wrong because a corrupted state file would typically cause Terraform to fail with an error or show all resources as new additions, not specifically target a single existing resource for destruction. Option D is wrong because if a resource is manually deleted from the cloud provider console, Terraform would detect the drift and plan to recreate it, not destroy it again.

462
MCQhard

A large organization uses Terraform to manage hundreds of AWS resources across multiple accounts. They have a central repository with modules for common patterns. A new engineer is tasked with adding a new feature that requires modifying the configuration of an existing S3 bucket to enable server-side encryption. The current configuration for the bucket is defined in a module that is used by many other teams. The engineer adds an `aws_s3_bucket_server_side_encryption_configuration` resource as recommended by the latest AWS provider. After running `terraform plan`, they see that the plan will create the new encryption resource but also shows an in-place update to the bucket itself. They check the bucket resource and see that it has a `server_side_encryption_configuration` argument that is deprecated. The engineer wants to ensure backward compatibility and avoid breaking other teams' configurations. What is the best course of action?

A.Use the deprecated `server_side_encryption_configuration` argument in the bucket resource to avoid adding a new resource.
B.Coordinate with the module maintainers to update the module, using the new encryption resource and removing the deprecated argument in a later release.
C.Proceed with the plan as is, since the in-place update is expected during migration.
D.Add a `lifecycle` block with `create_before_destroy` to the new encryption resource to prevent destruction.
AnswerB

ensures backward compatibility via module versioning

Why this answer

Option D is correct because using the new separate resource is the modern approach, and migrating from the old argument requires careful coordination. The best course is to implement the change using the new resource and update the module's version, communicating the change. Option A is wrong because using the deprecated argument is not recommended.

Option B is wrong because the plan already shows the correct approach; ignoring the plan might cause issues. Option C is wrong because forcing recreation might break other teams.

463
Multi-Selecthard

Which TWO of the following are valid ways to reference a resource attribute in Terraform?

Select 2 answers
A.`module.vpc.output`
B.`data.aws_ami.ubuntu.id`
C.`var.instance_type`
D.`module.vpc.vpc_id`
E.`aws_instance.web.id`
AnswersD, E

Correct: references the vpc_id output from module vpc.

Why this answer

Option D is correct because `module.vpc.vpc_id` directly references an output attribute from a module. In Terraform, module outputs are accessed using the syntax `module.<module_name>.<output_name>`, and `vpc_id` is a common output from VPC modules that exposes the ID of the created VPC resource.

Exam trap

HashiCorp often tests the distinction between resource attributes, data source attributes, module outputs, and input variables, and the trap here is that candidates confuse data source references (like `data.aws_ami.ubuntu.id`) with resource attribute references, or they think `module.vpc.output` is a valid catch-all syntax for module outputs.

464
MCQeasy

A developer has a Terraform configuration that includes an output block. They run `terraform apply` and then want to quickly retrieve the output value without re-running the entire apply. Which command should they use?

A.terraform plan
B.terraform state list
C.terraform show
D.terraform output
AnswerD

quickly retrieves output values from state

Why this answer

Option B is correct because `terraform output` displays the output values from the current state. Option A is wrong because `terraform show` shows the state or plan file but is not the quickest for just outputs. Option C is wrong because `terraform state list` lists resources.

Option D is wrong because `terraform plan` does not output values.

465
MCQhard

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

A.Amend the previous commit and force push
B.Create a new commit with the fix
C.Use the 'Queue Plan' button in the Terraform Cloud UI
D.Run terraform plan locally and apply
AnswerC

Re-runs plan with the same commit.

Why this answer

Option C is correct because the 'Queue Plan' button in Terraform Cloud allows you to trigger a new speculative plan for the same commit without modifying the VCS history or creating a new commit. This is the intended workflow for re-running a plan after fixing configuration errors in a VCS-backed workspace, as it uses the existing commit but re-evaluates the configuration.

Exam trap

The trap here is that candidates may confuse the 'Queue Plan' button with simply re-running a failed plan, but HashiCorp often tests whether you understand that Terraform Cloud's VCS workflow requires a new commit for configuration changes, while 'Queue Plan' is only for re-running the same configuration without changes.

How to eliminate wrong answers

Option A is wrong because amending the previous commit and force pushing rewrites Git history, which can disrupt team collaboration and is not a recommended practice for fixing a failed run in Terraform Cloud; it also does not leverage Terraform Cloud's built-in run management. Option B is wrong because creating a new commit with the fix would trigger a new run automatically, but the question specifically asks to re-run the plan without committing again, making this an unnecessary and incorrect approach. Option D is wrong because running terraform plan locally and applying bypasses Terraform Cloud's VCS-backed workflow, state management, and collaboration features, and the apply would not be tracked or approved through Terraform Cloud's run pipeline.

466
Drag & Dropmedium

Drag and drop the steps to manage Terraform state locking with a backend 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

Backend config must include locking mechanism; init sets up backend, apply uses lock.

467
MCQhard

A team uses Terraform with multiple workspaces and wants to automatically trigger a plan when a pull request is opened in their Git repository. They use Terraform Cloud. Which feature enables this?

A.VCS-driven workflow
B.API-driven workflow
C.CLI-driven workflow
D.Registry-driven workflow
AnswerA

Automatically runs plans on PRs.

Why this answer

Option B is correct because the VCS-driven workflow in Terraform Cloud automatically runs speculative plans on pull requests. Options A, C, and D are incorrect because they require manual triggering or are not workflows.

468
Multi-Selectmedium

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

Select 3 answers
.Using `terraform import` to bring existing infrastructure under Terraform management.
.Using `terraform state push` to manually upload a state file to a remote backend.
.Using `terraform plan -out=tfplan` to generate a plan file for later application.
.Using `terraform console` to interactively evaluate expressions in the Terraform language.
.Using `terraform validate` to check configuration syntax before any state operations.
.Using `terraform fmt` to automatically rewrite configuration files into a canonical format.

Why this answer

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

Exam trap

HashiCorp often tests the distinction between commands that are part of the core provisioning workflow (validate, plan, apply, destroy) and those that are auxiliary or administrative (import, state manipulation, plan file generation), leading candidates to mistakenly include `validate` or `fmt` as 'outside the core workflow' when they are actually preparatory steps within it.

469
MCQmedium

A company uses Terraform to manage infrastructure across multiple AWS accounts. They want to use a single S3 bucket to store state files for all accounts, but ensure that state files are isolated per account. What is the best approach?

A.Use Terraform workspaces with a single state file
B.Use separate state files with unique S3 key prefixes per account
C.Store all state in the same S3 key
D.Use a DynamoDB table with different lock IDs per account
AnswerB

Unique key prefixes ensure each account has its own state file.

Why this answer

Option B is correct because using separate state files with unique S3 key prefixes per account ensures that each AWS account's Terraform state is stored in the same S3 bucket but logically isolated. This approach leverages S3's hierarchical key structure to prevent cross-account state contamination, while still allowing centralized management. Terraform's backend configuration supports dynamic key prefixes (e.g., `key = "account-${var.account_id}/terraform.tfstate"`), enabling per-account isolation without requiring separate buckets or workspaces.

Exam trap

The trap here is that candidates confuse Terraform workspaces with true state isolation across accounts, not realizing that workspaces only provide logical separation within a single backend path and do not prevent cross-account state conflicts when using a shared S3 bucket.

How to eliminate wrong answers

Option A is wrong because Terraform workspaces store state files within the same backend path (same S3 key) by default, using a directory-like structure (e.g., `env:/workspace_name`), which does not provide true isolation per AWS account—state files can still be accidentally overwritten or accessed across workspaces if the backend key is not carefully managed. Option C is wrong because storing all state in the same S3 key would cause all accounts to share a single state file, leading to conflicts, corruption, and inability to manage separate infrastructure stacks. Option D is wrong because DynamoDB lock IDs are used for state locking and consistency, not for isolating state files per account; different lock IDs do not prevent state file collisions when multiple accounts write to the same S3 key.

470
MCQhard

Refer to the exhibit. A developer runs terraform plan and sees "No changes". However, the developer knows that manual changes were made to the infrastructure outside Terraform. What is the most likely reason terraform plan does not detect the drift?

A.The manual changes were made to resources not managed by Terraform.
B.Terraform only detects drift when running terraform apply.
C.The manual changes were reverted before the plan was run.
D.Terraform plan does not refresh state by default; it uses the existing state file.
AnswerD

By default, terraform plan runs a refresh to update state before planning, but if the refresh is skipped or fails, drift may not be detected.

Why this answer

Terraform plan compares the state file to the configuration. If the state file does not reflect manual changes (because it was not refreshed), terraform plan may not detect drift unless -refresh-only or a refresh is performed.

471
MCQhard

Refer to the exhibit. A user runs terraform init and receives an error about state data content. The state file in S3 has not been manually modified. What is the most likely cause?

A.The S3 bucket policy denies access to the state file.
B.Terraform version mismatch between local and state file.
C.The state file is locked by another process.
D.The state file was written by a different Terraform workspace.
AnswerD

When a state file is written by another workspace, the serial number may not match, causing this error.

Why this answer

The error indicates that the state file content does not match what Terraform expects. This can happen when the state file has a different serial number (e.g., if another process wrote to it) or if the state file is corrupted. However, since the user hasn't manually modified it, the most likely cause is that the state file was modified by a different Terraform process (perhaps from another workspace or different version) that changed the state structure.

Option D is correct because a conflicting workspace can write state with a different serial, causing the error.

472
MCQhard

After running terraform apply, you see the error: 'Error: Error loading state: state snapshot was created by Terraform v0.12.0, but this is Terraform v1.2.0'. What should you do to resolve this?

A.Run terraform state upgrade
B.Run terraform apply with no changes to upgrade the state format
C.Delete the state file and reimport resources
D.Downgrade Terraform to v0.12.0
AnswerB

Running terraform apply will upgrade the state to the current version.

Why this answer

Option B is correct because running `terraform apply` with no changes triggers Terraform to automatically upgrade the state file format to the version compatible with the current Terraform binary (v1.2.0). Terraform state files are versioned internally, and when a newer version of Terraform reads an older state format, it performs an in-place upgrade during the next state write operation, such as an apply that results in no changes. This avoids manual intervention or data loss.

Exam trap

HashiCorp often tests the misconception that there is a dedicated `terraform state upgrade` command, leading candidates to choose Option A, but Terraform handles state format upgrades implicitly during apply operations, not via a separate command.

How to eliminate wrong answers

Option A is wrong because `terraform state upgrade` is not a valid Terraform command; the correct command for upgrading state format is `terraform apply` with no changes or `terraform init -upgrade` for provider upgrades, not a dedicated state upgrade command. Option C is wrong because deleting the state file and reimporting resources is unnecessarily destructive and error-prone; it would require manual re-import of every resource, losing any existing state metadata and risking configuration drift. Option D is wrong because downgrading Terraform to v0.12.0 is a backward step that would lose access to features and fixes in v1.2.0, and it does not resolve the version mismatch; the state file would still be in the older format and would need to be upgraded eventually.

473
MCQeasy

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

A.The S3 bucket does not have versioning enabled.
B.The DynamoDB table is not configured correctly.
C.The state file is corrupted.
D.Another Terraform run is currently in progress.
AnswerD

State lock is held by another process.

Why this answer

Option C is correct because the error indicates that the state lock cannot be acquired, meaning another process holds the lock. Options A and B would cause different errors. Option D is unlikely.

474
MCQmedium

The above configuration references a module from the Terraform Registry. After running 'terraform init', the user runs 'terraform plan' and gets an error: 'Error: Unsupported argument' for 'version'. What is the most likely cause?

A.The 'version' argument is not supported for this module because the source is not a registry module.
B.The 'version' argument must be specified as a constraint like '>= 3.19.0' instead of an exact version.
C.The module source is from a Git repository, which does not support the 'version' argument.
D.The 'version' argument should be placed inside a 'required_providers' block.
AnswerA, C

The version argument is only valid for registry modules. If the source is misconfigured, Terraform might treat it as a non-registry source.

Why this answer

The error 'Unsupported argument' for 'version' occurs because the module source is not from a Terraform Registry. The 'version' argument is only valid when the source is a registry module (e.g., 'hashicorp/consul/aws'). If the source is a local path, Git URL, or other non-registry source, Terraform does not support the 'version' argument, as versioning is managed by the registry's metadata.

Exam trap

HashiCorp often tests the distinction between registry and non-registry module sources, trapping candidates who assume the 'version' argument is universally supported across all module source types.

How to eliminate wrong answers

Option B is wrong because the 'version' argument can accept both exact versions and constraint strings like '>= 3.19.0'; the error is not about the format of the version string but about the argument being unsupported entirely. Option D is wrong because the 'version' argument for a module is placed in the module block, not inside a 'required_providers' block, which is used for provider version constraints.

475
Drag & Dropmedium

Drag and drop the steps to use Terraform workspaces for environment separation 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

Workspaces isolate state; create, select, set variables, then plan and apply.

476
MCQhard

A team is using Terraform with multiple environments (dev, staging, prod) and wants to use separate state files. They are considering workspaces. A senior engineer suggests using separate directory structures instead of workspaces for prod. What is the strongest reason for this recommendation?

A.Workspaces share the same backend configuration, increasing the risk of accidental changes to production.
B.Workspaces cannot isolate state files.
C.Workspaces make it harder to refactor configurations.
D.Workspaces do not support state locking.
AnswerA

With workspaces, all states are in the same backend; misconfiguration could target prod from dev workspace.

Why this answer

Workspaces share the same backend configuration, meaning all workspaces (including prod) use the same state storage location and access controls. This increases the risk of accidental changes to production because a single backend misconfiguration or a mistaken workspace switch can lead to unintended modifications to the production state file. Separate directory structures allow for independent backend configurations, enabling stricter access controls and isolation for production.

Exam trap

HashiCorp often tests the misconception that workspaces provide full isolation, when in fact they only isolate state file keys, not the backend configuration or access controls, making separate directories safer for production environments.

How to eliminate wrong answers

Option B is wrong because workspaces do isolate state files by storing them under the same backend with a workspace-specific key, but they do not isolate the backend configuration itself. Option C is wrong because workspaces do not inherently make refactoring harder; in fact, they can simplify configuration reuse across environments. Option D is wrong because workspaces fully support state locking via the backend (e.g., DynamoDB for S3), just like separate directories.

477
MCQhard

When running terraform plan, the output indicates that a resource will be replaced (destroy then create) due to a change in the 'name' attribute. However, the engineer only changed a tag. What is the most likely cause?

A.The tag change triggered a ForceNew attribute.
B.The resource has create_before_destroy enabled.
C.The 'name' attribute is computed and any change to the resource forces replacement.
D.The underlying API does not support in-place updates.
AnswerC

Some providers mark certain attributes as ForceNew; if name is ForceNew, any config change to the resource may trigger replacement.

Why this answer

Option C is correct: the 'name' attribute may be ForceNew, meaning any change forces replacement. Option A is wrong because create_before_destroy does not cause this. Option B is wrong because tags are not typically ForceNew.

Option D is wrong because underlying SDK may not trigger replacement for tags.

478
MCQeasy

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

A.Terraform import
B.Local state with .gitignore
C.Terraform Cloud remote state
D.terraform state push
AnswerC

Secure and accessible by pipeline runs.

Why this answer

Using a remote state backend (like Terraform Cloud) ensures state is stored securely and can be accessed by pipeline runs. Local state with .gitignore is not secure or accessible. Terraform import is for adding existing resources, not state storage. terraform state push is used to manually upload state.

479
MCQhard

In a CI/CD pipeline, Terraform state is stored in Terraform Cloud. A pipeline run fails with the error: 'State version conflict'. What is the most likely cause?

A.Authentication failure with Terraform Cloud
B.Missing or incorrect backend configuration
C.State file exceeds maximum size limit
D.Terraform version mismatch between local and remote
E.Two runs started at the same time
AnswerB

A state version conflict can occur if the backend configuration is misconfigured, leading to mismatched state versions.

Why this answer

A state version conflict typically occurs when two runs attempt to modify the state simultaneously, even if Terraform Cloud serializes runs. This can happen if a run is triggered while another is still in progress.

480
MCQhard

A company uses Terraform to manage infrastructure on AWS. They have a configuration that creates an S3 bucket and a DynamoDB table for state locking. The team notices that sometimes when two members run terraform apply simultaneously, they get a state locking error. However, they want to allow concurrent operations on different workspaces. What is the best approach?

A.Remove the DynamoDB table and use local state files to avoid locking issues.
B.Configure all team members to use the same workspace so that only one person can apply at a time.
C.Keep the current setup because the error is harmless and users can retry.
D.Use separate state files per workspace and ensure each workspace has its own lock entry in DynamoDB; the current setup already supports this.
AnswerD

Workspaces use separate state files and DynamoDB locks per state file, allowing concurrent operations on different workspaces.

Why this answer

Option D is correct because Terraform natively supports per-workspace state files, and when using a remote backend like S3 with DynamoDB for state locking, each workspace's state file is stored at a distinct path in S3. The DynamoDB lock entry is tied to the specific state file path via the LockID, so concurrent operations on different workspaces acquire separate locks and do not conflict. This setup allows multiple team members to run terraform apply simultaneously as long as they are working in different workspaces.

Exam trap

HashiCorp often tests the misconception that DynamoDB locking is global across all workspaces, when in fact the lock is scoped to the specific state file path, which includes the workspace name.

How to eliminate wrong answers

Option A is wrong because removing the DynamoDB table and using local state files eliminates state locking entirely, which can lead to state corruption if multiple users apply changes concurrently, even on different workspaces. Option B is wrong because configuring all team members to use the same workspace defeats the purpose of allowing concurrent operations and forces serialization of all applies, reducing team productivity. Option C is wrong because the state locking error is not harmless; it indicates a real conflict that can cause corruption or inconsistent state if ignored, and simply retrying does not address the underlying need for concurrent workspace-level isolation.

481
MCQhard

A DevOps engineer runs terraform plan and sees that a resource will be destroyed and recreated, but they expected an in-place update. The resource is an AWS EC2 instance with a specific AMI. Which attribute change is most likely causing the destruction?

A.The AMI ID was changed.
B.The security group list was modified.
C.The tags were updated.
D.The instance type was reduced from large to micro.
AnswerA

AMI changes force a new instance because the root volume is tied to the AMI.

Why this answer

Option A is correct. Changing the AMI ID typically forces replacement of an EC2 instance because the underlying image changes. Option B (security groups) can be updated in-place.

Option C (tags) are modifiable without replacement. Option D (instance type) can be changed in-place if the instance is stopped (though plan may show in-place); but generally AMI changes force new.

482
MCQmedium

A team is using a module from the Terraform Registry. They want to ensure that changes to the module's source version are tested in a non-production environment before being applied to production. Which approach best supports this workflow?

A.Fork the module repository and manage the module internally as a private module.
B.Pin the module to an exact version (e.g., version = "1.2.3") and update it manually after testing in isolation.
C.Configure the module source to reference the latest commit from the default branch of the repository.
D.Use a version constraint like ~> 1.0 in the module configuration and test the module in a non-production workspace before promoting to production.
AnswerD

This allows controlled updates and testing before production.

Why this answer

Option D is correct because using a version constraint like `~> 1.0` allows Terraform to automatically select the latest compatible patch version within the specified minor version range. This enables safe, incremental updates that can be tested in a non-production workspace first, and then promoted to production by simply applying the same configuration. The constraint ensures that breaking changes (major version bumps) are not automatically pulled in, giving the team control over when to adopt them.

Exam trap

HashiCorp often tests the misconception that pinning to an exact version (Option B) is the safest approach for controlled testing, but the question specifically asks for a workflow that supports testing changes *before* production, which the pessimistic constraint enables automatically without manual version bumps.

How to eliminate wrong answers

Option A is wrong because forking the module repository and managing it internally as a private module adds significant overhead and defeats the purpose of using a public registry module; it also bypasses the version constraint workflow entirely. Option B is wrong because pinning to an exact version (e.g., version = "1.2.3") requires manual updates and does not automatically test newer compatible versions in a non-production environment before promotion. Option C is wrong because referencing the latest commit from the default branch introduces uncontrolled, potentially breaking changes directly into the configuration, with no versioning or testing gate before production.

483
Drag & Dropmedium

Drag and drop the steps to use Terraform modules from the registry 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

Registry modules are sourced; init downloads, variables configure, plan/apply deploy.

484
MCQeasy

Which of the following commands creates an execution plan that shows what resources will be created, updated, or destroyed?

A.terraform apply
B.terraform plan
C.terraform output
D.terraform destroy
E.terraform validate
AnswerB

Correct: Plan shows what will happen.

Why this answer

Option B is correct because `terraform plan` shows the changes without applying. Option A is wrong because `terraform apply` also creates a plan but applies it. Option C is wrong because `terraform destroy` creates a destroy plan.

Option D is wrong because `terraform validate` checks syntax. Option E is wrong because `terraform output` shows outputs.

485
Multi-Selectmedium

Which four of the following are valid techniques for reading, generating, or modifying Terraform configuration? (Choose all that apply. There are four correct answers.)

Select 4 answers
.Using the `templatefile` function to render a template with variables from the current configuration.
.Using `terraform console` to evaluate expressions and generate valid HCL configuration output.
.Using `terraform state pull` to retrieve remote state and then using `terraform state mv` to rename a resource address in the local state file before pushing it back.
.Using a `data` source with a `for_each` and a `local` value to dynamically generate resource blocks based on a variable input.
.Using the `jsonencode` function within a `local` value to programmatically construct a JSON string that is then used as part of a resource argument.
.Using `terraform validate` to check configuration syntax and internal consistency before applying changes.

Why this answer

The `templatefile` function is a valid technique for reading and generating configuration because it reads an external template file and renders it with variables from the current Terraform configuration, producing a string that can be used in resource arguments or other expressions. This is a core feature for dynamic configuration generation, such as injecting user data into cloud-init scripts or generating complex configuration files for provisioned resources.

Exam trap

HashiCorp often tests the distinction between commands that modify configuration versus those that only validate or inspect state, so candidates may incorrectly select `terraform validate` or `terraform console` as techniques for generating or modifying configuration when they are purely diagnostic or interactive tools.

486
MCQhard

Refer to the exhibit. A team member receives this error when running terraform apply. What is the most likely cause?

A.The state file is corrupted and needs to be restored from backup.
B.Another user is currently running terraform apply on the same state.
C.The S3 bucket containing the state has been deleted.
D.A previous Terraform process was terminated abruptly, leaving a stale lock.
AnswerD

The "OperationTypeInvalid" indicates the lock was not properly released.

Why this answer

The lock info shows an operation type "OperationTypeInvalid", which typically occurs when a previous Terraform process was terminated abruptly (e.g., Ctrl+C, crash), leaving the lock in place.

487
MCQmedium

Given the plan output, how is the module 'instances' configured in the root module?

A.The root module uses for_each in the module block with a map variable.
B.The module uses count with a list variable.
C.The module is declared twice with different names.
D.The module contains a resource with for_each inside.
AnswerA

for_each on a module block creates multiple module instances, each keyed by the map keys, allowing different variable values per instance.

Why this answer

Option D is correct because for_each with a map creates one instance per key, and each instance can have different variables like ami and instance_type. Option A is wrong because count would show index numbers, not keys. Option B is wrong because using module multiple times would show different module addresses.

Option C is wrong because a module with a single resource but for_each inside would still show one instance per key.

488
MCQeasy

A team wants to use a networking module from the public Terraform Registry. They need to ensure they always get the latest patch version within the 1.2.x series. Which version constraint should they use in the module block?

A.version = "= 1.2.0"
B.version = ">= 1.2.0, < 2.0.0"
C.version = ">= 1.2.0"
D.version = "~> 1.2"
AnswerD

Allows only patch version updates within the 1.2.x series, e.g., 1.2.0 to 1.2.9.

Why this answer

The ~> 1.2 constraint allows only patch version updates (e.g., 1.2.0 to 1.2.9), which matches the requirement. Option A is wrong because = 1.2.0 pins to an exact version, not allowing patch updates. Option C is wrong because >= 1.2.0, < 2.0.0 allows minor version updates (e.g., 1.3.0), which is too broad.

Option D is wrong because >= 1.2.0 allows any version 1.2.0 or higher, including 2.0.0.

489
MCQeasy

You are a platform engineer at a growing startup. The company currently manages infrastructure manually by SSH-ing into servers to install packages and update configurations. As the team grows, this approach has led to frequent configuration drift, inconsistent environments, and manual errors. Deploying a new environment takes several days and requires detailed runbooks. The CTO has asked you to propose a solution that improves consistency, reduces deployment time, and enables version control of infrastructure. You are evaluating Infrastructure as Code (IaC) tools like Terraform. Which course of action best addresses the CTO's requirements?

A.Improve SSH key management and use configuration management tools like Ansible to apply changes.
B.Migrate all applications to containers and use Kubernetes for orchestration.
C.Adopt Terraform to define all infrastructure as code, store configurations in a Git repository, and use a CI/CD pipeline to apply changes automatically.
D.Create more detailed runbooks and require peer review for all manual changes.
AnswerC

Declarative IaC with automation addresses all requirements.

Why this answer

Option C is correct because Terraform directly addresses the CTO's requirements by enabling infrastructure as code (IaC), which ensures consistent, repeatable deployments through declarative configuration files stored in Git for version control. Using a CI/CD pipeline to automatically apply changes eliminates manual SSH errors, reduces deployment time from days to minutes, and prevents configuration drift by enforcing a single source of truth for infrastructure state.

Exam trap

HashiCorp often tests the distinction between configuration management tools (like Ansible) and infrastructure provisioning tools (like Terraform), trapping candidates who confuse managing software on existing servers with defining and versioning the infrastructure itself.

How to eliminate wrong answers

Option A is wrong because improving SSH key management and using Ansible for configuration management still relies on imperative, agent-based execution against existing servers, which does not provide the declarative, version-controlled infrastructure provisioning that Terraform offers; it also does not inherently prevent configuration drift across environments. Option B is wrong because migrating to containers and Kubernetes addresses application deployment and orchestration, not the underlying infrastructure provisioning (e.g., VMs, networks, storage), and introduces unnecessary complexity for a startup that has not yet solved basic infrastructure consistency. Option D is wrong because creating more detailed runbooks and requiring peer review only reduces manual errors marginally but does not automate provisioning, eliminate configuration drift, or enable version control of infrastructure; it perpetuates the slow, error-prone manual process.

490
MCQeasy

After running `terraform plan`, a developer sees the following line in the output: `Plan: 1 to add, 0 to change, 0 to destroy.` What does this indicate?

A.One resource will be destroyed.
B.No changes will be made.
C.One resource will be changed.
D.One resource will be created.
AnswerD

"to add" indicates creation

Why this answer

Option B is correct because the plan shows one resource will be created, none modified, none destroyed. Option A is wrong because it says add, not change. Option C is wrong because there is no change or destroy.

Option D is wrong because there is an add.

491
MCQhard

A user receives the error shown in the exhibit when running `terraform init`. The user is behind a corporate proxy. Which environment variable should be set to resolve this issue?

A.TF_VAR_proxy=http://proxy:8080
B.AWS_ACCESS_KEY_ID
C.HTTP_PROXY=http://proxy:8080
D.TF_LOG=DEBUG
AnswerC

Configures proxy for HTTP requests.

Why this answer

Option C is correct because Terraform uses the standard `HTTP_PROXY` environment variable to route HTTP/HTTPS requests through a corporate proxy when downloading providers and modules. Setting `HTTP_PROXY=http://proxy:8080` instructs Terraform's underlying HTTP client to connect via the specified proxy, resolving the connectivity error during `terraform init`.

Exam trap

HashiCorp often tests the distinction between Terraform-specific environment variables (like `TF_VAR_`) and standard system proxy variables, leading candidates to mistakenly choose `TF_VAR_proxy` as a Terraform-native proxy setting.

How to eliminate wrong answers

Option A is wrong because `TF_VAR_proxy` is not a recognized environment variable in Terraform; the `TF_VAR_` prefix is used to set input variables, not proxy configuration. Option B is wrong because `AWS_ACCESS_KEY_ID` is an AWS credential variable unrelated to proxy settings; it would not fix a network connectivity issue caused by a proxy. Option D is wrong because `TF_LOG=DEBUG` enables verbose logging for debugging but does not configure proxy routing; it only increases log output without addressing the underlying proxy requirement.

492
MCQhard

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

A.The DynamoDB table lacks sufficient read/write capacity; increase it.
B.The same workspace is being used for concurrent runs; use separate workspaces per environment.
C.The pipeline is running too many jobs; increase the lock wait time.
D.The S3 bucket is not versioned; enable versioning.
AnswerB

Different workspaces have independent state locks.

Why this answer

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

Option B correctly identifies this as the most likely cause and solution.

Exam trap

HashiCorp often tests the misconception that DynamoDB capacity or S3 versioning are the root cause of lock errors, when the real issue is workspace-level contention in concurrent pipelines.

How to eliminate wrong answers

Option A is wrong because DynamoDB read/write capacity is not the issue; the lock error is about contention, not throughput limits, and increasing capacity would not resolve concurrent access to the same lock item. Option C is wrong because increasing the lock wait time (e.g., via the `-lock-timeout` flag) only delays the failure, it does not prevent the underlying conflict of multiple jobs trying to lock the same workspace state. Option D is wrong because S3 bucket versioning is unrelated to state locking; versioning protects against accidental deletion or corruption of state files, but does not affect DynamoDB lock acquisition.

493
MCQmedium

Refer to the exhibit. What does this output indicate?

A.A resource will be modified
B.A resource will be destroyed
C.No changes
D.A resource will be created
AnswerA

1 to change indicates an existing resource will be updated.

Why this answer

The plan shows 0 resources to add, 1 to change, and 0 to destroy, meaning an existing resource will be modified.

494
MCQhard

An organization uses Terraform Cloud to manage infrastructure across multiple teams. They need to enforce that all workspaces use a specific version of Terraform and that no workspace can be deleted accidentally. Which approach meets these requirements without using Sentinel or Terraform Enterprise?

A.Include `required_version` in each workspace's root module and configure workspace locks in the UI.
B.Set `required_providers` with version constraints in a global Terraform file.
C.Use the Terraform Cloud API to write an OPA policy that enforces Terraform version and prevents workspace deletion.
D.Configure version constraints in the Terraform Cloud workspace settings and enable deletion protection.
AnswerC

OPA policies can enforce version requirements and protect workspaces from deletion.

Why this answer

Option C is correct because the Terraform Cloud API allows you to write OPA (Open Policy Agent) policies that can enforce Terraform version constraints and prevent workspace deletion, even without Sentinel or Terraform Enterprise. OPA policies are evaluated during runs and API calls, providing a flexible, code-based approach to governance that meets both requirements.

Exam trap

HashiCorp often tests the distinction between built-in Terraform Cloud features (like workspace settings) and external policy engines (like OPA), leading candidates to assume that UI-based settings can enforce deletion protection when they cannot.

How to eliminate wrong answers

Option A is wrong because `required_version` in a root module only enforces the Terraform version at plan/apply time, not across all workspaces globally, and workspace locks in the UI prevent concurrent operations but do not prevent accidental deletion. Option B is wrong because `required_providers` with version constraints controls provider versions, not the Terraform CLI version, and does not address workspace deletion prevention. Option D is wrong because Terraform Cloud workspace settings allow you to set a Terraform version per workspace, but there is no built-in 'deletion protection' toggle; deletion protection requires Sentinel or OPA policies via the API.

495
Multi-Selecthard

Which THREE files are considered part of the standard module structure?

Select 3 answers
A.main.tf
B.outputs.tf
C.backend.tf
D.terraform.tfvars
E.variables.tf
AnswersA, B, E

Main resource definitions are typically in main.tf.

Why this answer

The standard module structure includes main.tf, variables.tf, and outputs.tf. Option C is wrong because terraform.tfvars is used to assign values, not part of module definition. Option E is wrong because backend.tf is for state configuration, which belongs in the root module.

496
Multi-Selectmedium

Which TWO statements about Terraform's handling of input variables are true?

Select 2 answers
A.All variables must be assigned a value before running terraform plan.
B.Variable values cannot be overridden using environment variables.
C.The terraform.tfvars file is automatically loaded by Terraform.
D.Default values for variables can only be set using a .tfvars file.
E.Variables can be declared in a .tf file using the 'variable' block.
AnswersC, E

Terraform automatically loads terraform.tfvars and any .auto.tfvars files in the root module directory.

Why this answer

Option A is correct because variables are declared using the 'variable' block in .tf files. Option C is correct because Terraform automatically loads terraform.tfvars. Option B is incorrect because variables can have defaults and are not required to be assigned before plan.

Option D is incorrect because environment variables with TF_VAR_ prefix can override variable values. Option E is incorrect because default values are set in the variable block, not in .tfvars files.

497
Multi-Selectmedium

Which three statements correctly describe concepts of Infrastructure as Code (IaC) as implemented by Terraform? (Choose three.)

Select 3 answers
.IaC enables consistent and repeatable provisioning of infrastructure by defining resources in declarative configuration files.
.With IaC, infrastructure changes can be version-controlled, reviewed, and rolled back using the same workflows as application code.
.Terraform's execution plan is a key IaC feature that allows you to preview changes before applying them, reducing the risk of unintended modifications.
.In Terraform, the desired state is described imperatively, meaning you specify the exact commands to create, modify, or delete resources in order.
.Terraform relies on a mutable infrastructure model, where changes are applied directly to existing resources without destroying and recreating them.
.IaC eliminates the need for manual configuration entirely by automatically detecting and fixing all configuration drift without human intervention.

Why this answer

The first three options are correct because they accurately describe core IaC principles as implemented by Terraform. IaC uses declarative configuration files to define infrastructure, enabling consistent and repeatable provisioning. Version control of these files allows changes to be reviewed and rolled back like application code.

Terraform's execution plan is a critical feature that previews changes before applying them, reducing risk of unintended modifications.

Exam trap

HashiCorp often tests the distinction between declarative and imperative approaches, and the trap here is that candidates may incorrectly assume Terraform uses imperative syntax because they confuse 'desired state' with 'step-by-step commands'.

498
MCQhard

A large enterprise uses Terraform Cloud with remote execution mode to manage infrastructure across multiple AWS accounts. Each environment (dev, staging, prod) has a separate workspace. The security team requires that all changes to production must be approved by a senior engineer before applying. Additionally, developers should be able to plan changes in production to preview the impact, but not apply them. The current setup uses the same Terraform Cloud team membership for all workspaces. When a developer runs a plan in production, the plan succeeds but they are unable to apply. However, the security team notices that the developer can accidentally apply if they quickly approve their own plan via the UI because the workspace is configured with 'Auto Apply' enabled. The security team wants to enforce the approval process without removing the developer's ability to plan. Which combination of changes should be made? (Select only one option.)

A.Keep 'Auto Apply' enabled but restrict the production workspace to only the infrastructure lead's Terraform Cloud account.
B.Use run triggers to promote runs from dev to staging to production, and only the lead can promote to production.
C.Disable 'Auto Apply' on the production workspace and configure team permissions so that developers have 'plan' role and the infrastructure lead has 'write' role.
D.Use VCS branch restrictions to only allow applies from the 'main' branch, and have developers plan from feature branches.
AnswerC

This enforces manual approval and restricts apply permissions.

Why this answer

Option C is correct because disabling 'Auto Apply' on the production workspace ensures that no apply occurs without explicit approval. Configuring team permissions so that developers have the 'plan' role (which allows running plans but not applying) and the infrastructure lead has the 'write' role (which allows applying) enforces the required approval process while preserving the developer's ability to preview changes via plan.

Exam trap

HashiCorp often tests the distinction between run triggers (which automate promotion) and manual approval workflows, leading candidates to incorrectly choose run triggers as a solution for approval enforcement when they actually bypass manual approval.

How to eliminate wrong answers

Option A is wrong because keeping 'Auto Apply' enabled would still allow applies to happen automatically after a plan, bypassing the approval process; restricting to the lead's account does not prevent a developer from triggering a plan that auto-applies. Option B is wrong because run triggers are designed to chain runs between workspaces (e.g., promoting from dev to staging to prod) but do not enforce a manual approval step before applying in production; they automate the promotion, not the approval. Option D is wrong because VCS branch restrictions control which branches can trigger runs, but they do not prevent a developer from applying a plan if they have apply permissions; the developer could still apply from the 'main' branch if they have the appropriate role, and the scenario requires that developers cannot apply at all.

499
Multi-Selecteasy

Which TWO are benefits of using Terraform modules?

Select 2 answers
A.Encapsulation of complexity, providing a clean interface.
B.Faster execution of terraform plan and apply.
C.Reusability of infrastructure configurations across projects.
D.Reduction in state file size.
E.Enhanced security by automatically encrypting state files.
AnswersA, C

Modules hide internal details and expose only necessary inputs and outputs.

Why this answer

Modules promote reusability and encapsulation of complex infrastructure components. Option C is wrong because modules do not inherently improve performance; they add overhead. Option D is wrong because modules are not specifically for security; they can be used for any resource.

Option E is wrong because modules do not reduce state file size; they may increase it.

500
MCQeasy

A DevOps team is using Terraform Cloud to manage infrastructure. They want to integrate Terraform into their CI/CD pipeline by triggering runs programmatically. Which approach should they use to invoke a Terraform run from an external system?

A.Use the Terraform Cloud API to trigger a run.
B.Set up a webhook from the VCS provider to trigger runs.
C.Configure a remote backend to automatically run apply.
D.Execute 'terraform apply -auto-approve' in the CI pipeline.
AnswerA

The API allows programmatic triggering of runs, suitable for CI/CD integration.

Why this answer

The Terraform Cloud API provides a programmatic endpoint to trigger runs, allowing external CI/CD systems to initiate Terraform operations without manual intervention. This is the correct approach because it directly invokes a run with full control over variables, configuration versions, and apply strategies, aligning with the requirement to integrate Terraform into a CI/CD pipeline programmatically.

Exam trap

HashiCorp often tests the distinction between event-driven triggers (VCS webhooks) and programmatic API calls, where candidates mistakenly choose webhooks because they seem 'automated,' but the question explicitly requires programmatic invocation from an external system, not a VCS event.

How to eliminate wrong answers

Option B is wrong because setting up a webhook from the VCS provider triggers runs automatically on code changes, not programmatically from an external CI/CD system; it is event-driven, not API-driven. Option C is wrong because configuring a remote backend does not trigger runs—it only stores state remotely and enables remote execution, but the run must be initiated separately. Option D is wrong because executing 'terraform apply -auto-approve' in the CI pipeline is a local CLI command that bypasses Terraform Cloud's run management, state locking, and policy checks, and it does not integrate with Terraform Cloud's API or remote execution capabilities.

501
MCQhard

A team uses Terraform with a remote backend that stores state in Azure Storage. A developer runs terraform apply and receives an error: 'Error refreshing state: state data in Azure Blob does not have expected content.' What is the most likely cause?

A.The Azure Storage account access key has expired.
B.The blob name contains uppercase letters.
C.The Terraform version is incompatible with the backend.
D.The state file was manually edited.
AnswerD

Correct. Manual editing can corrupt the JSON structure, leading to 'unexpected content' errors.

Why this answer

This error indicates that the state file has been corrupted or tampered with. Common causes include manual editing of the state file or a failed state operation.

502
MCQhard

A team has an existing S3 bucket created outside Terraform. They want to manage it with Terraform by importing its state. Which of the following is the correct sequence of commands to read the bucket's configuration and avoid drift?

A.Run terraform refresh, then terraform state pull to generate configuration.
B.Run terraform plan, note the resource address, then run terraform import.
C.Run terraform import, then terraform state show to generate configuration.
D.Write a minimal resource configuration, run terraform import, then terraform plan, then adjust configuration to match state.
AnswerD

This is the standard workflow: import into existing config, then use plan to detect differences and update config.

Why this answer

Option C is correct: first write a minimal resource block, then import, then run terraform plan to detect drift, then adjust config to match. Option A is wrong because terraform import requires a configuration to exist. Option B is wrong because terraform plan before import will show nothing.

Option D is wrong because terraform refresh alone does not create a state entry for unmanaged resources.

503
MCQhard

A developer runs terraform plan and sees a large number of resources will be destroyed. They suspect the state file is corrupted. They have a recent backup of the state file. Which command can help recover the previous state from the backup?

A.terraform state push
B.No command can recover; they must re-import all resources.
C.terraform state rm
D.terraform state pull
AnswerA

Correct. terraform state push writes a state file to the remote backend, allowing restoration from a backup file.

Why this answer

The terraform state push command uploads a local state file to the remote backend, overwriting the current state. This can be used to restore a backup.

504
MCQhard

Refer to the exhibit. A developer runs terraform plan and receives this error. What should the developer do to resolve the error?

A.Run terraform plan again; the error will self-resolve after a few minutes.
B.Run terraform init -migrate-state to migrate the state to the new region.
C.Update the backend configuration in the Terraform code to match the previous region.
D.Run terraform state rm to remove the state file and start fresh.
AnswerB

This command reinitializes the backend and migrates the existing state to the new backend configuration.

Why this answer

The error indicates that the backend configuration has changed (the region changed from us-east-1 to us-west-2). Terraform requires re-initialization when backend configuration changes.

505
MCQhard

An organization uses Terraform with remote state stored in S3 and DynamoDB for state locking. During a plan, they receive the error: 'Error acquiring the state lock: ConditionalCheckFailedException: The conditional request failed'. What is the most likely cause?

A.The state file in S3 is corrupted.
B.The DynamoDB table is not configured with a primary key named LockID.
C.The S3 bucket does not have versioning enabled.
D.Another Terraform process is currently running and holds the state lock.
AnswerD

Lock acquisition fails because another process holds the lock.

Why this answer

Option C is correct because the error indicates the state lock cannot be acquired because another process holds the lock. Options A and B are configuration issues that would cause different errors. Option D is unlikely; a corrupted state file would cause other errors.

506
MCQhard

A company uses Terraform to manage infrastructure across dev, staging, and production environments. They use Terraform workspaces to separate state files. The backend is configured with an S3 bucket for state storage and a DynamoDB table for state locking. Recently, the team has grown from 2 to 10 developers, and they frequently encounter the error: 'Error acquiring the state lock' when running terraform apply in quick succession. The error message includes: 'Lock Info: ID: ... Operation: Apply. Who: user@company.com. Version: 1.0.0. Created: ...' The error occurs intermittently, especially during peak deployment times. The DynamoDB table is configured with 5 read and 5 write capacity units. The team's current workflow involves multiple developers running apply on different workspaces simultaneously. Which course of action should the team take to minimize state locking errors?

A.Disable state locking to eliminate the error.
B.Increase the DynamoDB table's write capacity units to a higher value.
C.Use a different backend that does not support locking, such as local state.
D.Implement a pre-apply hook that checks if the state is already locked and waits.
AnswerB

Correct. Higher write capacity reduces lock acquisition timeouts, especially with concurrent applies.

Why this answer

Increasing DynamoDB write capacity reduces contention and lock acquisition failures during concurrent applies. Option B (implementing a pre-apply hook) is not standard and could add complexity. Options A and D disable locking, which is dangerous.

507
Multi-Selectmedium

Which THREE are part of Terraform's core workflow? (Choose three.)

Select 3 answers
A.Apply
B.Import
C.Plan
D.Destroy
E.Write
AnswersA, C, E

Apply executes the plan.

Why this answer

The core Terraform workflow consists of Write (author configuration), Plan (preview changes), and Apply (execute changes). Destroy is a subcommand of Apply, and Import is a separate command for bringing existing resources under management.

508
MCQmedium

A team uses remote state stored in an S3 bucket with DynamoDB locking. A developer wants to read the current state outputs locally without making changes. Which command should they use?

A.terraform output
B.terraform state pull
C.terraform console
D.terraform plan
AnswerA

output retrieves outputs from the state without acquiring a lock.

Why this answer

Option B is correct because terraform output retrieves outputs from the state without any lock or plan. Option A is wrong because terraform plan acquires a lock and might show planned changes. Option C is wrong because terraform state pull downloads the entire state file, which is overkill and also acquires a lock.

Option D is wrong because terraform console does not directly show outputs.

509
MCQeasy

A team uses the backend configuration above. What is the primary benefit of storing state remotely in S3?

A.Automatic encryption of state files
B.Reducing the number of API calls to AWS
C.Enabling state sharing and locking across the team
D.Faster Terraform execution times
AnswerC

Remote backend allows multiple users to access and lock state.

Why this answer

Storing Terraform state remotely in S3 is the standard practice for team collaboration because it allows multiple team members to access and modify the same state file, preventing conflicts. Combined with DynamoDB for state locking, it ensures that only one person runs `terraform apply` at a time, avoiding race conditions and state corruption. This is the primary benefit over local state storage, which is single-user by design.

Exam trap

HashiCorp often tests the misconception that remote state is about performance (faster execution) or security (automatic encryption), when the actual core purpose is enabling safe, concurrent team collaboration through state sharing and locking.

How to eliminate wrong answers

Option A is wrong because S3 does not automatically encrypt state files by default; server-side encryption (SSE-S3 or SSE-KMS) must be explicitly configured in the backend block or bucket policy. Option B is wrong because storing state remotely in S3 does not reduce API calls to AWS; in fact, it may increase them due to state retrieval and locking operations. Option D is wrong because remote state storage typically increases execution time due to network latency for downloading/uploading the state file, not faster execution.

510
MCQhard

You are a DevOps engineer at a company that manages infrastructure for multiple environments (dev, staging, prod) using Terraform. The team has created a reusable module for deploying an AWS ECS Fargate service. The module accepts variables for environment name, container image tag, and desired count. The module is stored in a private Git repository. The root configurations for each environment are stored in separate directories, each with its own backend configuration. Recently, a developer added a new feature to the module that requires a new variable 'enable_xray' (boolean, default false). After updating the module source to point to the new commit, the developer runs 'terraform init' and 'terraform plan' in the dev environment. The plan shows that the ECS service will be updated, but the output does not show any changes related to X-Ray. The developer expected that setting 'enable_xray = true' in the dev root module would enable X-Ray tracing. However, the plan shows no changes to the task definition. What is the most likely cause?

A.The module source was not updated correctly; it still points to the old commit.
B.The developer forgot to run 'terraform init' after changing the module source.
C.The variable 'enable_xray' is not declared in the module's variables.tf file.
D.The module does not reference the 'enable_xray' variable in any resource, so setting it has no effect.
AnswerD

The variable was added but not used in the module's resources, so no changes occur.

Why this answer

Option D is correct because the `enable_xray` variable, even when set to `true` in the root module, will not cause any changes in the plan unless the module's resources actually reference that variable. In Terraform, a variable declared in a module has no effect on infrastructure unless it is used in a resource argument. The developer saw no changes to the task definition because the module's code likely does not include a condition or argument that uses `enable_xray` to enable X-Ray tracing on the ECS task definition.

Exam trap

The trap here is that candidates assume declaring a variable and setting its value automatically triggers infrastructure changes, but Terraform only applies changes when the variable is actually consumed by a resource argument.

How to eliminate wrong answers

Option A is wrong because if the module source still pointed to the old commit, `terraform init` would not fetch the new variable definition, but the developer already ran `terraform init` and the plan showed an update to the ECS service, indicating the new module version was loaded. Option B is wrong because the developer explicitly ran `terraform init` after updating the module source, so the module was correctly initialized. Option C is wrong because the variable `enable_xray` is declared in the module's `variables.tf` (as stated in the scenario: 'requires a new variable'), and the developer set it to `true` in the root module; the issue is not the declaration but the lack of usage in resources.

511
Multi-Selecteasy

Which TWO of the following are valid methods for importing existing infrastructure into Terraform management? (Choose two.)

Select 2 answers
A.Use terraform apply directly on existing resources
B.Use a third-party tool like Terraformer to generate configuration
C.Use terraform state push to manually add state entries
D.Write configuration for the resource and use terraform import
E.Use terraform import without any prior configuration
AnswersB, D

Generates HCL configuration from existing resources, then import.

Why this answer

The typical method is to write configuration and run terraform import. Third-party tools can generate configuration from existing resources. terraform import requires configuration beforehand. terraform state push is not for importing; it pushes a state file. terraform apply would try to create new resources.

512
Multi-Selectmedium

Which THREE of the following are characteristics of Terraform state? (Choose three.)

Select 3 answers
A.It can be stored remotely to enable team collaboration
B.It contains the entire Terraform configuration
C.It maps real-world resources to your configuration
D.It includes metadata such as resource dependencies
E.It stores the provider source code
AnswersA, C, D

Correct: Remote state backends allow sharing.

Why this answer

Option A (state maps real-world resources to configuration), Option C (state can be stored remotely for collaboration), and Option D (state includes metadata like dependencies) are correct. Option B is wrong because state does not include provider source code; it only references providers. Option E is wrong because state does not contain the full configuration; only resource attributes and metadata.

513
MCQmedium

A team uses a remote state backend with partial configuration. They have a `backend` block with only the `bucket` attribute, and the rest of the backend configuration is provided via CLI during `terraform init`. Which of the following best describes the purpose of partial configuration?

A.It reduces the number of files needed for configuration.
B.It is required when using Terraform Cloud.
C.It enables state locking.
D.It allows sensitive backend configuration to be provided dynamically, avoiding hardcoding.
AnswerD

This is the main benefit of partial configuration.

Why this answer

Partial configuration allows passing backend settings via CLI or environment variables, preventing hardcoded secrets. Option A correct. Others are not primary purposes.

514
MCQhard

Your organization uses Terraform Cloud with a remote execution mode. There are two workspaces: `app-prod` and `app-staging`. The state for `app-prod` is stored in the `prod` workspace, and `app-staging` in the `staging` workspace. Recently, a new developer joined the team and tried to run `terraform plan` locally for the `app-staging` workspace. They received an error: "S3Backend bucket 'my-company-tf-state' does not exist." The developer is not using Terraform Cloud locally. The team uses a remote backend configuration with Terraform Cloud. What is the most likely cause?

A.The developer forgot to run `terraform workspace select staging`
B.The Terraform Cloud workspace `app-staging` is not set to use remote state
C.The developer lacks AWS credentials to access the S3 bucket
D.The developer is running Terraform locally without having the correct backend configuration; they should run `terraform init -reconfigure` to reinitialize backend settings for local execution
AnswerD

If the backend is pointing to a non-existent S3 backend (e.g., misconfigured), reinit fixes it.

Why this answer

If the developer is running Terraform locally without Terraform Cloud, they need to reconfigure the backend to local state or use the remote backend properly. Option D correctly identifies that the developer should use `terraform init -reconfigure` to set up the remote backend locally.

515
MCQhard

A company manages multiple microservices across AWS accounts. Each service has its own Terraform configuration and state file stored in a shared S3 bucket. The team uses `terraform_remote_state` data sources to read outputs from other services' state files. A service team recently changed the output structure in their state, breaking the `terraform_remote_state` calls from other services. The affected services now show errors during plan. What is the best practice to avoid such cross-service dependency issues?

A.Publish service outputs to a dedicated data store (e.g., AWS SSM Parameter Store or Consul) and have other services consume those values instead of reading state directly
B.Use versioning on the S3 bucket and revert to a previous state version
C.Lock the state files and require approval for any changes
D.Store outputs in a configuration management database and read from there
AnswerA

This decouples dependencies and uses a stable API.

Why this answer

Cloud-native integration patterns with explicit contracts (like SSM Parameter Store) are more robust than raw state reading. Option D is correct.

516
Multi-Selecthard

Which TWO statements about Terraform module structure and best practices are correct? (Choose two.)

Select 2 answers
A.A module should define variables for any values that need to be customized by the calling configuration.
B.A module should assume the calling configuration will provide all necessary provider configurations.
C.A module must have all Terraform code in a single main.tf file.
D.A module can be sourced from the same repository as the root module using a relative path.
E.A module should rely on direct attribute references to resources in the calling configuration.
AnswersA, D

This is a best practice for reusability.

Why this answer

Option A is correct because Terraform modules are designed to be reusable and configurable. By defining input variables for any customizable values (e.g., resource names, sizes, regions), the module abstracts away hardcoded details and allows the calling configuration to pass in specific values via variable assignments. This follows the principle of encapsulation, where the module's internal logic remains unchanged while its behavior adapts to the caller's needs.

Exam trap

HashiCorp often tests the misconception that modules must be stored in separate repositories or that they cannot reference resources from the calling configuration, but the real trap is that candidates confuse 'direct attribute references' (which are forbidden) with 'outputs' (which are the correct way to expose values), leading them to select option E as correct.

517
MCQmedium

A team uses Terraform to manage multiple environments (dev, staging, prod) with a shared networking module. The module defines a variable 'cidr_block' with no default. In the root module, they have a file dev.tfvars containing 'cidr_block = "10.0.0.0/16"'. When running 'terraform plan' while in the dev workspace, they receive: 'Error: No value for required variable cidr_block'. They have already run 'terraform init' and confirmed the workspace is 'dev'. What is the most likely cause and correct action?

A.They forgot to include the -var-file flag; add -var-file='dev.tfvars' to the plan command.
B.The variable is defined in the child module; they need to reference it with module.cidr_block in the root module.
C.The workspace is not selected; run 'terraform workspace select dev' again.
D.The variable must be passed through the module block; they should add a module input assignment.
AnswerA

Terraform does not automatically load arbitrary .tfvars files; using -var-file explicitly loads it.

Why this answer

The error indicates the variable file is not being loaded. The most common reason is that the -var-file flag was omitted. Option B fixes this by explicitly specifying the variable file.

Option A is incorrect because the variable is in the module, and root module can pass it via module block, but the variable is already defined in the module. Option C is incorrect because passing via module block is the correct way, but the error suggests the variable file is not being read at all. Option D is incorrect because the workspace is already set correctly.

518
MCQhard

A platform team manages a large Terraform codebase with hundreds of resources across multiple environments (dev, staging, prod). They use terraform workspaces to manage environment-specific state files. Recently, an engineer made changes to the production workspace but forgot to switch from the dev workspace before applying. The apply was successful, but now the production resources are in an inconsistent state. The team wants to recover the production state to match the actual infrastructure. The previous state file for production was backed up in an S3 bucket before the accidental apply. What is the best course of action?

A.Use terraform state mv to correct the state entries by mapping resources from the backup to the current state
B.Use terraform import to manually import each production resource based on the backup state
C.Use terraform workspace select prod then terraform apply with the backup state file
D.Use terraform state push with the backup state file to overwrite the current state
AnswerD

State push restores the previous state from a local file.

Why this answer

Option D is correct because terraform state push allows a local state file to be pushed to the remote backend, effectively replacing the current state. The team can then run terraform plan to verify. Option A is incorrect because terraform state mv is for renaming resources, not restoring full state.

Option B is incorrect because terraform apply with a state file is not a standard operation. Option C is incorrect because manual import would be time-consuming and error-prone.

519
MCQeasy

A developer wants to use Terraform in a CI pipeline where the pipeline runs on pull requests. They need to preview infrastructure changes without applying them. Which command should be used?

A.terraform plan
B.terraform validate
C.terraform init
D.terraform apply
AnswerA

Plan shows what will be created/changed/destroyed.

Why this answer

Option A is correct because `terraform plan` creates an execution plan that shows what actions Terraform will take to change infrastructure to match the configuration, without actually applying any changes. This is the standard command for previewing infrastructure changes in a CI pipeline triggered by pull requests, enabling developers to review proposed modifications before merging.

Exam trap

HashiCorp often tests the distinction between validation and planning, so the trap here is that candidates confuse `terraform validate` (syntax check) with `terraform plan` (infrastructure preview), assuming validation alone is sufficient to preview changes.

How to eliminate wrong answers

Option B is wrong because `terraform validate` checks only the syntactic correctness and internal consistency of Terraform configuration files, not the actual state or planned changes against real infrastructure. Option C is wrong because `terraform init` initializes the working directory by downloading providers and modules, but does not generate any preview of infrastructure changes. Option D is wrong because `terraform apply` executes the planned changes and modifies real infrastructure, which is the opposite of a preview-only operation and should not be used in a pull request pipeline without prior approval.

Page 6

Page 7 of 7

All pages