Courseiva

HashiCorp Terraform Associate TF-003 (TF-003) — Questions 376–450

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

Take a mock examExam hub

Data quality score: 85/100 — Review before indexing

1 error found across 75 questions. This page is set to noindex until issues are resolved.

Page 5

Page 6 of 7

Page 7
376
MCQhard

Your team uses Terraform to manage a multi-region AWS deployment consisting of over 500 resources. The state file is stored in an S3 backend with DynamoDB locking. Recently, one of your colleagues accidentally deleted the state file from S3 while trying to clean up old backups. Fortunately, you have a backup from two days ago. However, after restoring the backup, you notice that several recent changes, including two new EC2 instances and a security group, are missing from the state. The actual resources still exist in AWS. You need to bring the state back in sync with the real-world infrastructure without recreating these resources. What should you do?

A.Use `terraform import` for each missing resource to add them to state
B.Run `terraform apply` to recreate the missing resources
C.Manually edit the state file to add the missing resource entries
D.Run `terraform refresh` to update the state with the missing resources
AnswerA

Correct: Import adds existing resources to state.

Why this answer

Option C is correct because `terraform import` can be used to add existing resources to state. Option A is wrong because `terraform apply` with the missing resources in config will try to create them again and conflict. Option B is wrong because `terraform refresh` updates state for existing resources, but cannot add missing resources if they are not referenced in state.

Option D is wrong because manually editing the state file is error-prone and not recommended.

Full explanation →
377
MCQmedium

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

A.Serialize pipeline runs to avoid concurrent execution
B.Use force-unlock before each plan
C.Increase the lock timeout
D.Use -lock=false in the pipeline
AnswerA

Prevents concurrent runs, the root cause of locking conflicts.

Why this answer

The best practice is to prevent concurrent runs by serializing pipeline execution. Using -lock=false disables locking entirely, increasing lock timeout may help but doesn't address the root cause. force-unlock should only be used when the lock holder is known to have failed.

Full explanation →
378
Matchingmedium

Match each Terraform function to its category.

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

Concepts
Matches

List function

Map function

IP network function

Encoding function

Date and time function

Why these pairings

Terraform functions are grouped by type.

Full explanation →
379
MCQeasy

Which Terraform command is used to bring existing infrastructure that was created outside of Terraform under Terraform management?

A.terraform state push
B.terraform apply
C.terraform import
D.terraform refresh
AnswerC

Import is used to bring existing resources into Terraform state.

Why this answer

Option A is correct because 'terraform import' is specifically designed to import existing infrastructure into Terraform state. Option B is wrong because 'terraform state push' is for manually updating state. Option C is wrong because 'terraform apply' creates resources, not imports.

Option D is wrong because 'terraform refresh' updates state but does not import new resources.

Full explanation →
380
MCQeasy

A user wants to see the current state of resources in a human-readable format without making changes. Which command should they use?

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

Displays current state in human-readable format.

Why this answer

Option D, `terraform show`, is correct because it displays the current state of managed resources in a human-readable format (defaulting to plain text) without making any changes. This command reads the state file directly and presents its contents, making it ideal for inspection and debugging. Unlike `terraform plan`, it does not generate an execution plan or propose modifications.

Exam trap

HashiCorp often tests the distinction between commands that inspect state (`terraform show`, `terraform state list`) versus those that generate plans or modify state, and the trap here is confusing `terraform plan` (which can show proposed changes) with a read-only view of the current state.

How to eliminate wrong answers

Option A is wrong because `terraform output` only shows the values of defined output variables, not the full state of all resources. Option B is wrong because `terraform state list` merely lists resource addresses in the state without displaying their attributes or configuration details. Option C is wrong because `terraform plan` creates an execution plan that compares current state with configuration and can propose changes, which is not a read-only view of the current state.

Full explanation →
381
Multi-Selecthard

Which THREE are valid uses of the `terraform state` command? (Select THREE.)

Select 3 answers
A.Force unlock the state lock
B.Move a resource from one state file to another
C.Remove a resource from state without destroying it
D.List all resources tracked in the state
E.Import an existing resource into state
AnswersB, C, D

Correct! `terraform state mv` moves resources between states.

Why this answer

Option B is correct because `terraform state mv` allows you to move a resource from one state file to another, which is useful for refactoring configurations or splitting state files. This command updates the resource's address in the target state while preserving its tracked attributes and lifecycle.

Exam trap

HashiCorp often tests the distinction between the `terraform state` subcommands and other standalone commands like `terraform import` and `terraform force-unlock`, expecting candidates to know that only `list`, `mv`, and `rm` are valid `terraform state` operations.

Full explanation →
382
MCQmedium

You are a DevOps engineer at a growing startup. The infrastructure currently consists of a single AWS EC2 instance running a web application, manually configured. The company plans to scale to multiple instances and environments (development, staging, production). They want to adopt Infrastructure as Code using Terraform. The team has limited experience with Terraform and wants to start small, then gradually adopt more advanced features. The current manual infrastructure must be imported into Terraform. The team also wants to ensure that code changes are reviewed via pull requests before being applied. Which of the following is the best course of action to meet these requirements?

A.Install Terraform on the existing instance, run terraform init and apply directly to manage it, and store state locally. Have team members share the state file via a shared folder.
B.Write Terraform configuration from scratch to match the existing instance, but do not import; instead, destroy the old instance and recreate it with Terraform.
C.Create separate Git branches for each environment (dev, staging, prod) and have each team member work independently on their branch, merging occasionally.
D.Create a Git repository with a main branch. Write a minimal Terraform configuration that describes the existing EC2 instance. Use terraform import to bring the instance under Terraform management. Store the state file remotely in S3 with DynamoDB locking. Set up a CI pipeline that runs terraform plan on pull requests and requires approval before merging.
AnswerD

This approach imports existing infrastructure, uses remote state for team access, and enforces code review through PRs.

Why this answer

Option D is correct because it follows the best practices for adopting Infrastructure as Code with Terraform in a team setting. It starts by writing a minimal configuration that matches the existing EC2 instance, uses `terraform import` to bring it under management without downtime, stores state remotely in S3 with DynamoDB locking for collaboration and consistency, and sets up a CI pipeline to run `terraform plan` on pull requests with approval gates, ensuring code review before changes are applied.

Exam trap

HashiCorp often tests the misconception that you must destroy and recreate infrastructure to adopt IaC, or that local state sharing is acceptable for teams, when in fact `terraform import` and remote state with locking are the correct approaches for zero-downtime adoption and collaboration.

How to eliminate wrong answers

Option A is wrong because storing state locally in a shared folder leads to state file corruption, conflicts, and no locking mechanism, which violates the requirement for safe team collaboration and code review via pull requests. Option B is wrong because destroying the existing instance to recreate it with Terraform causes unnecessary downtime and risk, whereas `terraform import` can bring the instance under management without disruption. Option C is wrong because having separate Git branches for each environment without a unified main branch and CI pipeline leads to configuration drift, lack of code review, and no controlled promotion of changes across environments.

Full explanation →
383
Multi-Selectmedium

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

Select 4 answers
.Running `terraform plan` and `terraform apply` in a CI/CD pipeline using environment variables for backend configuration.
.Using Terraform Cloud's API-driven run workflow to trigger plans and applies via a REST API call.
.Invoking the Terraform binary with the `-auto-approve` flag in a script to skip interactive approval.
.Using the `terraform output` command in a shell script to fetch infrastructure values for use by other tools.
.Editing the `.tfstate` file directly to modify resource attributes before applying changes in automation.
.Using `terraform init` with the `-from-module` flag to import existing infrastructure into state without a configuration file.

Why this answer

All four correct options represent valid methods for using Terraform outside the core interactive manual workflow. Running `terraform plan` and `terraform apply` in a CI/CD pipeline with environment variables for backend configuration is a standard automation pattern. Terraform Cloud's API-driven run workflow allows programmatic triggering of runs, which is essential for integration with external systems.

The `-auto-approve` flag skips the interactive approval prompt, enabling non-interactive execution in scripts. Using `terraform output` in shell scripts is a common way to extract and pass infrastructure data to downstream tools.

Exam trap

HashiCorp often tests the misconception that directly editing the state file or using non-existent flags like `-from-module` are valid automation techniques, when in fact Terraform strictly enforces state management through its CLI and API to prevent corruption and drift.

Full explanation →
384
MCQhard

Your organization manages a multi-cloud infrastructure using Terraform. The infrastructure includes an AWS VPC with subnets and EC2 instances, and an Azure resource group with virtual networks and VMs. The Terraform configuration is stored in a Git repository, and state is stored in an S3 bucket with DynamoDB locking. Recently, a developer updated the configuration to add a new security group rule in AWS, but after running `terraform apply`, the rule was not created. The developer verified that the configuration file contains the rule. Additionally, the developer noticed that the state file shows the security group exists but without the new rule. The developer ran `terraform plan` again, and it shows that the rule will be created. However, when applying, it fails with a 'timeout' error. The operations team suspects network connectivity issues to the S3 backend. What is the best course of action to resolve this issue?

A.Run `terraform init` again to reinitialize the backend.
B.Migrate the state backend to Terraform Cloud, and use remote operations for applies.
C.Increase the timeout value in the Terraform provider configuration.
D.Disable state locking by removing the DynamoDB table reference.
AnswerB

Terraform Cloud runs applies in a controlled environment, avoiding local network issues.

Why this answer

Option B is correct because the timeout error when applying, despite a successful plan, indicates that the issue is not with the configuration or state locking but with the network connectivity to the S3 backend during the apply operation. Migrating to Terraform Cloud with remote operations moves the execution environment to Terraform Cloud's infrastructure, which has reliable connectivity to the S3 backend, bypassing the local network issues. This resolves the timeout without altering the configuration or compromising state integrity.

Exam trap

HashiCorp often tests the distinction between provider-level timeouts (for API calls to cloud providers) and backend-level timeouts (for state storage), leading candidates to incorrectly choose increasing provider timeouts when the issue is actually with backend connectivity.

How to eliminate wrong answers

Option A is wrong because `terraform init` reinitializes the backend configuration but does not fix network connectivity issues to the S3 backend; the timeout occurs during the apply, not during initialization. Option C is wrong because increasing the timeout in the provider configuration affects API calls to AWS or Azure, not the HTTP timeout for the S3 backend connection; the timeout error is from the backend, not the provider. Option D is wrong because disabling state locking by removing the DynamoDB table reference would allow concurrent state modifications, risking state corruption and race conditions, and does not address the underlying network connectivity issue.

Full explanation →
385
Multi-Selectmedium

Which of the following statements about the core Terraform workflow (Write, Plan, Apply) are correct? (Choose all that apply. There are four correct answers.)

Select 4 answers
.The `terraform plan` command creates an execution plan showing what actions Terraform will take to reach the desired state described in the configuration.
.The `terraform apply` command without any flags will automatically apply the last saved plan if one exists from a previous `terraform plan -out` command.
.During the 'Write' phase, you define resources in one or more `.tf` configuration files, which can reference variables, data sources, and modules.
.If a `terraform plan` shows that a resource will be destroyed and recreated, the state file is immediately updated to reflect this planned change before apply.
.Running `terraform plan` is strictly optional before `terraform apply` because apply will automatically generate and execute a plan if none is provided.
.The `terraform apply` command can be used to destroy infrastructure by passing a plan that includes only destroy operations, but the more common approach is to use `terraform destroy`.

Why this answer

The core Terraform workflow consists of three phases: Write, Plan, and Apply. During the Write phase, you define your desired infrastructure in `.tf` configuration files, which can include variables, data sources, and modules. The `terraform plan` command creates an execution plan that shows what actions Terraform will take to reach that desired state.

The `terraform apply` command can use a saved plan from `terraform plan -out` without additional flags, or if no plan is provided, it will automatically generate and execute a new plan. This workflow ensures that changes are reviewed before being applied, reducing the risk of unintended modifications.

Exam trap

HashiCorp often tests the misconception that `terraform plan` modifies the state file or that `terraform apply` always requires a separate plan command, when in fact `terraform apply` can generate and execute a plan automatically if none is provided.

Full explanation →
386
MCQmedium

During a 'terraform plan', you see the following output: 'Plan: 1 to add, 2 to change, 0 to destroy.' However, after running 'terraform apply', the actual number of resources changed is different. What is the most likely reason?

A.Terraform state locking prevented the apply from executing correctly.
B.The state file was corrupted during the apply.
C.The configuration was modified after the plan was generated.
D.The 'terraform apply' command includes an implicit refresh that changes the plan.
AnswerC

If the configuration changes between plan and apply, the apply uses the new config, so the plan is outdated.

Why this answer

The plan is based on the state and configuration at the time of planning. If someone else applies changes concurrently or if the configuration changes between plan and apply, the plan becomes stale. Option A is wrong because refreshing state doesn't change the plan.

Option C is wrong because 'terraform apply' does not modify configuration. Option D is wrong because locking prevents concurrent applies but doesn't cause discrepancy if the plan is still valid.

Full explanation →
387
MCQmedium

A Terraform plan shows that an AWS EC2 instance will be destroyed and recreated. The team wants to ensure zero downtime during the update. Which lifecycle attribute should be added?

A.depends_on
B.ignore_changes
C.create_before_destroy
D.prevent_destroy
AnswerC

Creates new resource before destroying old, ensuring zero downtime.

Why this answer

Correct B: create_before_destroy creates the new resource before destroying the old one. A prevents destruction, C ignores attribute changes, D handles explicit dependencies.

Full explanation →
388
Matchingmedium

Match each Terraform cloud/enterprise feature to its purpose.

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

Concepts
Matches

Organize state and runs for different environments

Integrate third-party policy or compliance checks

Policy as code framework for governance

Store state securely in Terraform Cloud

Trigger runs automatically from version control

Why these pairings

Terraform Cloud extends open-source capabilities.

Full explanation →
389
MCQeasy

Refer to the exhibit. A developer runs terraform plan and sees the above output. What will happen when terraform apply is executed?

A.The existing EC2 instance is replaced due to a change in instance_type.
B.A new EC2 instance is created with instance_type t2.small, and the old one is destroyed.
C.The existing EC2 instance's instance_type is changed to t2.small in-place.
D.No changes will be made because the plan shows an update.
AnswerC

The tilde (~) and 'updated in-place' indicate a modification without recreation.

Why this answer

Option B is correct. The plan shows 'updated in-place' with a tilde (~) indicating modification, not recreation. The instance_type will change from t2.micro to t2.small without destroying the instance.

Option A describes replacement (force new), which is not indicated. Option C is incorrect because AWS allows in-place modification of instance_type for stopped instances. Option D is incorrect because the plan shows one change.

Full explanation →
390
MCQhard

A company manages a large Terraform configuration with an S3 backend and DynamoDB locking. After initial setup, they modify the backend block in the main.tf to change the S3 bucket name. Running 'terraform plan' yields: 'Backend reinitialization required. Please run "terraform init".' They run 'terraform init' but it prompts to migrate state from the old bucket to the new one. The old bucket is empty (no state files) because the configuration has never been applied. The team wants to avoid unnecessary state migration. Which step should they take?

A.Run 'terraform init -reconfigure' to skip state migration.
B.Delete the .terraform directory and run 'terraform init' again.
C.Change the backend configuration back to the original bucket and run 'terraform state rm' to clear resources.
D.Run 'terraform init -migrate-state' and accept the migration.
AnswerA

The -reconfigure flag disables backend migration and forces reinitialization from scratch.

Why this answer

The correct action is to use 'terraform init -reconfigure', which allows reinitialization without migration by ignoring the existing backend configuration and starting fresh. Option B (deleting .terraform) would also work but is less efficient and may lose cached modules. Option C is unnecessary because there is no state to manage.

Option D would force migration, which the team wants to avoid.

Full explanation →
391
Drag & Dropmedium

Drag and drop the steps to upgrade Terraform providers in a configuration 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

Check versions, update constraints, upgrade with init, then plan to validate.

Full explanation →
392
MCQmedium

Refer to the exhibit. What is the primary purpose of the version constraint '~> 4.0'?

A.Allows any version in the 4.0 range including patch updates.
B.Allows only exact version 4.0.
C.Allows versions 4.0 through 5.0.
D.Allows any version 4.0 or higher.
AnswerA

The pessimistic constraint allows versions 4.0, 4.1, 4.2, etc., but not 5.0.

Why this answer

Option C is correct because the pessimistic version constraint (~>) allows only the rightmost version component to increment. For '~> 4.0', it means any version >= 4.0 and < 5.0, so patch updates are allowed. Option A is wrong because it would be '>= 4.0'.

Option B is wrong because exact version is '= 4.0'. Option D is wrong because that range would be '>= 4.0, < 5.0' which is same as ~> 4.0 but not the intended explanation; actually D is also partially correct but in exam context, 'including patch updates' is more precise.

Full explanation →
393
Multi-Selecteasy

A team is defining their Infrastructure as Code strategy. Which two of the following are key benefits of using IaC compared to manual configuration?

Select 2 answers
A.Faster deployment and provisioning.
B.Reduced need for monitoring.
C.Elimination of all security vulnerabilities.
D.Automatic recovery from any infrastructure failure.
E.Consistent and repeatable infrastructure setups.
AnswersA, E

Automated provisioning is faster than manual processes.

Why this answer

Options A and C are correct. IaC enables faster provisioning and ensures consistency and repeatability. Option B is false because IaC does not eliminate all security vulnerabilities.

Option D is false because IaC does not automatically recover from failures. Option E is false because monitoring is still necessary.

Full explanation →
394
MCQeasy

Refer to the exhibit. What does the output indicate?

A.The Terraform configuration defines three resources
B.The state file tracks three resources
C.Three providers are configured
D.Three workspaces are in use
E.The plan will create three resources
AnswerB

These are the resources currently stored in the state.

Why this answer

The `terraform state list` command lists all resources currently tracked in the state file. Here it shows three resources: a VPC, a subnet, and an EC2 instance.

Full explanation →
395
MCQmedium

An engineer accidentally destroys a critical resource by running `terraform apply` after an incorrect `terraform plan`. They want to recover the resource quickly. What should they do?

A.Modify the configuration to match the destroyed resource and run `terraform import`
B.Use `terraform force-unlock` to unlock the state and then run `terraform plan`
C.Restore the previous version of the configuration and run `terraform apply` again
D.Run `terraform state rm` to remove the destroyed resource from state and then re-import it
AnswerC

Correct! Applying the previous config will recreate the resource as long as state still has the resource.

Why this answer

If the resource was destroyed, Terraform's state still knows about it (unless state was also deleted). The best recovery is to revert the configuration to the previous version and run `terraform apply`. If state is intact, Terraform will recreate the resource.

Full explanation →
396
MCQeasy

After modifying a Terraform configuration file, a user runs 'terraform plan' and sees 'No changes. Infrastructure is up-to-date.' What is the most likely reason?

A.The user forgot to run terraform init.
B.The configuration changes were not committed to version control.
C.The state is stored remotely and the user does not have access.
D.The configuration changes were made in a different directory.
AnswerD

Plan only detects changes in the current directory's .tf files.

Why this answer

Option D is correct because Terraform operates on the configuration files in the current working directory. If the user modified a Terraform configuration file in a different directory and then ran 'terraform plan' from the original directory, Terraform would compare the state against the unchanged configuration in the current directory, resulting in 'No changes. Infrastructure is up-to-date.'

Exam trap

The trap here is that candidates may assume 'No changes' always means the infrastructure is truly up-to-date, overlooking the possibility that Terraform is simply evaluating the wrong set of configuration files due to directory context.

How to eliminate wrong answers

Option A is wrong because forgetting to run 'terraform init' would cause an error about missing providers or modules, not a 'No changes' message. Option B is wrong because version control (e.g., Git) has no effect on Terraform's plan operation; Terraform reads the local filesystem, not the repository history. Option C is wrong because if the user lacks access to the remote state, Terraform would fail with an authentication or permission error, not report that the infrastructure is up-to-date.

Full explanation →
397
MCQhard

Refer to the exhibit. A user runs `terraform plan` and receives this error. The user is using a local backend. Which of the following is the most likely cause?

A.The workspace is not selected correctly.
B.The configured state file path's directory does not exist.
C.The state file is corrupted.
D.The backend is misconfigured for remote state.
AnswerB

The parent directory must exist for Terraform to create the state file.

Why this answer

For local backend, specifying a `path` in the configuration to a non-existent directory causes this error because Terraform cannot create the state file in a missing directory. Option A is correct. Option B would not cause this error.

Option C would cause different errors. Option D is unrelated.

Full explanation →
398
MCQeasy

A company manages multiple AWS accounts using Terraform. They have a central repository where all Terraform configurations are stored. Recently, a developer accidentally ran terraform destroy on a production workspace and deleted critical resources. The team wants to implement safeguards to prevent such incidents while still allowing developers to test changes in non-production environments. They currently use Terraform Cloud for remote state management and runs. Which course of action should the team take to minimize risk?

A.Store the production Terraform state file locally and restrict access to it.
B.Use Terraform's built-in lifecycle prevent_destroy on all production resources.
C.Implement run tasks in Terraform Cloud that require approval for any destroy operation on workspaces tagged as 'production'.
D.Remove all developers' access to the Terraform Cloud API and only allow operations via pull requests.
AnswerC

Run tasks can enforce policy checks and require manual approval for destructive actions.

Why this answer

Option A is correct because Terraform Cloud run tasks can enforce approval workflows for destroy operations on production workspaces. Option B is wrong because removing API access entirely is too restrictive and hinders legitimate operations. Option C is wrong because storing state locally goes against best practices and is insecure.

Option D is wrong because prevent_destroy is a meta-argument that blocks all destroy operations, not just accidental ones, and is not a flexible safeguard.

Full explanation →
399
MCQeasy

In Terraform, which block is used to define a default value for a variable that can be overridden at runtime?

A.locals
B.variable
C.output
D.terraform
AnswerB

variable block with 'default' argument sets a default value for the variable.

Why this answer

Option C is correct: the variable block with a default argument sets a default. Option A is wrong because output blocks produce output values. Option B is wrong because locals are for local computed values.

Option D is wrong because terraform block is for provider and backend settings.

Full explanation →
400
MCQeasy

A team is using a module from the public Terraform Registry. They want to ensure that the module is pinned to a specific version to avoid unexpected changes. Which approach should they use?

A.Use 'required_providers' block in the root module to lock the module version.
B.Add a 'version' argument inside the module block.
C.Set 'version' in the module's source attribute, e.g., source = "terraform-aws-modules/vpc/aws" with version = "3.2.0".
D.Store the module locally in a vendor directory and reference it by path.
AnswerC

Correct. The version constraint is specified as an argument in the module block alongside the source.

Why this answer

Option C is correct because the Terraform Registry module syntax requires the version constraint to be specified as a separate argument within the module block, not embedded in the source string. Pinning to a specific version (e.g., "3.2.0") ensures that only that exact module version is used, preventing unexpected changes from upstream updates. This is the standard approach for versioning public registry modules in Terraform.

Exam trap

HashiCorp often tests the distinction between provider versioning (required_providers) and module versioning (version argument in the module block), and the trap here is that candidates confuse the two or think the version can be embedded in the source string.

How to eliminate wrong answers

Option A is wrong because the 'required_providers' block is used to specify provider version constraints, not module version constraints; modules are versioned independently of providers. Option B is wrong because the 'version' argument cannot be placed inside the module block as a top-level attribute; it must be specified as a separate argument alongside the source, not as a nested block. Option D is wrong because while storing a module locally avoids version drift, it is not the standard approach for pinning a public registry module and introduces manual maintenance overhead; the question specifically asks about using a module from the public Terraform Registry, where the version argument is the intended mechanism.

Full explanation →
401
MCQmedium

A developer needs to retrieve the current state of an AWS EC2 instance that was created by Terraform but the configuration file is missing. Which command will output the attributes of the instance in a format suitable for generating a configuration?

A.terraform output aws_instance
B.terraform state pull | grep aws_instance
C.terraform state show -json aws_instance.example
D.terraform plan
AnswerC

This outputs the resource's current attributes in JSON format, suitable for generating configuration.

Why this answer

Option B is correct because terraform state show displays the state of a single resource, and using -json provides machine-readable output ideal for generating configuration. Option A is wrong because terraform plan only shows changes, not full state. Option C is wrong because terraform output shows output values, not resource attributes.

Option D is wrong because terraform state pull outputs the entire state file, not a single resource in an easy-to-parse format.

Full explanation →
402
MCQhard

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

A.encrypted
B.sensitive
C.hidden
D.secret
AnswerB

Marks a variable as sensitive so its value is not displayed in CLI output.

Why this answer

The `sensitive` attribute on provider configuration (via variables) prevents values from being displayed in CLI output, including plan output. There is no `secret` or `hidden` attribute. `encrypted` is not a Terraform attribute for this purpose.

Full explanation →
403
MCQeasy

A team wants to import an existing AWS S3 bucket named 'my-bucket' into Terraform state. The resource block is defined as 'aws_s3_bucket.my_bucket'. Which command should be used?

A.terraform import my-bucket aws_s3_bucket.my_bucket
B.terraform import 'aws_s3_bucket.my_bucket' 'my-bucket'
C.terraform import aws_s3_bucket.my_bucket my-bucket
D.terraform import aws_s3_bucket.my-bucket my-bucket
AnswerC

Correct syntax and order.

Why this answer

Option D is correct because the import command syntax is 'terraform import <resource_address> <id>'. The resource address is 'aws_s3_bucket.my_bucket' and the ID is the bucket name 'my-bucket'. Option A has the wrong order.

Option B uses a hyphen in the resource name. Option C is correct syntax but with unnecessary quotes. Option D is the standard syntax.

Full explanation →
404
Multi-Selectmedium

Which TWO actions are part of the core Terraform workflow? (Choose two.)

Select 2 answers
A.terraform fmt
B.terraform plan
C.terraform validate
D.terraform apply
E.terraform destroy
AnswersB, D

Plan is the second step in the core workflow.

Why this answer

The core Terraform workflow consists of three main steps: `terraform init` to initialize the working directory, `terraform plan` to preview changes, and `terraform apply` to execute those changes. Option B (`terraform plan`) is correct because it creates an execution plan showing what actions Terraform will take to reach the desired state defined in configuration files. Option D (`terraform apply`) is correct because it applies the changes required to reach the desired state, either by using a previously generated plan or by creating a new plan and prompting for approval.

Exam trap

HashiCorp often tests the distinction between commands that are part of the essential three-step workflow (init, plan, apply) versus commands that are useful but optional, leading candidates to mistakenly include `terraform validate` or `terraform fmt` as core workflow steps.

Full explanation →
405
MCQhard

A team manages a multi-tier application consisting of web servers, application servers, and databases deployed across AWS and Azure. Historically, they have provisioned infrastructure manually using cloud consoles and ad-hoc scripts. To improve consistency and reduce errors, they decide to adopt Terraform for Infrastructure as Code. After initial rollout, they encounter problems: some team members still make direct changes via the cloud console to quickly fix issues, causing configuration drift between the Terraform state and actual resources. They also need to manage three distinct environments (development, staging, production) with different configurations (e.g., instance sizes, database settings). The team consists of five people with a limited budget for additional tools. Which course of action best addresses these challenges while adhering to IaC principles?

A.Store Terraform state in a shared S3 bucket with DynamoDB locking, and have each team member apply their own changes locally after review.
B.Use Terraform workspaces to manage environments and enforce that all changes go through version-controlled Terraform configs, disabling direct console changes via IAM policies.
C.Assign each environment to a different Terraform provider alias and use manual planning to ensure correctness.
D.Implement a CI/CD pipeline that runs terraform plan and apply automatically on merges to the main branch, and use Terraform Cloud's Sentinel policies to prevent drift.
AnswerD

CI/CD automates deployments and enforces that only version-controlled configs are applied; Sentinel can detect and prevent drift.

Why this answer

Option C is correct because implementing CI/CD with automated plan/apply and using Sentinel policies to prevent drift directly addresses both issues: drift from manual changes and environment management. Option A helps with environment separation but doesn't prevent drift; IAM policies can restrict console changes but are not part of IaC best practices. Option B improves state management but local applies can still lead to drift.

Option D uses provider aliases which are not designed for environment separation, and manual planning does not prevent drift.

Full explanation →
406
MCQeasy

Which of the following is a primary benefit of using Infrastructure as Code?

A.Faster provisioning through automation
B.Removes dependency on cloud providers
C.Guarantees zero downtime during updates
D.Eliminates the need for cloud credentials
AnswerA

Automation speeds up resource creation and reduces manual effort.

Why this answer

Faster provisioning through automation (B) is a core benefit because IaC allows quick and repeatable deployments. A is false because credentials are still needed. C is false because IaC does not guarantee zero downtime.

D is false because you still depend on cloud providers.

Full explanation →
407
MCQmedium

A team is using a module from the Terraform Registry. When they run 'terraform init', they receive an error stating that the module source cannot be downloaded. The module source is correct. What is the most likely cause?

A.The module output variable names are misspelled.
B.The provider version in the module conflicts with the root provider version.
C.The internet connection is down.
D.The user forgot to run 'terraform init' before 'terraform plan' or 'apply'.
AnswerD

Modules must be initialized first; if init hasn't been run, Terraform cannot download the module.

Why this answer

The most common cause is that the user forgot to run 'terraform init' before attempting to use the module, as modules must be downloaded first. Option A is wrong because if the source is correct, a network issue might cause a different error (timeout, 404). Option C is wrong because provider version issues are separate from module download errors.

Option D is wrong because output variable names don't affect init.

Full explanation →
408
MCQeasy

Refer to the exhibit. A developer runs `terraform apply` and the operation succeeds. Later, they manually terminate the EC2 instance through the AWS console. What will happen when the developer runs `terraform apply` again?

A.Terraform will recreate the EC2 instance and reassociate the Elastic IP
B.The Elastic IP will be disassociated and the instance will be recreated
C.Terraform will only recreate the EC2 instance without reassociating the Elastic IP
D.The apply will fail because the Elastic IP is still attached to the terminated instance
AnswerA

Terraform will detect drift, recreate the instance, and update the EIP association.

Why this answer

Option A is correct because Terraform maintains the Elastic IP (EIP) association in its state file. When the EC2 instance is manually terminated outside of Terraform, the state still records the EIP as associated with that instance ID. On the next `terraform apply`, Terraform detects that the instance is missing (drift) and plans to recreate it, then reassociates the EIP to the new instance as defined in the configuration, ensuring the public IP remains attached.

Exam trap

The trap here is that candidates assume Terraform will fail or skip the EIP reassociation because the instance is terminated, but Terraform's state-driven reconciliation ensures it recreates and reassociates all resources to match the configuration, regardless of manual changes.

How to eliminate wrong answers

Option B is wrong because Terraform does not disassociate the EIP before recreating the instance; it simply reassociates it to the new instance after creation, as the state still holds the association. Option C is wrong because Terraform will reassociate the EIP because the configuration explicitly defines the `aws_eip_association` resource or `aws_eip` with `instance` attribute, and Terraform reconciles the full desired state. Option D is wrong because the EIP is not 'attached' to a terminated instance in a way that blocks apply; AWS allows EIPs to remain allocated and can be reassociated, and Terraform will not fail—it will proceed with recreation and reassociation.

Full explanation →
409
MCQeasy

A developer runs `terraform init` in a directory containing Terraform configuration files. After initialization, they notice that a provider plugin was installed. Where are provider plugins stored locally by default?

A.In a `.terraform` subdirectory of the current working directory
B.In the system-wide plugin directory `/usr/share/terraform/plugins`
C.In the user's home directory under `~/.terraform.d/plugins`
D.In a temporary directory that is deleted after `terraform init` completes
AnswerA

Correct! Provider plugins are stored in `.terraform/providers/`.

Why this answer

By default, `terraform init` downloads provider plugins into a `.terraform` subdirectory of the current working directory. This is the standard location for the Terraform working directory's local cache.

Full explanation →
410
Matchingmedium

Match each Terraform meta-argument to its purpose.

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

Concepts
Matches

Create multiple instances from one resource block

Create multiple instances from a map or set of strings

Explicitly specify hidden resource dependencies

Control resource creation/destruction behavior

Select a non-default provider configuration

Why these pairings

Meta-arguments are available across all resource types.

Full explanation →
411
MCQmedium

A team uses a remote backend (S3) with state locking via DynamoDB. One team member runs terraform apply and it fails mid-way. Another team member immediately tries to run terraform plan. What is likely to happen?

A.The plan will run successfully because the lock is automatically released after failure.
B.The plan will run but the state file will be corrupted.
C.The plan will fail with an error indicating the state is locked.
D.The plan will run successfully and show any partial changes.
AnswerC

DynamoDB-backed locking persists until manually released or after a timeout.

Why this answer

Option C is correct. The failed apply may have left a lock on the state, so the plan will fail to acquire the lock. Option A is incorrect because the lock is not automatically released after a failure in all backends.

Option B is possible but the lock prevents it. Option D is incorrect because state is not automatically corrupted; it may be inconsistent but not necessarily corrupt.

Full explanation →
412
MCQeasy

A DevOps team is integrating Terraform into a CI/CD pipeline using Jenkins. They want to ensure that the pipeline fails if the Terraform plan contains destructive changes. Which approach best achieves this?

A.Run terraform apply and parse the output for destroy messages.
B.Run terraform validate and check output for errors.
C.Run terraform destroy --target and fail if any resources are destroyed.
D.Run terraform plan -detailed-exitcode and fail pipeline if exit code is 2.
AnswerD

Exit code 2 means there are changes; pipeline can check this.

Why this answer

Option D is correct because `terraform plan -detailed-exitcode` returns exit code 2 if there are changes, allowing pipeline failure. Option A is wrong because `terraform validate` only checks syntax. Option B is wrong because `terraform apply` will apply changes, not just fail on destructive ones.

Option C is wrong because `terraform destroy` destroys resources, not suitable.

Full explanation →
413
MCQmedium

An organization uses Terraform Cloud for team collaboration. They have a workspace that manages production infrastructure. Due to a security policy, they must ensure that all changes go through a peer review process before they are applied. How can they enforce this requirement?

A.Enable 'apply on merge' and set the workspace to require approval before applying.
B.Require all changes to be submitted via a VCS pull request.
C.Use run triggers to automatically apply after a successful plan in another workspace.
D.Lock the workspace and only unlock it for approved changes.
AnswerA

This ensures that runs are created on merge and require explicit approval before apply.

Why this answer

Option A is correct because enabling 'apply on merge' combined with requiring approval before applying enforces a peer review process: changes must be merged via a VCS pull request (triggering the plan), and then a separate approval step is needed before Terraform Cloud applies the changes. This ensures that no change is applied without explicit human approval after the plan is reviewed.

Exam trap

The trap here is that candidates confuse 'requiring a VCS pull request' (option B) with enforcing peer review, but without the approval step, the apply can still happen automatically after merge, bypassing the intended review gate.

How to eliminate wrong answers

Option B is wrong because requiring all changes to be submitted via a VCS pull request alone does not enforce peer review before apply; it only ensures changes are proposed via PR, but the apply could still happen automatically without manual approval. Option C is wrong because run triggers automatically apply after a successful plan in another workspace, bypassing any peer review or approval step for the target workspace. Option D is wrong because locking the workspace and only unlocking it for approved changes is a manual, error-prone process that does not enforce a consistent peer review workflow and does not integrate with VCS or Terraform Cloud's native approval mechanisms.

Full explanation →
414
Multi-Selecthard

An organization wants to reference outputs from a root module in another Terraform configuration. Which THREE methods are valid for reading those outputs?

Select 3 answers
A.Store outputs in a remote state backend and use terraform_remote_state with appropriate configuration.
B.Use provider data sources (e.g., aws_instance data source) to query existing infrastructure directly.
C.Use a module block with source = "./path/to/other-config" and reference its outputs.
D.Use a terraform_remote_state data source pointing to the remote backend of the other configuration.
E.Read the state file directly using terraform state pull and parse in HCL.
AnswersA, B, D

This is the standard way to share outputs across root modules.

Why this answer

Options B, C, and D are correct. Option B: terraform_remote_state data source reads outputs from another state. Option C: using data sources from a provider can read infrastructure directly.

Option D: outputs.tf in a remote state backend can be referenced via terraform_remote_state. Option A is wrong because relative paths only work within a single configuration. Option E is wrong because partial outputs cannot be extracted from state file directly via HCL.

Full explanation →
415
MCQmedium

Refer to the exhibit. A user applies this configuration and then runs 'terraform state list'. Which resource addresses would appear in the output?

A.aws_instance.web and aws_eip.web
B.aws_instance.web only
C.aws_instance.web and aws_eip.web (but aws_eip.web might not appear if the EIP fails to associate)
D.aws_eip.web only
AnswerA

Both resources are created and will appear in state.

Why this answer

The configuration defines two resources: aws_instance.web and aws_eip.web. Both will be in the state after apply. Option A lists both correct addresses.

Full explanation →
416
MCQhard

An organization uses Terraform modules to provision multiple environments. They have a module 'vpc' that uses a for_each argument in the root module to create VPCs per environment. Each VPC requires a unique CIDR block passed via variable. What is the best practice to pass different CIDRs per instance?

A.Define a map variable with environment names as keys and CIDRs as values, then pass the entire map to the module.
B.Hardcode the CIDR within each module block.
C.Use a list variable for CIDRs and reference them with count.index and element().
D.Use a module output to fetch the CIDR from a data source.
AnswerA

Using a map variable allows clear association between each module instance and its CIDR; it integrates naturally with for_each.

Why this answer

Option D is correct because using a map variable with for_each allows each instance to receive its own CIDR. Option A is wrong because count combined with element() on a list works but is less clear than a map. Option B is wrong because a map already provides key-value association.

Option C is wrong because hardcoding is not scalable.

Full explanation →
417
MCQmedium

A company uses Terraform with remote state stored in an S3 bucket. An operator accidentally runs 'terraform destroy' on a production workspace and wants to recover the state before the operation. What is the best course of action?

A.Re-run 'terraform apply' to recreate resources.
B.Restore the state file from a DynamoDB backup.
C.Use 'terraform state pull' to retrieve the last known state.
D.Restore the state file from the S3 bucket's versioning if enabled.
AnswerD

S3 versioning allows you to revert to a previous version of the state file.

Why this answer

Option B is correct because S3 versioning allows restoring previous versions of the state file. Option A is wrong because DynamoDB is used for locking, not state storage. Option C is wrong because terraform state pull would retrieve the current (post-destroy) state.

Option D is wrong because re-running apply would attempt to recreate resources using the current state, which is empty.

Full explanation →
418
MCQmedium

Refer to the exhibit. A developer runs `terraform plan -out=tfplan` and then `terraform apply "tfplan"`. During apply, network fails and apply is interrupted. The developer then runs `terraform apply` again (without a plan file). What will happen?

A.It will automatically use the previously saved plan file `tfplan`
B.It will fail because the state is locked from the previous apply
C.It will create a new plan and apply only the changes that are still needed
D.It will resume the previous apply from where it left off
AnswerC

Correct! Terraform will refresh state, determine what's already created, and apply only remaining changes.

Why this answer

When `terraform apply` is run without a plan file, Terraform automatically creates a new plan based on the current state and configuration, then applies only the changes that are still needed. Since the previous apply was interrupted, the state file reflects the partial progress, and the new plan will detect any remaining resources that still need to be created, updated, or destroyed, ensuring idempotent behavior.

Exam trap

HashiCorp often tests the misconception that Terraform can resume or automatically reuse a plan file after an interruption, when in fact it always re-plans from the current state to ensure consistency.

How to eliminate wrong answers

Option A is wrong because `terraform apply` without a plan file does not automatically use a previously saved plan file; the `-out=tfplan` flag is required to specify a plan file, and it must be explicitly passed as an argument. Option B is wrong because the state lock is released when the apply is interrupted (either by network failure or manual interruption), so the state is not locked; Terraform uses a lock in the backend (e.g., DynamoDB) that is released after the operation ends. Option D is wrong because Terraform does not resume a partially completed apply; it re-evaluates the configuration against the current state and creates a fresh plan, as the apply operation is not transactional and does not support checkpointing.

Full explanation →
419
MCQeasy

A junior DevOps engineer is asked to explain the primary purpose of Terraform. Which statement best describes Terraform's purpose?

A.Terraform is a monitoring tool that tracks infrastructure changes.
B.Terraform is a scripting tool for automating manual tasks in cloud environments.
C.Terraform is a configuration management tool that installs and configures software on servers.
D.Terraform is an infrastructure provisioning tool that manages cloud and on-premises resources using declarative configuration.
AnswerD

This accurately describes Terraform's purpose: declarative IaC provisioning.

Why this answer

Option B is correct because Terraform is a declarative infrastructure provisioning tool that manages cloud and on-premises resources as code. Option A is incorrect because configuration management (e.g., Ansible) is a different category. Option C is incorrect because Terraform is not a scripting tool but an IaC tool.

Option D is incorrect because monitoring is not Terraform's core purpose.

Full explanation →
420
Multi-Selectmedium

Which THREE of the following are best practices for Terraform state management in a team environment?

Select 3 answers
A.Use separate state files for different environments (dev, prod)
B.Store state files in a version control repository
C.Enable state locking to prevent concurrent modifications
D.Store state files in a remote backend shared by the team
E.Manually edit the state file to correct drift
AnswersA, C, D

Separation reduces blast radius.

Why this answer

Best practices include remote state, state locking, and isolating environments. Options A, B, and D are correct.

Full explanation →
421
MCQmedium

A user runs 'terraform plan' and it shows 'No changes. Infrastructure is up-to-date.' However, the user knows they added a new resource block to the configuration. What could explain this?

A.The resource block has a count parameter set to 0.
B.The resource block is inside an output block.
C.The user ran terraform validate before plan.
D.The resource block was added after running terraform fmt.
AnswerA

With count=0, the resource is not created, so no change.

Why this answer

When a resource block has `count = 0`, Terraform evaluates the count meta-argument and determines that zero instances of that resource should be created. As a result, the resource is effectively absent from the state, and `terraform plan` sees no changes because there is nothing to add, modify, or remove. This is a common cause of a 'No changes' result despite adding a new resource block.

Exam trap

HashiCorp often tests the subtle behavior of `count = 0` causing a resource to be completely ignored by Terraform, leading candidates to mistakenly think the resource would still appear in the plan as 'to be added' or that other workflow commands like `validate` or `fmt` are responsible for the discrepancy.

How to eliminate wrong answers

Option B is wrong because resource blocks cannot be placed inside output blocks; outputs are separate blocks that reference resource attributes, and Terraform would produce a syntax error, not a silent 'No changes'. Option C is wrong because `terraform validate` only checks configuration syntax and internal consistency; it does not affect the plan's detection of new resources. Option D is wrong because `terraform fmt` only reformats configuration files for style consistency; it does not alter the logical content or cause Terraform to ignore new resources.

Full explanation →
422
Multi-Selectmedium

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

Select 2 answers
A.Run terraform apply automatically after plan
B.Use version control for configurations
C.Store state in the source repository
D.Use remote state with locking
E.Use terraform import to manage existing resources
AnswersB, D

Tracks changes and enables collaboration.

Why this answer

Remote state with locking ensures consistency and prevents corruption. Version control tracks changes. Storing state in source repo is not secure.

Auto-applying after plan is risky without approval. terraform import is for importing existing resources, not a CI/CD best practice.

Full explanation →
423
MCQeasy

Which of the following files is NOT required in a Terraform module?

A.providers.tf
B.outputs.tf
C.variables.tf
D.main.tf
AnswerA

A module does not need its own providers.tf; it uses the provider configuration from the root module.

Why this answer

Option D is correct because a module does not require its own providers.tf; it inherits provider configurations from the root module. Options A, B, and C are all standard files commonly found in a module (main.tf, variables.tf, outputs.tf).

Full explanation →
424
MCQmedium

A developer runs `terraform apply` and receives the error: 'Error acquiring the state lock'. Another engineer is currently running `terraform plan`. What should the developer do?

A.Run terraform init to reinitialize the backend
B.Wait for the lock to be released automatically
C.Run terraform force-unlock with the lock ID
D.Run terraform plan with -lock=false to bypass the lock
E.Delete the lock file from the S3 bucket
AnswerB

The lock will be released when the other engineer's plan completes. Waiting is the safest approach.

Why this answer

The safest action is to wait for the lock to be released. Force-unlocking without proper cause can corrupt the state, and disabling locks can cause concurrency issues.

Full explanation →
425
Multi-Selecteasy

Which TWO statements accurately describe the purpose of Terraform? (Choose two.)

Select 2 answers
A.Terraform allows users to define infrastructure resources in a declarative configuration language.
B.Terraform can be used to create, modify, and destroy infrastructure resources.
C.Terraform is designed to work exclusively with AWS.
D.Terraform is a configuration management tool used for installing software on existing servers.
E.Terraform is a continuous integration and deployment tool.
AnswersA, B

Terraform uses HCL to declare desired state.

Why this answer

Option A is correct because Terraform uses HashiCorp Configuration Language (HCL) to define infrastructure as code in a declarative manner, meaning users specify the desired end state of resources without scripting the step-by-step process. This declarative approach allows Terraform to automatically determine the necessary actions to reach that state, making infrastructure management predictable and repeatable.

Exam trap

The trap here is that candidates often confuse Terraform's provisioning role with configuration management (Option D) or mistakenly assume it is cloud-specific (Option C), because many introductory examples focus on AWS, but Terraform's multi-provider support is a core design principle.

Full explanation →
426
Multi-Selectmedium

Which TWO statements about Terraform provisioners are correct?

Select 2 answers
A.Provisioners can only be used with the 'local-exec' and 'remote-exec' provisioners.
B.Provisioners should be used as a last resort when no other Terraform resource or data source fits.
C.Provisioners are the primary way to configure resources after creation.
D.Provisioners run only once during initial creation by default.
E.Provisioners can be used with the 'null_resource' to run arbitrary actions.
AnswersB, E

Best practice: use provisioners only when necessary.

Why this answer

Option B is correct because Terraform provisioners are considered a last resort for tasks that cannot be accomplished with Terraform's declarative resource model. The official Terraform documentation explicitly states that provisioners should be used sparingly, as they introduce procedural logic and can cause state drift or failures that are hard to debug. This aligns with the principle of keeping configurations idempotent and relying on native resource attributes or data sources first.

Exam trap

HashiCorp often tests the misconception that provisioners are the standard way to configure resources, when in fact they are explicitly documented as a last resort, and candidates may also incorrectly assume that only 'local-exec' and 'remote-exec' exist.

Full explanation →
427
MCQmedium

A company wants to use Terraform to manage resources across AWS and Azure. They need a single workflow that can apply changes to both providers. What is the best practice?

A.Use separate Terraform configurations for each provider
B.Use Terraform Cloud workspaces with different providers
C.Use Terraform workspaces to separate providers
D.Define both providers in a single configuration
AnswerD

Allows unified workflow.

Why this answer

Option D is correct because Terraform allows multiple providers to be defined in a single configuration, enabling a unified workflow to manage resources across AWS and Azure. By declaring both providers in the same root module, a single `terraform apply` can create, update, or destroy resources from both clouds in the correct order, leveraging Terraform's dependency graph to handle cross-provider dependencies. This is the recommended best practice for multi-cloud management with a single workflow.

Exam trap

The trap here is that candidates confuse workspaces (which isolate state for different environments) with provider separation, leading them to choose option C, when in fact workspaces do not change the provider definitions in a configuration.

How to eliminate wrong answers

Option A is wrong because using separate configurations for each provider would require separate `terraform apply` runs, breaking the single workflow requirement and introducing manual coordination or external orchestration. Option B is wrong because Terraform Cloud workspaces are designed to manage multiple environments (e.g., dev, prod) with the same provider configuration, not to separate providers; using different workspaces for different providers would still require separate configurations or state files, not a single workflow. Option C is wrong because Terraform workspaces are a state isolation mechanism for the same configuration, not a way to separate providers; they cannot change which providers are used in a single configuration, and using workspaces to separate providers would still require multiple configurations or manual switching.

Full explanation →
428
MCQmedium

A module outputs a map of security group IDs keyed by name. In the root module, a resource needs to reference the security group ID for the name 'web-sg'. How should the root configuration access this value?

A.module.sg["web-sg"]
B.module.sg.web-sg
C.data.module.sg["web-sg"]
D.module.sg[0]
AnswerA

Correct map index syntax to retrieve the value for key 'web-sg'.

Why this answer

Using a 'for' expression with a condition is the correct way to filter a map. Option A is wrong because map syntax uses brackets, not dot notation. Option B is wrong because you need to look up by key, not index.

Option D is wrong because module outputs are not accessed via data sources.

Full explanation →
429
MCQhard

A company manages a microservices application across multiple AWS accounts using Terraform. They have a dedicated 'infrastructure' repository with Terraform configurations for each account. The team recently migrated their Terraform state to a centralized S3 backend with DynamoDB locking. After the migration, they notice that when two developers run `terraform apply` simultaneously in the same workspace, one of them receives a lock error, but the other proceeds normally. The team wants to ensure that only one apply runs at a time across all workspaces. However, they also need to allow concurrent operations on different workspaces. The current backend configuration uses a single DynamoDB table for all workspaces. What should the team do to achieve their goals?

A.Use a single DynamoDB table but increase the lock timeout
B.Remove the backend configuration and use local state with manual locking
C.Use a separate DynamoDB table for each workspace to isolate locks
D.Disable locking to allow parallel operations
AnswerC

Separate tables allow concurrent applies on different workspaces while maintaining locking per workspace.

Why this answer

The problem is that using a single DynamoDB table with a single lock key means all workspaces share the same lock, preventing concurrent applies on different workspaces. Option D is correct: Use a separate DynamoDB table for each workspace, which isolates locks per workspace. Option A is dangerous.

Option B does not solve the cross-workspace contention because the lock key is shared. Option C loses centralized state.

Full explanation →
430
Multi-Selectmedium

Which TWO of the following are benefits of using Terraform Cloud Run Tasks?

Select 2 answers
A.Integrate with third-party tools for security scanning.
B.Simplify state management by offloading to Terraform Cloud.
C.Provide an approval gate for manual intervention.
D.Enforce custom policies before allowing an apply.
E.Automatically reduce costs by identifying unused resources.
AnswersA, D

Run Tasks can call external services during runs.

Why this answer

Options A and C are correct. Run Tasks allow integration with third-party tools during the plan/apply phase (A), and they can enforce compliance checks before approval (C). Option B is wrong because run tasks don't directly avoid costs.

Option D is wrong because they don't simplify state management. Option E is wrong because approval is separate.

Full explanation →
431
Multi-Selectmedium

Which four of the following statements about interacting with Terraform modules are correct? (Choose four.)

Select 4 answers
.A module can reference outputs from another module using the syntax module.<MODULE_NAME>.<OUTPUT_NAME>.
.The source attribute in a module block can reference a local file path, a Git repository, the Terraform Registry, or an HTTP URL.
.Terraform automatically downloads module dependencies when running terraform init, including nested modules from the root module.
.Module inputs are defined as variables in the module's root directory, and outputs are defined as output values that can be consumed by the calling configuration.
.To use a module from a private registry, you must always specify a version constraint in the source attribute of the module block.
.A module can be used to create resources only in the same provider configuration as the root module; it cannot define its own provider configurations.

Why this answer

This statement is correct because Terraform modules expose outputs that can be referenced by the calling configuration using the syntax `module.<MODULE_NAME>.<OUTPUT_NAME>`. This allows values computed inside a module to be used elsewhere in the root module, enabling modular composition and data sharing between modules.

Exam trap

HashiCorp often tests the distinction between `source` and `version` attributes in module blocks, and the misconception that modules cannot override provider configurations, which leads candidates to incorrectly select the two wrong options.

Full explanation →
432
Multi-Selecteasy

Which THREE of the following are valid methods to manage Terraform state in a team environment? (Choose three.)

Select 3 answers
A.Storing state in a version control system
B.Using a remote backend like S3 with DynamoDB locking
C.Using Terraform workspaces with a remote backend
D.Storing state locally and sharing via network drive
E.Using Terraform Cloud to manage state
AnswersB, C, E

Standard team approach.

Why this answer

Option B is correct because using a remote backend like Amazon S3 with DynamoDB locking provides a centralized, durable, and consistent state storage solution. DynamoDB implements a distributed lock mechanism using conditional writes to prevent concurrent state modifications, ensuring state integrity in team environments.

Exam trap

HashiCorp often tests the misconception that version control systems like Git can safely manage Terraform state, but they lack the locking and atomicity required for concurrent team workflows.

Full explanation →
433
Multi-Selecteasy

Which TWO module source types are supported by Terraform natively?

Select 2 answers
A.Terraform Registry (e.g., hashicorp/consul/aws)
B.Docker Hub repositories
C.Local file paths (e.g., ./modules/vpc)
D.Jenkins plugin repository
E.npm packages
AnswersA, C

The Terraform Registry is a native source for published modules.

Why this answer

Options A and D are correct. A: Local paths are supported. D: Terraform Registry is supported.

B is wrong because npm is not a Terraform source. C is wrong because Docker Hub is not a Terraform source. E is wrong because there is no built-in Jenkins module source.

Full explanation →
434
MCQhard

Refer to the exhibit. What is the purpose of the data source?

A.To create a new AMI
B.To fetch an existing AMI ID
C.To define a variable
D.To output the AMI name
AnswerB

The data source retrieves the AMI ID of the latest Ubuntu 20.04 image.

Why this answer

The data source queries the AWS API to fetch information about an existing AMI that matches the specified filters, returning its ID for use in the resource.

Full explanation →
435
MCQeasy

A new user is learning Terraform. They write a configuration file and run terraform apply expecting to provision resources. However, they forgot to run terraform init first. What will happen?

A.Terraform will successfully apply the configuration because validate is enough.
B.Terraform will automatically run init before applying.
C.Terraform will prompt to run init and then continue.
D.Terraform will return an error stating that the working directory is not initialized.
AnswerD

Terraform requires initialization to download providers and modules.

Why this answer

Option B is correct. Running apply without init will fail because providers and modules are not initialized. Option A is incorrect because init is a prerequisite.

Option C is incorrect because terraform validate does not initialize. Option D is incorrect because the failure will prevent any provisioning.

Full explanation →
436
MCQmedium

A team is using Terraform workspaces to manage multiple environments with a single configuration. They store state in an S3 backend. Which statement about Terraform workspaces is true?

A.There is a limit of 10 workspaces per configuration
B.The default workspace is named "default" and cannot be deleted
C.Workspaces can only be used with the local backend
D.Workspaces automatically isolate variable values and provider configurations
AnswerB

Correct! The "default" workspace is always present and cannot be deleted.

Why this answer

Option B is correct because the default workspace in Terraform is always named 'default' and cannot be deleted. This workspace is created automatically when you initialize a configuration, and it serves as the baseline workspace for state management. The S3 backend fully supports workspaces, and each workspace stores its state under a separate path in the S3 bucket, enabling environment isolation without changing the configuration.

Exam trap

The trap here is that candidates often assume workspaces isolate variables and provider configurations, but Terraform workspaces only isolate state; variable values and provider configurations must be managed separately, which is a common source of confusion in the exam.

How to eliminate wrong answers

Option A is wrong because Terraform does not impose a hard limit of 10 workspaces per configuration; you can create up to 256 workspaces (depending on the backend) and the actual limit is determined by the backend's capabilities, not by Terraform itself. Option C is wrong because workspaces are supported by many backends, including S3, AzureRM, GCS, and Consul, not just the local backend; the local backend is only one of many. Option D is wrong because workspaces only isolate state files, not variable values or provider configurations; to isolate those, you must use separate directories, separate configurations, or separate variable files.

Full explanation →
437
MCQeasy

Which of the following is NOT a valid backend type for storing Terraform state?

A.terraform cloud
B.local
C.kubernetes
D.s3
E.http
AnswerC

Kubernetes is not a supported Terraform backend for state storage.

Why this answer

The official Terraform backends include s3, local, http, and terraform cloud. Kubernetes is not a standard backend type.

Full explanation →
438
Multi-Selecthard

Which of the following are valid ways to pass input variables to a Terraform configuration? (Select all that apply.)

Select 3 answers
A.Use the '-var' flag on the command line to set a single variable.
B.Create a file named 'terraform.tfvars' with variable assignments.
C.Use the '-var-file' flag to specify a JSON file with variable definitions.
AnswersA, B, C

The '-var' flag sets a single variable, but the question asks for ways to pass variables (multiple ways). This is a valid way, but it's not a file. The question says 'valid ways to pass input variables' and does not specify 'file'. So both A and B are correct? Let's rethink: Option B: '-var-file' is indeed a valid way to pass a file. Option C: '-var' is also valid. But the instruction says exactly 2 correct. I need to ensure only two are correct. I'll adjust: Option B should be something else that is incorrect. Let me correct the options.

Why this answer

Option B is correct because Terraform automatically loads variable definitions from a file named 'terraform.tfvars' (or 'terraform.tfvars.json') in the current directory when you run a plan or apply. This allows you to define input variables in a structured, reusable way without needing to specify them on every command invocation.

Exam trap

HashiCorp often tests the distinction between 'terraform.tfvars' (auto-loaded) and '-var-file' (explicitly loaded), and the trap here is that candidates may think '-var-file' can load any JSON file, but Terraform requires the file to have a .tfvars or .tfvars.json extension and proper variable assignment syntax.

How to eliminate wrong answers

Option A is wrong because while the '-var' flag is valid for passing a single variable, the question asks for valid ways to pass input variables to a configuration, and the '-var' flag is indeed a valid method — but it is not listed as correct in the answer set because the question requires selecting TWO correct options, and A is actually a valid method; however, the provided correct answer set includes B and C, so A is considered wrong in this context because the question's intended correct pair is B and C. Option C is wrong because the '-var-file' flag is used to specify a file containing variable definitions, but the file must be in HCL format (with .tfvars extension) or JSON format (with .tfvars.json extension); specifying a plain JSON file without the correct extension or using '-var-file' with a JSON file that is not properly formatted as Terraform variable definitions is not a valid way to pass input variables.

Full explanation →
439
MCQmedium

An organization uses a remote backend (S3) with DynamoDB for state locking. A developer runs `terraform plan` and gets the error: "Error acquiring the state lock: ConditionalCheckFailedException". What is the most likely cause?

A.Another Terraform process is currently holding the state lock
B.The S3 bucket does not exist
C.The DynamoDB table is not yet created
D.The Terraform version is incompatible with the backend
AnswerA

Correct! The conditional check fails because the lock item's version does not match, meaning it's locked.

Why this answer

The error 'ConditionalCheckFailedException' occurs when Terraform attempts to acquire a lock in DynamoDB but the conditional write fails because the lock item already exists with a different lock ID. This indicates another Terraform process (or a stale lock) is currently holding the state lock, preventing concurrent operations to protect state integrity.

Exam trap

HashiCorp often tests the distinction between DynamoDB-specific errors (ConditionalCheckFailedException) versus S3 or configuration errors, trapping candidates who confuse state locking failures with backend connectivity issues.

How to eliminate wrong answers

Option B is wrong because if the S3 bucket does not exist, Terraform would return an error like 'NoSuchBucket' or 'AccessDenied', not a DynamoDB conditional check failure. Option C is wrong because if the DynamoDB table is not created, Terraform would throw a 'ResourceNotFoundException' when trying to write the lock item, not a conditional check failure. Option D is wrong because version incompatibility typically causes backend configuration errors or unsupported features, not a DynamoDB conditional check exception.

Full explanation →
440
MCQhard

What will happen when this configuration is applied?

A.The plan will fail due to missing variables.
B.The instance will be destroyed and recreated.
C.The instance will be modified in-place, potentially causing a reboot.
D.The instance type will be changed without downtime.
AnswerC

The tilde (~) signals an in-place update; changing instance type triggers a stop/start, which may involve a reboot.

Why this answer

Option C is correct because the tilde (~) indicates an in-place update. Changing the instance type on AWS requires a stop/start, which results in a reboot but not a full destroy and recreate. Option A is incorrect because the plan shows an update, not a destroy/recreate (which would show -/+).

Option B is incorrect because changing instance type typically requires a reboot, causing downtime. Option D is incorrect because the plan does not indicate any missing variables.

Full explanation →
441
Multi-Selectmedium

Which TWO are benefits of using Terraform Cloud's remote operations with a CLI-driven run workflow?

Select 2 answers
A.Integration with version control systems for automatic plan and apply
B.Centralized state management with automatic locking
C.Support for multiple cloud providers in a single workspace
D.Reduced dependency on local environment variables for provider authentication
E.Ability to execute `terraform plan -refresh-only` without a run
AnswersA, B

Terraform Cloud can trigger runs based on VCS changes.

Why this answer

Option A is correct because Terraform Cloud's CLI-driven run workflow allows users to trigger remote operations from the CLI, which can be integrated with version control systems (VCS) via webhooks. When a VCS repository is connected, any push to a configured branch automatically triggers a remote plan and apply, enabling continuous delivery pipelines without manual intervention.

Exam trap

HashiCorp often tests the distinction between general Terraform Cloud features and those specifically tied to the CLI-driven run workflow; the trap here is that candidates may confuse broad benefits of Terraform Cloud (like multi-provider support) with the unique advantages of the CLI-driven workflow, which focuses on VCS integration and centralized state management.

Full explanation →
442
MCQeasy

A developer wants to use the output of one Terraform configuration as input to another. Which Terraform feature should they use?

A.local values
B.remote state data source
C.data sources
D.variables
AnswerB

Correct. The terraform_remote_state data source retrieves outputs from a different Terraform state.

Why this answer

The terraform_remote_state data source reads outputs from another Terraform state file, allowing cross-configuration data sharing.

Full explanation →
443
MCQhard

In Terraform, the `terraform plan` command compares the current state with the configuration. This is an example of which IaC principle?

A.Version control integration
B.Continuous delivery
C.Modular architecture
D.Desired state enforcement
AnswerD

Terraform plan shows what changes are needed to achieve the desired configuration.

Why this answer

The `terraform plan` command compares the current state (what is deployed) with the configuration (what is declared) and computes the changes needed to align the real-world infrastructure with the declared configuration. This is the essence of desired state enforcement: the tool continuously reconciles the actual state toward the user-defined desired state, rather than executing imperative steps. Option D is correct because Terraform's core loop—plan, apply, refresh—is built around this declarative, state-driven model.

Exam trap

HashiCorp often tests the distinction between declarative (desired state enforcement) and imperative (step-by-step) approaches, and the trap here is that candidates confuse the `plan` command's output with a simple diff report rather than recognizing it as the core mechanism of Terraform's declarative state reconciliation model.

How to eliminate wrong answers

Option A is wrong because version control integration refers to storing Terraform configurations in Git or similar systems, not to the behavior of `terraform plan`. Option B is wrong because continuous delivery is a software engineering practice for automating deployments through pipelines, not a principle demonstrated by a single command that compares state. Option C is wrong because modular architecture is about organizing configurations into reusable modules (e.g., using `module` blocks), which is unrelated to the state-comparison mechanism of `terraform plan`.

Full explanation →
444
MCQhard

In the configuration, what is the likely result of the resource block 'aws_flow_log'?

A.Terraform will error because for_each cannot be used with module outputs.
B.The resource will be created only for the last module instance due to overwriting.
C.It will create one flow log per network module instance, using the vpc_id output from each.
D.It will create one flow log for each VPC using a count based on length of module.networks.
AnswerC

for_each = module.networks iterates over each module instance, allowing access to its outputs via each.value.

Why this answer

Option B is correct because module.networks is a map of module instances, each with outputs; the resource uses for_each over that map, referencing each.value.vpc_id. Option A is wrong because the module does not produce a list of VPC IDs. Option C is wrong because the resource will have two instances.

Option D is wrong because it is fine.

Full explanation →
445
MCQmedium

A DevOps engineer manages infrastructure with Terraform using an S3 backend with DynamoDB locking. During a `terraform apply`, the engineer's network connection drops. After reconnecting, they run `terraform plan` and get an error: "Error acquiring the state lock." The lock is from the previous session. The engineer has verified that no other operations are running. What is the appropriate next step to proceed?

A.Delete the DynamoDB table and recreate it
B.Wait 15 minutes for the lock to expire automatically
C.Use `terraform force-unlock <lock_id>` to remove the stale lock
D.Run `terraform init` to reset the backend connection
AnswerC

Force-unlock removes the lock entry in DynamoDB.

Why this answer

When a lock is stuck, the correct action is to force-unlock using the lock ID. Option B is correct.

Full explanation →
446
MCQhard

Which Terraform feature helps manage dependencies between resources?

A.data source
B.output
C.depends_on
D.provisioner
AnswerC

`depends_on` explicitly defines resource dependencies.

Why this answer

The `depends_on` argument explicitly specifies dependencies, ensuring resources are created or destroyed in the correct order.

Full explanation →
447
MCQmedium

A Terraform configuration uses a module from the Terraform Registry. The module's documentation states it requires Terraform version >= 0.14. The team is using Terraform 0.12. What should the developer do to use this module?

A.Upgrade Terraform to a supported version.
B.Fork the module and modify it to be compatible.
C.Add a version constraint in the module block to pin to an older compatible version.
D.Use the module as-is; the version requirement is only a recommendation.
AnswerA

Correct. The module requires Terraform >= 0.14, so upgrading to a version that satisfies the constraint is necessary.

Why this answer

Modules from the Registry often specify required Terraform versions. Using an older version may lead to syntax errors or missing features. The correct action is to upgrade Terraform to a supported version.

Full explanation →
448
MCQhard

A company uses Terraform Cloud with a remote state backend and runs infrastructure as code through a CI/CD pipeline (GitHub Actions). The pipeline executes 'terraform plan' and 'terraform apply' using a service account with appropriate permissions. Recently, the team introduced a Sentinel policy to enforce that all AWS resources have mandatory tags (Environment, Owner, Project). The policy passes when runs are triggered manually from the Terraform Cloud UI, but fails consistently when the CI/CD pipeline runs the plan. The infrastructure configuration files are identical in both cases. The team verifies that the service account used by CI/CD has the same workspace permissions as the UI user. What is the most likely cause of the failure?

A.The Sentinel policy is checking the wrong workspace.
B.The CI/CD pipeline is using a different set of variables that override the tags.
C.The Sentinel policy is configured to fail on all plans regardless of compliance.
D.The CI/CD pipeline is using an older version of Terraform that does not support Sentinel.
AnswerB

Pipeline variables can override Terraform variables; if tags differ, Sentinel will fail.

Why this answer

The CI/CD pipeline often uses environment variables or variable files that can override Terraform variables. If the pipeline sets different values for the tag variables (e.g., missing or incorrect tags), the Sentinel policy would fail. Option C is correct because variable overrides in the pipeline are a common cause of such discrepancies.

Full explanation →
449
MCQmedium

A team uses an S3 backend with DynamoDB locking. They accidentally delete the DynamoDB table used for state locking. What is the immediate consequence?

A.Terraform commands that require state locking will fail with a locking error.
B.State operations will continue without locking, risking corruption.
C.Terraform will automatically create a new DynamoDB table.
D.The state file will be migrated to local storage.
AnswerA

Without the DynamoDB table, lock operations fail, causing errors.

Why this answer

When the DynamoDB table is deleted, Terraform cannot acquire or release locks, so any command needing locking (apply, plan, destroy) will fail. Option A is correct. Option B is incorrect because Terraform will not proceed without lock; it returns an error.

Options C and D are not automatic behaviors.

Full explanation →
450
MCQhard

A module requires a specific provider configuration with aliases. The root module has two provider configurations: provider 'aws' (default) and provider 'aws' with alias = 'uswest'. The module uses the us-west alias. How should the module block be configured to ensure the correct provider is used?

A.Set required_providers inside the module to include the alias.
B.Use the providers argument in the module block: providers = { aws = aws.uswest }.
C.Include a provider block inside the module block with alias = 'uswest'.
D.Do nothing; Terraform automatically uses the default provider.
AnswerB

The providers argument explicitly maps the module's provider requirements to root module provider configurations.

Why this answer

Option D is correct because providers argument within module block allows mapping aliases to provider configurations. Option A is wrong because required_providers is for provider requirements, not provider selection. Option B is wrong because provider block is not allowed inside module block.

Option C is wrong because the module will use the default provider if not specified.

Full explanation →
Page 5

Page 6 of 7

Page 7

All pages

1234567

Practice TF-003 by domain

Target a specific domain to shore up weak areas.

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