Courseiva

HashiCorp Terraform Associate TF-003 (TF-003) — Questions 76–150

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

Take a mock examExam hub
Page 1

Page 2 of 7

Page 3
76
MCQeasy

A startup uses Terraform to manage their cloud infrastructure. They have a single configuration file that defines an AWS EC2 instance. They want to add an Elastic IP (EIP) and associate it with the instance. The engineer modifies the configuration to add an `aws_eip` resource and references the instance ID. They run `terraform plan` and it shows that the EIP will be created. However, when they run `terraform apply`, they get an error: "Error: Error associating EIP: ... The instance ID 'i-1234567890abcdef0' does not exist." The instance was created successfully in a previous apply. What is the most likely cause?

A.The Terraform state file was lost or corrupted, so the instance is not in state.
B.The `aws_eip` resource is referencing the wrong instance attribute.
C.The instance type has changed causing a new instance to be created.
D.The instance was terminated manually outside Terraform.
AnswerA

state loss means Terraform doesn't know about the instance

Why this answer

Option B is correct because if the state was lost or corrupted, Terraform would think the instance needs to be created, but the error indicates the ID doesn't exist, which could happen if the state doesn't match reality. Option A is wrong because the instance exists. Option C is wrong because the configuration references the instance ID from the resource attribute.

Option D is wrong because the instance type is not changed.

Full explanation →
77
MCQeasy

A team is using Terraform for infrastructure as code. They want to ensure that the state file is stored securely and can be accessed by multiple team members. Which backend type should they use?

A.The -state flag pointing to a network share
B.Using the -lock=false flag
C.Local backend with .terraform directory version-controlled
D.Remote backend such as Amazon S3 with DynamoDB state locking
AnswerD

This provides secure, shared state storage with locking to prevent conflicts.

Why this answer

Option D is correct because a remote backend like Amazon S3 with DynamoDB state locking provides secure, centralized storage for the Terraform state file and enables state locking to prevent concurrent modifications. This setup ensures that multiple team members can safely access and update the state without conflicts, while S3 offers encryption and access control. Local backends or network shares lack these locking and security features, making them unsuitable for team collaboration.

Exam trap

HashiCorp often tests the misconception that version-controlling the state file or using a simple network share is sufficient for team collaboration, when in fact proper state locking and remote storage are required to prevent corruption and ensure consistency.

How to eliminate wrong answers

Option A is wrong because using the -state flag to point to a network share does not provide state locking, leading to potential state corruption when multiple team members run Terraform concurrently. Option B is wrong because using the -lock=false flag disables state locking entirely, which can cause race conditions and state file corruption in a team environment. Option C is wrong because version-controlling the .terraform directory (which contains the local state file) is insecure and violates best practices, as state files often contain sensitive data and are not designed for concurrent access via version control systems.

Full explanation →
78
MCQeasy

Which statement best describes 'immutable infrastructure' in the context of IaC?

A.Configuration is changed via patches and updates
B.Servers are never modified after deployment; new ones are created for updates
C.Resources are shared across environments
D.Infrastructure is version-controlled
AnswerB

This is the core principle of immutability.

Why this answer

Immutable infrastructure means never modifying servers after deployment; instead, new servers are created for any changes (D). A describes mutable. B is generally true but not specific to immutable.

C is not related.

Full explanation →
79
MCQeasy

A developer is working on a Terraform configuration that manages a single resource. They want to import an existing AWS EC2 instance into state. Which command should they use?

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

terraform import is the command to import existing resources into state.

Why this answer

Option C is correct because `terraform import` is the dedicated command for bringing an existing infrastructure resource (like an AWS EC2 instance) under Terraform management by attaching it to a resource block in the state file. It requires the resource address and the provider-specific ID (e.g., `aws_instance.my_instance i-1234567890abcdef0`) to map the real-world resource into the Terraform state without modifying the resource itself.

Exam trap

HashiCorp often tests the distinction between `terraform import` (which only updates state) and `terraform apply` (which modifies infrastructure), so the trap here is that candidates mistakenly think `terraform apply` can also import resources because it can create new ones, but it cannot attach to an existing resource that is not already in state.

How to eliminate wrong answers

Option A is wrong because `terraform apply` is used to create, update, or destroy resources based on the configuration, not to import existing resources into state. Option B is wrong because `terraform refresh` updates the state file to match real-world infrastructure but does not add new resources that are not already tracked in state; it cannot import a resource that has no corresponding state entry. Option D is wrong because `terraform state mv` moves a resource from one state address to another within the same state file or between state backends, but it does not bring an external resource into state for the first time.

Full explanation →
80
Multi-Selectmedium

Which TWO of the following are true about Terraform state? (Choose two.)

Select 2 answers
A.State never contains sensitive data, so it can be stored in version control.
B.State can be used to improve performance by caching resource attributes.
C.State does not store resource IDs; it only stores metadata.
D.State should be stored locally by default for team collaboration.
E.State is used to map real-world resources to your configuration.
AnswersB, E

State caches resource attributes to avoid re-reading every time.

Why this answer

Option B is correct because Terraform state acts as a cache for resource attributes, allowing Terraform to avoid re-querying the provider for every attribute during planning and applying. This improves performance, especially when dealing with large infrastructures or APIs with rate limits, as the state file stores the last-known values of resource attributes.

Exam trap

HashiCorp often tests the misconception that state is purely metadata or that it never contains sensitive data, leading candidates to incorrectly select options A or C, while the correct focus is on state's role as a mapping and performance cache.

Full explanation →
81
MCQmedium

A configuration defines a variable `instance_type` with a default value `t2.micro`. After running `terraform apply`, the operator notices that the instances are being created with type `t2.small`. They check the configuration file and see the default is `t2.micro`. What is the most likely cause?

A.The variable declaration was changed after apply.
B.The state file stores the variable value and overrides the default.
C.A `terraform.tfvars` file in the working directory sets the variable to `t2.small`.
D.The `instance_type` attribute was changed by a lifecycle rule.
AnswerC

overrides the default

Why this answer

Option A is correct because the default can be overridden by setting the variable in a `terraform.tfvars` file or via environment variable `TF_VAR_instance_type`. Option B is wrong because the default is read from the variable declaration. Option C is wrong because variable is set, not read from state.

Option D is wrong because the instance type is a variable, not a resource attribute change.

Full explanation →
82
MCQmedium

A team uses Terraform Cloud workspaces to manage multiple environments. They notice that the state file for the production workspace is stored in a different backend than the development workspace. Which Terraform feature allows different workspaces to use different backends?

A.Using the -backend-config flag
B.Using the backend block with a workspace key
C.Using partial configuration with a backend block that has dynamic workspace references
D.Using a remote backend type
AnswerC

Partial configuration allows injecting workspace-specific values like bucket keys.

Why this answer

Option C is correct because Terraform supports partial backend configuration, where the backend block can omit certain arguments (like the bucket or path) and those values can be supplied dynamically at initialization time. By using a backend block with dynamic workspace references (e.g., `key = "${var.env}/terraform.tfstate"`), each workspace can resolve to a different storage path or even a different backend type when combined with workspace-specific `-backend-config` files. This allows the production and development workspaces to store their state in entirely different backends without hardcoding the configuration.

Exam trap

The trap here is that candidates often confuse the `-backend-config` flag (which supplies values to a single backend) with the ability to switch between entirely different backends per workspace, when in fact the dynamic workspace references in the backend block are what enable that per-workspace backend differentiation.

How to eliminate wrong answers

Option A is wrong because the `-backend-config` flag is used to supply partial configuration values at `terraform init` time, but it does not itself allow different workspaces to use different backends; it merely provides dynamic input to a single backend block. Option B is wrong because the `backend` block does not support a `workspace` key; the `workspace` key is used in the `cloud` block for Terraform Cloud workspaces, not for backend selection. Option D is wrong because the `remote` backend type is a specific backend that stores state in Terraform Cloud or Terraform Enterprise; while it can support multiple workspaces, it does not inherently allow different workspaces to use different backends—all workspaces using the `remote` backend share the same backend configuration.

Full explanation →
83
Multi-Selectmedium

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

Select 2 answers
A.Use 'terraform state rm' to remove existing state before running apply.
B.Run 'terraform import' with the resource address and ID.
C.Use 'terraform console' to inspect and import.
D.Add resource blocks manually and run 'terraform import' for each resource.
E.Use 'terraform init -migrate-state' to import from another backend.
AnswersB, D

Direct import command.

Why this answer

Options B and D are correct. B involves writing resource blocks manually and then using terraform import. D is the direct import command.

A is not a command. C migrates state, not imports. E is not for import.

Full explanation →
84
Multi-Selecthard

Which THREE variable declarations are valid in Terraform?

Select 3 answers
A.variable "enabled" { type = bool default = true }
B.variable "tags" { type = map(string) default = {} }
C.variable "region" { type = string default = "us-east-1" }
D.variable "names" { type = list(string) default = "name" }
E.variable "count" { type = number default = "1" }
AnswersA, B, C

Valid: bool type with bool default.

Why this answer

A, B, D are valid. C is invalid because default is a string for number type. E is invalid because default is a string for list type.

Full explanation →
85
MCQhard

A team has a monolithic Terraform configuration managing multiple AWS accounts. They want to decompose it into smaller configurations that can be managed independently. What is the recommended strategy?

A.Split the configuration into separate directories per account and resource type, and use remote state sharing.
B.Use Terraform workspaces to separate environments within the same configuration.
C.Create a single super-module that contains all resources.
D.Move everything to Terraform Cloud and use different workspaces.
AnswerA

This allows independent management and collaboration.

Why this answer

Option D is correct because splitting by account and resource type into separate workspaces or directories is a common pattern. Option A is wrong because using a single configuration with many workspaces still has tight coupling. Option B is wrong because pulling all into one module increases complexity.

Option C is wrong because Terraform Cloud workspaces alone do not decompose the code.

Full explanation →
86
MCQhard

A company has a monolithic Terraform configuration that manages all infrastructure. As the infrastructure grows, plan and apply times become very long. They want to break the configuration into smaller, independent units to improve performance and reduce blast radius. Which approach should they take?

A.Refactor into multiple Terraform modules and use a single root module
B.Split the configuration into separate root modules, each with its own state file, and use data sources to share outputs
C.Use Terraform workspaces to separate environments
D.Use terraform state mv to reorganize resources into different state files
AnswerB

Correct. This is the recommended pattern for large infrastructures: each root module manages a subset of resources with its own state, reducing plan time and limiting the impact of changes.

Why this answer

Splitting into separate root modules, each with its own state file, and using data sources to share outputs, is the recommended approach for reducing blast radius and improving performance. This allows independent plan/apply cycles and smaller state files.

Full explanation →
87
MCQeasy

Refer to the exhibit. A developer runs 'terraform plan' and receives the following error: 'Error: InvalidAMIID.NotFound: The image id '[ami-0c55b159cbfafe1f0]' does not exist'. What is the most likely cause?

A.The 'tags' block is missing a required 'ami' tag.
B.The AMI is not available in the region specified in the provider configuration.
C.The 'ami' argument is misspelled; it should be 'image_id'.
D.The AMI ID is malformed; it should start with 'ami-' but the rest is incorrect.
AnswerB

AMI IDs are unique per region; the AMI may exist in another region.

Why this answer

Option B is correct because the error 'InvalidAMIID.NotFound' indicates that the specified AMI ID does not exist in the AWS region configured in the Terraform provider block. AMI IDs are region-specific; an AMI available in us-east-1 may not exist in eu-west-2. Terraform validates the AMI against the region's EC2 API, and if the ID is not found, it throws this exact error.

Exam trap

HashiCorp often tests the misconception that AMI IDs are globally unique across all AWS regions, when in fact they are region-specific, leading candidates to overlook the provider region configuration.

How to eliminate wrong answers

Option A is wrong because the 'tags' block is optional and does not require an 'ami' tag; the error is about AMI existence, not missing tags. Option C is wrong because the correct Terraform argument for an AMI ID is 'ami', not 'image_id'; 'image_id' is used in other tools like Packer, not in Terraform's aws_instance resource. Option D is wrong because the AMI ID format 'ami-0c55b159cbfafe1f0' is valid (starts with 'ami-' followed by a hex string); the error states the image does not exist, not that the format is malformed.

Full explanation →
88
MCQmedium

An organization uses Terraform workspaces to manage multiple environments (dev, staging, prod) with the same configuration. What is the primary benefit of using workspaces for state management?

A.Workspaces reduce the number of Terraform configurations needed
B.Workspaces automatically synchronize state across team members
C.Each workspace has its own independent state file, preventing environment conflicts
D.Workspaces enable role-based access control to state
AnswerC

Workspaces separate state per environment.

Why this answer

Workspaces allow the same configuration to be applied to multiple environments with separate state files. Option B correctly captures this isolation.

Full explanation →
89
MCQhard

Refer to the exhibit. After applying this configuration, a team member manually changes the instance type to 't2.small' via the AWS console. The next `terraform plan` shows a change to revert to 't2.micro'. What does this demonstrate?

A.Terraform's drift detection only
B.Immutable infrastructure pattern
C.Terraform's desired state reconciliation
D.A misconfiguration in the Terraform code
AnswerC

Terraform plans to revert the change to match the configuration, which is reconciliation.

Why this answer

Terraform has detected configuration drift (the manual change) and plans to reconcile back to the desired state defined in configuration (C). A is incorrect because immutable infrastructure would replace the instance entirely. B is partially true but the key point is reconciliation, not just detection.

D is false.

Full explanation →
90
MCQeasy

A small startup is using Terraform to deploy AWS resources. They have two separate environments: development and production. Currently, they manage two sets of Terraform configuration files in different directories, each with its own state file stored locally. The CEO wants to reduce duplication and simplify management. The team decides to restructure into a single configuration with workspaces. After implementing workspaces, they run `terraform workspace new dev` and `terraform workspace new prod`, then `terraform apply` in the dev workspace. However, when they switch to prod and run `terraform apply`, the plan shows that Terraform wants to recreate all resources instead of managing the existing production resources. What is the most likely reason for this behavior?

A.Workspaces cannot be used for different environments; only for temporary feature branches.
B.The Terraform configuration uses the same resource names in both workspaces, causing conflicts.
C.The team did not migrate the existing production state into the 'prod' workspace.
D.The team must configure a remote backend for workspaces to function correctly.
AnswerC

Workspaces have independent state; existing state must be imported or moved.

Why this answer

Option C is correct because when the team restructured into a single configuration with workspaces, they created new empty workspaces (`dev` and `prod`) but did not migrate the existing production state file into the `prod` workspace. Terraform workspaces maintain separate state files, so without importing the existing production state into the `prod` workspace, Terraform has no record of the existing production resources and plans to create them from scratch. The `terraform workspace new` command creates a fresh, empty state for that workspace.

Exam trap

HashiCorp often tests the misconception that workspaces automatically inherit or share state from previous configurations, when in fact each workspace starts with a completely empty state unless explicitly migrated.

How to eliminate wrong answers

Option A is wrong because workspaces are explicitly designed to manage multiple environments (e.g., dev, staging, prod) from a single configuration, not just for temporary feature branches. Option B is wrong because resource names within a workspace are scoped to that workspace's state; using the same resource names across workspaces does not cause conflicts—each workspace maintains its own independent state. Option D is wrong because while remote backends are recommended for team collaboration, workspaces function perfectly well with local backends; the issue here is the missing state migration, not the backend type.

Full explanation →
91
MCQeasy

What does Terraform's declarative model mean for infrastructure changes?

A.You manually approve each step
B.You describe the desired end state
C.You must specify the order of creation
D.You write scripts to create resources
AnswerB

Declarative means stating what you want, not how to get there.

Why this answer

In a declarative model, you describe the desired end state, and Terraform determines the steps to achieve that state, handling dependencies and changes automatically.

Full explanation →
92
MCQhard

Which module source type does NOT support version constraints?

A.Local path
B.HTTP URL
C.Git repository
D.Terraform Registry
AnswerA

Local paths are not versioned; they reference a specific directory without version constraints.

Why this answer

Option B is correct. Local path sources (e.g., ./modules/foo) do not support version constraints because they are directly referenced without versioning. Registry, Git, and HTTP sources all support version constraints (via ref, tag, or semver).

Full explanation →
93
MCQeasy

Refer to the exhibit. Which command was most likely executed?

A.terraform apply
B.terraform plan
C.terraform get
D.terraform init
AnswerD

Terraform init downloads modules and backends, showing such output.

Why this answer

"Initializing modules" is part of terraform init. terraform get also downloads modules but does not initialize backends and providers. terraform plan and apply do not download modules.

Full explanation →
94
MCQmedium

An organization uses Terraform Cloud and wants to automate run triggers when a new version of a module is published in a private module registry. What is the recommended method?

A.Create a Git repository with versioned modules and use GitOps.
B.Configure a webhook in the private module registry to notify Terraform Cloud.
C.Schedule terraform plan to run periodically via cron.
D.Use the Terraform Cloud API to poll the registry for new versions.
AnswerB

Webhook allows real-time trigger.

Why this answer

Option A is correct because Terraform Cloud has a webhook integration to trigger runs on registry events. Option B is wrong because API calls would require polling. Option C is wrong because GitOps requires code changes.

Option D is wrong because scheduler is not event-driven.

Full explanation →
95
MCQhard

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

A.Configure the S3 backend with server-side encryption enabled (e.g., 'encrypt = true' and 'kms_key_id').
B.Enable encryption in the AWS provider block.
C.Use 'terraform state encrypt' command.
D.Use 'terraform init -encrypt-state' flag.
AnswerA

S3 backend encryption encrypts state at rest.

Why this answer

Option A is correct because S3 can be configured with server-side encryption, either via bucket policy or default encryption. Options B and D are not real Terraform commands. Option C is incorrect because provider block does not control state encryption.

Full explanation →
96
MCQmedium

Refer to the exhibit. Which change to the configuration would prevent this error in the future?

A.Hardcode a different AMI ID.
B.Set the AMI to null.
C.Add a lifecycle rule to ignore changes.
D.Use a data source to fetch the AMI dynamically.
AnswerD

Correct. A data source retrieves a valid AMI ID at plan time, avoiding hardcoded invalid values.

Why this answer

Using a data source to dynamically fetch the correct AMI avoids hardcoding invalid IDs and ensures the AMI exists in the region.

Full explanation →
97
Multi-Selectmedium

Which TWO scenarios require the use of the depends_on argument?

Select 2 answers
A.When a resource uses the output of another resource in its arguments.
B.When a provisioner creates resources that other resources depend on.
C.When Terraform cannot automatically infer an implicit dependency.
D.When a resource uses the output of a data source in its arguments.
E.When a resource uses a module output as an input.
AnswersB, C

Terraform cannot track provisioner-side effects.

Why this answer

B and E require depends_on because Terraform cannot detect these dependencies. A, C, D typically create implicit dependencies.

Full explanation →
98
MCQeasy

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

A.Provisioners run only when the resource is destroyed.
B.The provisioner should be 'remote-exec' to run on updates.
C.The command syntax is incorrect.
D.Provisioners run only when the resource is created, not on subsequent updates.
AnswerD

Provisioners are not re-run on updates unless triggers specify.

Why this answer

Option A is correct because provisioners only run during resource creation, not updates. Option B is wrong because provisioners run on create or destroy, but only if specified. Option C is wrong because the command is valid.

Option D is wrong because the issue is not the type of provisioner.

Full explanation →
99
MCQmedium

Refer to the exhibit. A user runs 'terraform plan' and sees this output. However, when they run 'terraform apply', they get an error: 'Error creating EC2 instance: UnauthorizedOperation: You are not authorized to perform this operation.' The user's IAM permissions allow ec2:RunInstances. What is the most likely missing permission?

A.ec2:CreateNetworkInterface
B.iam:PassRole
C.ec2:TerminateInstances
D.ec2:DescribeInstances
AnswerA

EC2 instances often require network interface creation, and missing this permission can cause UnauthorizedOperation.

Why this answer

Creating an EC2 instance often requires permissions for related resources like network interfaces, security groups, etc. The error 'UnauthorizedOperation' despite having ec2:RunInstances suggests missing permissions for other actions. Option B is correct because the instance might require a subnet and network interface, and without ec2:CreateNetworkInterface permission, the operation fails.

Full explanation →
100
MCQhard

A team uses Terraform with remote state in Azure Storage. They have a CI/CD pipeline that runs terraform plan and apply. Recently, a team member ran terraform apply manually from their local machine and the process crashed due to a network interruption. Now, the pipeline's next run fails with an error: "Error: Error acquiring the state lock". The team is unsure who holds the lock. They need to proceed with the pipeline as soon as possible. What should they do?

A.Use terraform force-unlock with the lock ID to break the lock.
B.Wait for the lock to expire automatically.
C.Re-run terraform apply with -lock=false to skip locking.
D.Delete the .terraform folder and reinitialize.
AnswerA

Force-unlock allows you to remove a stuck lock, but should be used cautiously.

Why this answer

The correct action is to use `terraform force-unlock` with the lock ID to break the stale lock. When a Terraform process crashes while holding a state lock (stored in Azure Blob Storage via the `azurerm` backend), the lock remains in place, blocking all subsequent operations. The `force-unlock` command is the designed mechanism to manually release such locks, and the lock ID can be obtained from the error message or by querying the Azure Storage blob's lease state.

Exam trap

HashiCorp often tests the misconception that `-lock=false` is a safe workaround for lock issues, but in reality it bypasses safety guarantees and can lead to state corruption, while `force-unlock` is the correct, intended recovery command.

How to eliminate wrong answers

Option B is wrong because Terraform state locks do not have a built-in expiration mechanism; they persist until explicitly released, so waiting will not resolve the issue. Option C is wrong because using `-lock=false` skips lock acquisition entirely, which risks concurrent state modifications and data corruption, and is not a safe or recommended practice for resolving a stuck lock. Option D is wrong because deleting the `.terraform` folder and reinitializing only clears local cached data and provider plugins; it does not affect the remote state lock held in Azure Storage, so the pipeline would still fail with the same lock error.

Full explanation →
101
MCQmedium

A development team is using a declarative IaC tool. They make a change to the configuration file to add a new security group rule. When they apply the configuration, the tool automatically modifies the existing security group to add the rule. What is this behavior called?

A.Desired state reconciliation
B.Provisioning
C.Imperative execution
D.Resource drift
AnswerA

The tool reconciles the current state to match the desired configuration.

Why this answer

This behavior is called desired state reconciliation because declarative IaC tools like Terraform or AWS CloudFormation compare the current state of infrastructure against the desired state defined in the configuration file. When a new security group rule is added to the configuration, the tool automatically computes the necessary changes to reconcile the actual state with the desired state, creating, updating, or deleting resources as needed. This is a core principle of declarative IaC, where the user specifies the 'what' and the tool handles the 'how'.

Exam trap

The trap here is that candidates confuse the automatic correction of drift with the initial provisioning process, or they mistakenly think that any automated change is 'imperative execution' rather than recognizing the declarative reconciliation loop.

How to eliminate wrong answers

Option B is wrong because provisioning refers to the initial creation and setup of infrastructure resources, not the ongoing process of modifying existing resources to match a desired configuration. Option C is wrong because imperative execution involves explicitly scripting each step (e.g., using AWS CLI commands to add a rule), whereas the question describes a declarative tool that automatically determines the actions. Option D is wrong because resource drift is a condition where the actual state of infrastructure diverges from the desired state over time, not the automatic correction of that divergence through reconciliation.

Full explanation →
102
MCQhard

A developer runs `terraform plan` and receives the error: "Error: Unsupported argument; An argument named 'enable_vpn_gateway' is not expected here." What is the most likely cause?

A.The source address is misspelled 'vpc' instead of 'vpc/aws'.
B.The source module is not pinned to a specific version, so it may have changed.
C.The module must be sourced from a different registry or repository.
D.The module version 5.0.0 does not support the 'enable_vpn_gateway' argument.
AnswerD

The error clearly states the argument is not expected; it was likely removed in that version.

Why this answer

Option D is correct because the error 'Unsupported argument' indicates that the module version currently in use does not define an input variable named 'enable_vpn_gateway'. In Terraform, each module version has a fixed set of input variables; if you attempt to pass an argument that is not declared in the module's variables.tf, Terraform will reject it. The most common reason for this is that the module version has been updated or changed, and the argument was removed or renamed in that version.

Exam trap

HashiCorp often tests the distinction between errors caused by module version changes versus errors caused by source configuration issues, trapping candidates who confuse a missing variable error with a source path or registry problem.

How to eliminate wrong answers

Option A is wrong because the error message specifically says 'An argument named 'enable_vpn_gateway' is not expected here', which is about an unexpected argument, not about a misspelled source address; a misspelled source would cause a 'source not found' or 'module not found' error. Option B is wrong because while not pinning a version can lead to unexpected changes, the error itself is about the current module's input schema, not about version drift; the error would occur even if the version is pinned to a version that lacks the argument. Option C is wrong because the source registry or repository does not affect which arguments are supported; the argument support is determined by the module's code, not its location.

Full explanation →
103
MCQeasy

A team uses an S3 backend for Terraform state. During a `terraform apply`, another team member accidentally runs a plan that also modifies the same state. Which feature prevents state corruption in this scenario?

A.The `-lock=false` flag
B.Terraform Cloud remote operations
C.State locking via DynamoDB
D.State versioning in S3
AnswerC

State locking uses DynamoDB to acquire a lock, preventing multiple operations.

Why this answer

State locking prevents concurrent modifications to the state file. Options A and C are not related to state locking. Option D is not a built-in feature.

Full explanation →
104
MCQmedium

A developer creates a module in a subdirectory of their Terraform configuration and wants to reference it from the root module. The directory structure is: /terraform-project/modules/networking. Which source argument should they use in the module block?

A.source = "file:///terraform-project/modules/networking"
B.source = "/terraform-project/modules/networking"
C.source = "./modules/networking"
D.source = "hashicorp/networking/aws"
AnswerC

Correct relative path to the local module subdirectory.

Why this answer

A relative path starting with ./ is the correct way to reference a local module in a subdirectory of the root configuration. Option B is wrong because absolute paths are platform-dependent and not recommended. Option C is wrong because file:/// scheme is used for absolute file URIs, not relative.

Option D is wrong because using the registry path would try to download from an external source, not local.

Full explanation →
105
MCQmedium

A developer is reviewing a terraform plan output and sees that a resource of type "aws_instance" with name "web" will be updated. The developer expected no changes because the configuration hasn't been modified. The instance was manually resized in the AWS console by another team. The developer wants to reconcile the state without destroying the instance. What should they do?

A.Run terraform apply -refresh-only to update the state to match reality.
B.Run terraform state rm aws_instance.web and then terraform import.
C.Manually edit the state file to match the instance attributes.
D.Run terraform apply with -target=aws_instance.web to update only that resource.
AnswerA

Refresh-only syncs state with real-world infrastructure without making changes.

Why this answer

Option A is correct because `terraform apply -refresh-only` updates the Terraform state to match the actual infrastructure without making any configuration changes. This command reads the current state of the `aws_instance.web` resource from AWS and writes it to the state file, reconciling the drift caused by the manual resize. It does not destroy or recreate the instance, preserving the existing resource.

Exam trap

HashiCorp often tests the distinction between `terraform apply -refresh-only` and `terraform apply` with `-target`, where candidates mistakenly think targeting a resource will only refresh it, but in reality `-target` still applies configuration changes and can cause updates or destruction.

How to eliminate wrong answers

Option B is wrong because `terraform state rm` followed by `terraform import` is unnecessarily destructive and complex; it removes the resource from state entirely, which could cause Terraform to plan a destroy on the next apply if the configuration still references it, and re-importing requires knowing the exact resource ID. Option C is wrong because manually editing the state file is error-prone, unsupported, and violates Terraform's principle of using the CLI to manage state; it can lead to corruption or inconsistencies. Option D is wrong because `terraform apply -target=aws_instance.web` would attempt to apply the configuration to that resource, which would likely trigger an update or destroy/recreate action based on the configuration, not just refresh the state; it does not reconcile drift without changes.

Full explanation →
106
MCQeasy

An engineer modifies a Terraform configuration by increasing the instance_count for an AWS EC2 resource from 2 to 5. After running terraform plan, which change will be displayed?

A.One new resource will be created and two modified.
B.Two existing resources will be destroyed and five new created.
C.Three new resources will be created, two unchanged.
D.All five resources will be updated in-place.
AnswerC

The plan will show +3 resources (for indices 2,3,4) and ~0 changes for indices 0,1.

Why this answer

Option A is correct because increasing count adds three new resources while leaving existing ones unchanged. Option B is wrong because it incorrectly predicts deletion and recreation. Option C is wrong because it suggests in-place update, but count changes add/remove resources.

Option D is wrong because it wrongly says only one new resource.

Full explanation →
107
MCQmedium

An organization uses Terraform to deploy resources on AWS. They have separate configuration files for development, staging, and production. To differentiate these environments, they plan to use the same root module with different variable values. Which Terraform feature best supports this use case?

A.Terraform modules
B.Remote state backends
C.Multiple provider configurations
D.Terraform workspaces
AnswerD

Workspaces allow multiple state files for the same configuration, ideal for environments.

Why this answer

Option C is correct. Workspaces allow using the same configuration with separate state files for different environments. Option A (providers) is for different cloud providers, not environments.

Option B (modules) organize code but don't inherently separate state. Option D (remote backends) can be used with workspaces but alone don't provide environment separation.

Full explanation →
108
MCQeasy

A company wants to adopt infrastructure as code (IaC) to manage their expanding cloud environment. Which problem does Terraform directly address?

A.Ensuring applications are highly available across regions
B.Automating software installation and patching on servers
C.Eliminating manual configuration drift across environments
D.Providing real-time monitoring and alerting for infrastructure
AnswerC

Terraform's desired state model helps prevent drift by enforcing configuration.

Why this answer

Option A is correct because Terraform provides a declarative way to define and provision infrastructure, ensuring consistency and repeatability. Option B is configuration management, not Terraform's focus. Option C is monitoring, not provisioning.

Option D is partly addressed but not the core purpose; Terraform helps with drift detection but not real-time correction.

Full explanation →
109
MCQmedium

A team is writing Terraform configurations for a multi-region deployment. They want to use a module from the public Terraform Registry that provisions AWS VPCs. The module has been updated recently, but the team wants to ensure that all deployments use the same version of the module to avoid unexpected changes. Which configuration approach should they take to lock the module version?

A.Run 'terraform lock' on the module to record its version in the dependency lock file.
B.Use the 'version' argument in the module block to specify the exact version.
C.Reference the module source with a git URL and tag, such as 'git::https://github.com/...?ref=v1.0'.
D.Set the 'required_version' argument in the root module to match the module's version.
AnswerB

The 'version' argument in a module block pins the module to a specific version.

Why this answer

Option B is correct because the 'version' argument in a module block is the standard Terraform mechanism for pinning a module from the Terraform Registry to a specific semantic version. This ensures that all deployments use the exact same module version, preventing unexpected changes from newer releases. The version constraint is evaluated against the registry's metadata and enforces the specified version during 'terraform init'.

Exam trap

HashiCorp often tests the distinction between module version pinning (using 'version' in the module block) and provider version pinning (using 'required_providers' and the lock file), leading candidates to confuse 'terraform lock' or 'required_version' as valid mechanisms for locking module versions.

How to eliminate wrong answers

Option A is wrong because 'terraform lock' is not a valid Terraform command; the dependency lock file (.terraform.lock.hcl) is automatically managed by 'terraform init' and records provider version hashes, not module versions. Option C is wrong because while using a git URL with a tag does pin a version, it bypasses the Terraform Registry's version resolution and is not the recommended approach for modules sourced from the registry; the question specifically asks about a module from the public Terraform Registry. Option D is wrong because 'required_version' in the root module sets a constraint on the Terraform CLI version, not on module versions.

Full explanation →
110
MCQmedium

A developer creates a directory structure with a module located at './modules/networking'. The root configuration references it with source = './modules/networking'. What is the behavior when running terraform init from the root directory?

A.Terraform uses the module directly from the local filesystem.
B.Terraform requires a network connection to verify the module.
C.Terraform attempts to download the module from the public registry.
D.Terraform returns an error because the module path is not absolute.
AnswerA

When the source is a relative or absolute path, Terraform reads the module from that directory.

Why this answer

Option C is correct because local path modules are detected automatically without registry. Option A is wrong because local paths don't require registry. Option B is wrong because no internet needed.

Option D is wrong because it will be found.

Full explanation →
111
MCQhard

A team member runs terraform apply with the configuration shown in the exhibit. The apply succeeds, but the output of the local-exec provisioner shows an empty string for the public IP address. What is the most likely cause?

A.There is a dependency cycle between the aws_instance and null_resource causing Terraform to skip the provisioner.
B.The local-exec provisioner only runs during terraform destroy, not during apply.
C.The aws_instance resource does not have a public IP assigned because it is launched in a default VPC without auto-assign public IP, and no Elastic IP is attached.
D.The provisioner cannot access the aws_instance resource's attributes because it is defined in a separate resource block.
AnswerC

Without explicit configuration, the instance may not get a public IP, leaving the attribute empty.

Why this answer

Option C is correct because the `local-exec` provisioner runs on the machine executing Terraform, not on the AWS instance itself. If the instance is launched in a default VPC without `auto-assign public IP` enabled and no Elastic IP is attached, the `self.public_ip` attribute will be an empty string. The provisioner then outputs that empty string, as it simply reads the attribute value from the resource state.

Exam trap

HashiCorp often tests the misconception that `local-exec` runs on the remote instance or that `self.public_ip` is always populated, when in reality it depends on the network configuration and the provisioner's execution context.

How to eliminate wrong answers

Option A is wrong because a dependency cycle would cause Terraform to error out during planning, not silently skip the provisioner; the apply succeeded, so no cycle exists. Option B is wrong because `local-exec` provisioners run during `terraform apply` by default, not only during destroy; `destroy-time` provisioners require explicit `when = destroy`. Option D is wrong because provisioners can access attributes of any resource in the configuration, including `aws_instance`, as long as the resource is referenced (e.g., via `self` or a direct reference); the `null_resource` has a `depends_on` ensuring the instance exists.

Full explanation →
112
MCQmedium

Refer to the exhibit. A Terraform configuration includes an `aws_instance.web` resource. The state shows the instance with a specific AMI and instance type. After running `terraform plan`, Terraform reports no changes. However, an engineer observes that the actual instance in AWS has a different AMI ID but the same instance type. What is the most likely cause?

A.The instance type was modified after the last apply, but AMI was not
B.The state file has not been refreshed since the manual AMI change; it still reflects the old AMI
C.The `terraform plan` command ignores drift by default
D.The AMI data source is returning a different value each time
AnswerB

Terraform compares state to config, not state to real world, unless refresh happens.

Why this answer

If the state shows the old AMI, but the actual instance has a different AMI, the state is stale. A `terraform refresh` or apply should detect drift. Option C correctly identifies that the state has not been refreshed.

Full explanation →
113
MCQmedium

During a terraform apply, the state file becomes corrupted. What is the recommended recovery method?

A.Restore from backup
B.Re-run apply
C.Delete the state and re-import all resources
D.Use terraform state pull
AnswerA

Restoring from a recent backup is the safest and most efficient method.

Why this answer

Restoring from a backup is the recommended recovery method for a corrupted state file, as state is critical and backups ensure minimal loss.

Full explanation →
114
Multi-Selecteasy

Which TWO of the following commands can be used to read and inspect the current Terraform state? (Select TWO.)

Select 2 answers
A.terraform state show
B.terraform validate
C.terraform state list
D.terraform output
E.terraform plan
AnswersA, C

shows details of a resource in state

Why this answer

Options B and C are correct. `terraform state list` lists resources, `terraform state show` shows details. Option A is wrong because `terraform plan` does not read state; it plans changes. Option D is wrong because `terraform output` shows outputs, not full state.

Option E is wrong because `terraform validate` validates syntax.

Full explanation →
115
MCQmedium

Refer to the exhibit. The user runs 'terraform plan' and sees that Terraform wants to create the instance. However, the instance already exists in the AWS account with the same configuration. What is the most likely reason?

A.The instance type has changed
B.The instance is not in the Terraform state
C.The AMI ID has changed
D.The provider version is different
AnswerB

If the instance is not in the state file, Terraform sees it as missing and plans to create.

Why this answer

Terraform tracks resources in its state file. If the existing instance is not in the state, Terraform will plan to create it. The AMI and instance type are the same, so changes in them wouldn't cause a create.

Full explanation →
116
MCQhard

An organization is evaluating IaC tools and wants to minimize configuration drift. Which characteristic of a declarative IaC approach is most effective in preventing drift?

A.Periodic state comparison and correction
B.Manual approval gates
C.Tagging resources
D.Using modules
AnswerA

Declarative tools like Terraform regularly check and enforce desired state, preventing drift.

Why this answer

A declarative IaC approach defines the desired end state of infrastructure, and tools like Terraform use periodic state comparison (e.g., `terraform plan` and `terraform apply`) to detect and correct any configuration drift. This automated reconciliation ensures the actual infrastructure matches the declared configuration, directly preventing drift without manual intervention.

Exam trap

HashiCorp often tests the misconception that drift prevention is achieved through code organization (modules) or operational controls (approvals), rather than the core declarative mechanism of automated state comparison and correction.

How to eliminate wrong answers

Option B is wrong because manual approval gates (e.g., in CI/CD pipelines) enforce process control but do not automatically detect or correct drift in the deployed infrastructure. Option C is wrong because tagging resources is a metadata labeling practice that aids in resource identification and cost allocation, not a mechanism for drift detection or correction. Option D is wrong because using modules promotes code reuse and consistency but does not inherently perform state comparison or auto-remediation against drift.

Full explanation →
117
MCQeasy

A developer runs `terraform plan` and sees that Terraform will create a new S3 bucket and modify a security group. Which Terraform feature allows the developer to review these changes before applying them?

A.The `terraform apply` command
B.The `terraform validate` command
C.The `terraform plan` command
D.The `terraform state` command
AnswerC

Plan shows a preview of changes.

Why this answer

The `terraform plan` command creates an execution plan that shows what actions Terraform will take to achieve the desired state defined in the configuration. It compares the current state with the configuration and outputs a diff-like summary of resources to be created, modified, or destroyed, allowing the developer to review changes before applying them with `terraform apply`.

Exam trap

HashiCorp often tests the distinction between `terraform plan` as a read-only preview and `terraform apply` as the execution command, trapping candidates who confuse 'review' with 'apply' or think `terraform validate` performs a dry-run.

How to eliminate wrong answers

Option A is wrong because `terraform apply` executes the changes and does not provide a review-only preview; it applies the plan and prompts for confirmation unless auto-approved. Option B is wrong because `terraform validate` checks the syntax and internal consistency of the configuration files, not the planned changes against the real infrastructure state. Option D is wrong because `terraform state` is used to inspect or manipulate the Terraform state file (e.g., `terraform state list`, `terraform state show`), not to preview upcoming changes.

Full explanation →
118
MCQeasy

A Terraform module defines an output 'instance_ips'. In the root module, how should this value be referenced?

A.var.instance_ips
B.local.instance_ips
C.resource.my_module.instance_ips
D.module.my_module.instance_ips
AnswerD

This is the correct syntax to access an output from a module named 'my_module'.

Why this answer

Option A is correct because module outputs are referenced as module.<module_name>.<output_name>. Option B is wrong because var is for input variables. Option C is wrong because resource references are different.

Option D is wrong because local is for local values.

Full explanation →
119
MCQhard

A company is adopting Terraform to manage its multi-cloud infrastructure on AWS and Azure. The infrastructure team has written several Terraform configurations stored in a Git repository. Each configuration is applied by different team members using their local machines. Recently, the team has been experiencing state file conflicts and inconsistencies, leading to infrastructure drift. The team currently stores the state file locally. They want to ensure that only one person can apply changes at a time and that the state file is always up-to-date. They also want to be able to collaborate effectively without overwriting each other's changes. Which approach should they implement?

A.Use Terraform Cloud to manage state and provide remote operations with locking.
B.Have only one team member run terraform apply from a dedicated machine.
C.Store the state file in a shared Git repository and use git pull/push to sync changes.
D.Use a remote backend such as Amazon S3 with DynamoDB for state locking.
AnswerA

Terraform Cloud provides remote state, locking, and team collaboration features.

Why this answer

Option A is correct because Terraform Cloud provides a managed remote state backend with built-in state locking and remote operations. This ensures that only one person can apply changes at a time (via the locking mechanism), the state file is always up-to-date (stored centrally), and team members can collaborate without overwriting each other's changes. It directly addresses the team's need for exclusive apply access and consistent state.

Exam trap

HashiCorp often tests the distinction between remote state storage (e.g., S3) and remote operations (e.g., Terraform Cloud); the trap here is that candidates see 'remote backend' and assume it solves all collaboration issues, but without remote operations, the apply still runs locally and state locking alone does not prevent concurrent applies from different machines.

How to eliminate wrong answers

Option B is wrong because it introduces a single point of failure and a bottleneck, and does not solve the underlying state locking issue—other team members could still run terraform plan or modify local state, leading to drift. Option C is wrong because storing the state file in a shared Git repository is not safe; Git does not provide state locking, and concurrent git pull/push operations can cause merge conflicts, corruption, or stale state. Option D is wrong because while Amazon S3 with DynamoDB provides state locking and remote storage, it does not offer remote operations (the apply still runs locally), so the team would still need to coordinate who runs apply, and the state file could become stale if multiple users run apply simultaneously without proper locking integration.

Full explanation →
120
Multi-Selectmedium

Which TWO of the following are key advantages of using Terraform over manual infrastructure management? (Select TWO.)

Select 2 answers
A.Guaranteed zero downtime during updates
B.Consistent and repeatable deployments
C.Version-controlled infrastructure code
D.Automatic discovery of existing resources
E.Self-healing infrastructure
AnswersB, C

Declarative configurations ensure the same result each time, reducing manual errors.

Why this answer

Options B and E are correct. Version-controlled infrastructure code enables collaboration and audit trails. Consistent and repeatable deployments reduce errors.

Option A is incorrect because Terraform does not auto-discover resources. Option C is not guaranteed. Option D is not a Terraform feature.

Full explanation →
121
MCQeasy

A junior engineer cloned a Terraform repository from GitHub and ran terraform init inside the project directory. The command downloaded the required provider plugins successfully. Next, they ran terraform plan and received the following error: 'Error: No configuration files found in the current directory.' The engineer checked and confirmed that the main.tf file exists in the current directory. What is the most likely cause of this error?

A.The file is named main.tf.txt instead of main.tf
B.The terraform init command was not run with -upgrade flag
C.The main.tf file contains syntax errors
D.The terraform plan command requires the -out flag
AnswerA

Terraform only reads .tf files; .tf.txt is not recognized.

Why this answer

Option B is correct because Terraform expects configuration files with a .tf extension. If the file has been saved as main.tf.txt, it will not be read. Option A is incorrect because syntax errors would produce a different error message.

Option C is incorrect because the -upgrade flag is not needed for provider download. Option D is incorrect because the -out flag is optional.

Full explanation →
122
Multi-Selecteasy

Which two commands are part of the standard Terraform workflow for provisioning infrastructure?

Select 2 answers
A.terraform init
B.terraform fmt
C.terraform apply
D.terraform import
E.terraform taint
AnswersA, C

Initializes the working directory for Terraform.

Why this answer

`terraform init` is correct because it initializes a working directory containing Terraform configuration files, downloading the required providers and modules. `terraform apply` is correct because it executes the actions proposed in a Terraform plan to provision or change infrastructure resources. These two commands form the core of the standard workflow: initialize, plan, and apply.

Exam trap

HashiCorp often tests the distinction between provisioning commands and lifecycle or maintenance commands, so candidates may incorrectly select `terraform taint` or `terraform import` because they associate them with changing infrastructure, even though they do not directly provision new resources.

Full explanation →
123
MCQmedium

A company wants to use Terraform to create Azure resources. They have written a configuration file but when they run `terraform init`, they get a warning about an 'incomplete lock file'. What should they do first?

A.Change the provider version in the configuration
B.Run `terraform apply` immediately
C.Run `terraform plan` to update the lock file
D.Delete the `.terraform.lock.hcl` and re-run `terraform init`
E.Run `terraform validate` to fix the warning
AnswerD

Re-running init will regenerate the lock file.

Why this answer

Option B is correct because the lock file (.terraform.lock.hcl) is automatically updated by `terraform init`; deleting it will force re-creation. Option A is wrong because `terraform plan` does not update lock files. Option C is wrong because `terraform validate` only validates syntax.

Option D is wrong because running `terraform apply` without proper initialization may fail. Option E is wrong because changing providers is not necessary.

Full explanation →
124
Multi-Selecteasy

Which TWO statements best describe Terraform's purpose? (Choose two.)

Select 2 answers
A.It is a configuration management tool.
B.It is designed for single-cloud environments.
C.It uses a declarative language.
D.It requires a master node to manage agents.
E.It is an infrastructure provisioning tool.
AnswersC, E

Terraform uses HCL, a declarative language.

Why this answer

Terraform is an infrastructure provisioning tool that uses a declarative language. It is not a configuration management tool, does not require a master node, and supports multiple clouds.

Full explanation →
125
Multi-Selectmedium

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

Select 2 answers
A.Create infrastructure manually via cloud console
B.Write Terraform configuration files
C.Review the execution plan
D.Commit changes to version control
E.Run unit tests on the configuration
AnswersB, C

Correct! Writing config is the first step.

Why this answer

The core workflow consists of: Write (author config), Plan (review changes), Apply (execute). Options that match are 'Write configuration' and 'Review execution plan'.

Full explanation →
126
Multi-Selecthard

Which THREE of the following are valid ways to modify a Terraform configuration to rename a resource without destroying and recreating it? (Select THREE.)

Select 3 answers
A.Run `terraform state mv` to rename the resource in state, then update the config.
B.Add a `moved` block in the configuration to map the old address to the new.
C.Simply change the resource name in the configuration and run `terraform apply`.
D.Use a `removed` block to remove the old resource and `import` block to import the new.
E.Run `terraform state rm` then `terraform import` with the new address.
AnswersA, B, D

state mv renames in state without destroy.

Why this answer

Options A, B, and C are correct. Using `moved` block, `terraform state mv`, and then updating config manually, and using `removed` block with `import` are all valid. Option D is wrong because `terraform state rm` + `terraform import` is two steps but works, but the question asks for modification without destroy/recreate; however, removing and importing does not cause destroy, but it's not a single modification.

Option E is wrong because changing the resource name in config and running apply will destroy and recreate.

Full explanation →
127
MCQmedium

A team is using a private module registry from a third-party vendor. When running terraform init, they receive an error: 'Error downloading module: could not download module... server responded with 401 Unauthorized'. What is the most likely cause?

A.The module source URL is incorrect.
B.The registry credentials are missing or invalid.
C.The Terraform version is too old for the module.
D.The network firewall is blocking outbound connections.
AnswerB

A 401 response specifically indicates authentication failure; the client must provide valid credentials to access the registry.

Why this answer

The 401 Unauthorized error indicates authentication failure. Option B is correct because the module registry requires valid credentials, and they are missing or incorrect. Option A is wrong because registry URL typo usually gives a 404 or connection timeout.

Option C is wrong because network firewall usually gives connection refused or timeout. Option D is wrong because Terraform version incompatibility gives a different error about required_version.

Full explanation →
128
Multi-Selecthard

A team is adopting Terraform for infrastructure deployment. They want to ensure that the core workflow (write, plan, apply) is followed effectively. Which two practices should they adopt? (Choose two.)

Select 2 answers
A.Store Terraform configurations in a version control system like Git.
B.Require manual confirmation for every terraform plan execution.
C.Store state files locally on the engineer's machine.
D.Always run terraform apply directly without terraform plan to save time.
E.Use a remote backend with state locking enabled.
AnswersA, E

Version control allows tracking changes, collaboration, and rollback.

Why this answer

Option A is correct because storing Terraform configurations in a version control system like Git ensures that the 'write' phase is collaborative, auditable, and repeatable. It enables teams to track changes, roll back to previous versions, and enforce code review before applying infrastructure changes, which is a core DevOps practice for the Terraform workflow.

Exam trap

HashiCorp often tests the misconception that local state storage is acceptable for teams, but the exam expects candidates to recognize that remote backends with locking are mandatory for collaborative workflows to prevent state conflicts and enable team-based infrastructure management.

Full explanation →
129
Multi-Selecthard

Which THREE of the following are valid flags for the terraform apply command? (Choose three.)

Select 3 answers
A.-lock-timeout
B.-target
C.-var-file
D.-auto-approve
E.-refresh=false
AnswersB, C, D

Limits apply to specific resource addresses.

Why this answer

The `-target` flag is valid for `terraform apply` because it allows you to target specific resources or modules for application, which is useful for incremental deployments or debugging. This flag accepts a resource address pattern and limits the apply operation to only those resources and their dependencies, as defined in the Terraform execution plan.

Exam trap

HashiCorp often tests the distinction between flags that are valid for `terraform plan` versus `terraform apply`, and candidates may incorrectly assume that flags like `-refresh=false` or `-lock-timeout` are exclusive to one command when they actually work for both.

Full explanation →
130
MCQmedium

An organization uses Terraform Cloud for remote state management. They have a workspace that uses the CLI-driven run workflow. A developer runs `terraform plan` locally and sees that the plan succeeds. However, when they push the same configuration to the version control system (VCS) connected to the workspace, the plan fails with a state lock error. What is the most likely reason?

A.The Terraform version in the VCS pipeline is different
B.The local `terraform plan` left the state locked in Terraform Cloud
C.The VCS branch is not configured as the workspace's working branch
D.The VCS pipeline does not have access to the Terraform Cloud workspace
AnswerB

If the plan didn't release the lock, subsequent runs are blocked.

Why this answer

The local `terraform plan` command acquires a state lock in Terraform Cloud to prevent concurrent modifications. When the developer runs `terraform plan` locally but does not follow it with `terraform apply` or explicitly release the lock (e.g., via `terraform force-unlock`), the lock persists. When the VCS pipeline triggers a new run, it attempts to acquire the same lock, which is still held by the local session, causing the plan to fail with a state lock error.

Exam trap

HashiCorp often tests the misconception that state locks are only held during `terraform apply`, but in Terraform Cloud, `terraform plan` also acquires a lock to ensure consistency, and candidates may incorrectly attribute the failure to VCS configuration or permissions issues.

How to eliminate wrong answers

Option A is wrong because a Terraform version mismatch between the local environment and the VCS pipeline would typically cause syntax or provider incompatibility errors, not a state lock error. Option C is wrong because the working branch configuration affects which branch triggers runs, but a misconfigured branch would result in no run being triggered at all, not a lock error. Option D is wrong because if the VCS pipeline lacked access to the Terraform Cloud workspace, the error would be an authentication or authorization failure (e.g., 401 or 403), not a state lock error.

Full explanation →
131
MCQhard

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

A.Restrict module sources in VCS
B.Configure workspace variables to limit module paths
C.Use Sentinel policies to check module sources
D.Use run tasks to scan for module types
AnswerC

Sentinel inspects module source attributes and can block runs.

Why this answer

Sentinel policies can inspect module declarations and block runs if modules come from unapproved sources. VCS restrictions are not always effective. Run tasks and workspace variables do not directly control module sources.

Full explanation →
132
MCQhard

What is the correct way to resolve this provider version conflict?

A.Ignore the module's required_providers and force install the root version.
B.Remove the required_providers block from the root module.
C.Change the root module's required version to ~> 2.70.
D.Manually edit the .terraform/modules/consul/main.tf to change the version.
AnswerC

This aligns the root with the module's requirement, solving the conflict.

Why this answer

The conflict arises because the module requires a provider version (~> 2.70) that is incompatible with the root's requirement (>= 3.0). The best solution is to update the module's required provider version, if possible, to be compatible with the root. Option A is wrong because removing the root constraint may allow a version that satisfies both, but it's better to update the module.

Option B is wrong because downgrading the root version to 2.x may lose features. Option D is wrong because manually editing .terraform is not supported.

Full explanation →
133
MCQeasy

A developer wants to create multiple instances of a module that provisions a single EC2 instance. They want to create 3 EC2 instances. Which approach is most efficient and concise?

A.Set the source argument to a list of three URLs.
B.Use the 'count' meta-argument in the module block.
C.Use the 'for_each' meta-argument with a list of numbers.
D.Copy the module block three times with different names.
AnswerB

count allows creating multiple instances of the module efficiently.

Why this answer

Using 'count' in the module block is the recommended way to create multiple instances of a module. Option B is wrong because copying the module block three times is not DRY. Option C is wrong because for_each requires a map or set of strings, not just a number.

Option D is wrong because a module can only have one source; you cannot specify a list of sources.

Full explanation →
134
MCQmedium

A team is reviewing the Terraform configuration shown in the exhibit. Which statement best describes the relationship between the two resources?

A.The S3 bucket cannot be created until the EC2 instance is running.
B.The S3 bucket depends on the EC2 instance because it is defined after it.
C.The two resources have no dependencies and can be created in any order.
D.The EC2 instance depends on the S3 bucket because the instance uses the bucket name.
AnswerC

No explicit or implicit dependencies.

Why this answer

Option C is correct because Terraform resources are independent by default unless an explicit or implicit dependency is declared. In the exhibit, the S3 bucket and EC2 instance are defined without any `depends_on` argument or attribute reference (e.g., `aws_s3_bucket.example.arn` used in the EC2 instance configuration). Therefore, Terraform can create them in parallel or any order, as there is no directed acyclic graph (DAG) edge enforcing a creation sequence.

Exam trap

HashiCorp often tests the misconception that Terraform creates resources in the order they appear in the configuration file, but the actual dependency mechanism is based on explicit references and `depends_on`, not lexical order.

How to eliminate wrong answers

Option A is wrong because there is no `depends_on` or attribute reference from the S3 bucket to the EC2 instance, so Terraform does not require the EC2 instance to be running before creating the bucket. Option B is wrong because Terraform does not use definition order to determine dependencies; it builds a dependency graph based on explicit references and `depends_on` blocks, not the order in the configuration file. Option D is wrong because the EC2 instance does not reference the S3 bucket's name or any attribute (e.g., `aws_s3_bucket.example.bucket`), so no implicit dependency exists; the instance can be created independently of the bucket.

Full explanation →
135
MCQmedium

A team has been managing their AWS infrastructure using a collection of Bash scripts that create resources in a specific order. They frequently encounter issues where resources are created out of order or not properly cleaned up. They want to adopt a more reliable approach that ensures consistent provisioning and teardown. Which action best aligns with Terraform's purpose?

A.Continue using the Bash scripts but add more error handling.
B.Use Terraform but only store state locally on the lead engineer's machine.
C.Convert the scripts into Terraform configuration files and use remote state.
D.Rewrite the scripts as Ansible playbooks for provisioning.
AnswerC

Terraform's declarative model with dependency graph and state solves ordering and consistency.

Why this answer

Terraform's purpose is to manage infrastructure declaratively, handling dependencies and state. Converting to Terraform configs and using the plan/apply workflow ensures consistent provisioning. Continuing with scripts or using Ansible for provisioning are less effective.

Full explanation →
136
MCQhard

Which Terraform feature allows managing multiple separate sets of infrastructure from the same configuration?

A.Workspaces
B.Count
C.Providers
D.For_each
AnswerA

Workspaces create separate state files for each environment using the same configuration.

Why this answer

Workspaces allow you to manage multiple distinct environments (e.g., dev, staging, prod) with the same configuration by maintaining separate state files.

Full explanation →
137
MCQhard

A user accidentally ran `terraform state rm` on a critical resource, removing it from state but not destroying the actual infrastructure. Later, they need to re-import the resource. Which sequence of commands correctly accomplishes this?

A.`terraform state push` with the original state file
B.`terraform plan` and then `terraform apply`
C.`terraform refresh` and then `terraform plan`
D.`terraform import` using the resource address and ID of the resource
AnswerD

Import adds the resource back to state without destroying it.

Why this answer

After removal, the resource is unmanaged. `terraform import` re-associates it with state. Option D is the correct sequence.

Full explanation →
138
MCQeasy

A developer wants to conditionally create a resource based on a variable that is a boolean. Which syntax should they use?

A.Use 'if var.create' inside the resource block
B.Use 'for_each = var.create ? [1] : []'
C.Use 'count = var.create'
D.Use 'count = var.create ? 1 : 0'
AnswerD

Correct pattern: count with ternary.

Why this answer

Option D is correct because in Terraform, the `count` meta-argument accepts a number, and the ternary expression `var.create ? 1 : 0` evaluates to 1 (true) to create one instance of the resource or 0 (false) to create none. This is the standard pattern for conditionally creating a single resource based on a boolean variable.

Exam trap

HashiCorp often tests the distinction between `count` and `for_each` for conditional creation, and the trap here is that candidates mistakenly think `count` can accept a boolean directly or that `for_each` with a single-element list is the correct approach for a simple boolean condition.

How to eliminate wrong answers

Option A is wrong because Terraform does not support an `if` keyword inside a resource block; conditional logic must be implemented using `count` or `for_each`. Option B is wrong because `for_each = var.create ? [1] : []` would work for conditionally creating resources but is unnecessarily complex for a single resource and is not the idiomatic syntax for a boolean variable; `count` is preferred for simple true/false conditions. Option C is wrong because `count = var.create` is invalid since `count` requires a number, not a boolean; Terraform will throw a type error unless the variable is explicitly converted to a number.

Full explanation →
139
MCQhard

Refer to the exhibit. An engineer runs 'terraform plan' and receives an error: 'Error refreshing state: state data in S3 does not have the expected content.' The state file exists and is not corrupted. What is the most likely cause?

A.The state file is locked by another process.
B.The state file was written by a different backend configuration (e.g., different key or workspace).
C.The DynamoDB table does not exist.
D.The S3 bucket is in a different region.
AnswerB

A different backend configuration can produce a state with a different serial, causing this error.

Why this answer

The error indicates that the state data read from S3 does not match what Terraform expects. This can happen if the state file was written by a different backend configuration (e.g., different key or bucket) or if the state file has a different serial. Option C is correct because if a teammate used a different backend configuration to write state (e.g., a different workspace or different key), the state file might have a different serial number causing this error.

Full explanation →
140
Multi-Selecteasy

Which TWO of the following are valid ways to pass variables to Terraform in an automated pipeline?

Select 2 answers
A.Creating a .tfvars file and referencing it with -var-file.
B.Using interactive prompts during terraform apply.
C.Using the -var flag to specify individual variables.
D.Setting environment variables with prefix TERRAFORM_.
E.Using the -vars flag to pass JSON string.
AnswersA, C

Allows multiple variables in file.

Why this answer

Option A is correct because `-var-file` allows you to pass a `.tfvars` file containing variable definitions, which is ideal for automated pipelines where you want to load multiple variables from a version-controlled or dynamically generated file without manual interaction. This approach supports repeatable, non-interactive deployments.

Exam trap

HashiCorp often tests the exact environment variable prefix (`TF_VAR_` vs `TERRAFORM_`) and the existence of non-existent flags like `-vars`, expecting candidates to confuse them with similar-sounding options from other tools.

Full explanation →
141
MCQmedium

A company wants to ensure that Terraform configurations are consistent across teams. What practice should they adopt?

A.Write all code in a single file
B.Use modules from a registry
C.Use provisioners extensively
D.Avoid using variables
AnswerB

Modules encapsulate reusable configuration, ensuring consistency.

Why this answer

Using modules from a registry (e.g., Terraform Registry) promotes reuse, consistency, and best practices across teams.

Full explanation →
142
MCQhard

A Terraform configuration includes a variable for a database password marked as sensitive. When a user runs 'terraform apply', the password appears as (sensitive) in the plan output. However, they want to pass this password to a provisioner as an environment variable. What should they do?

A.Use the variable directly; sensitive only affects CLI output.
B.Use the nonsensitive() function around the variable when assigning.
C.Store the password in a local value with sensitive = false.
D.Remove the sensitive flag from the variable.
AnswerB

nonsensitive() allows using the value but keeps it marked sensitive in state.

Why this answer

Option A is correct because 'nonsensitive()' allows using the value while preserving the sensitive flag in state. Option B would expose the password in logs. Option C is false; sensitive affects output.

Option D does not help.

Full explanation →
143
MCQeasy

After adding a new module sourced from a Git repository with a specific tag, terraform init reports that the module is being downloaded. What is the best practice to ensure the team uses the same version of this module consistently?

A.Use a version constraint in the module block, e.g., version = 1.0.0.
B.Specify the source as the branch name 'main'.
C.Use the 'latest' tag in the source URL.
D.Use a Git tag, like '?ref=v1.0.0', to pin the version.
AnswerD

Tags are immutable references in Git; pinning to a specific tag ensures every team member uses the exact same code.

Why this answer

Option C is correct because using a specific Git tag ensures version control and reproducibility. Option A is wrong because 'latest' tag is not deterministic. Option B is wrong because branch names change over time.

Option D is wrong although version constraints work with registries, not Git sources directly without metadata.

Full explanation →
144
MCQmedium

A DevOps engineer is responsible for maintaining Terraform configurations that manage resources in AWS. The team uses an S3 backend with DynamoDB state locking. The engineer notices that a recent 'terraform plan' command failed with the following error: 'Error: Failed to get existing workspaces: AccessDenied: Access Denied'. Other team members are able to run plans successfully from their machines. The engineer has verified that they have the correct AWS credentials configured via environment variables and that they can list the contents of the S3 bucket using the AWS CLI. The DynamoDB table exists and the engineer can describe it. What is the most likely cause of this error?

A.The DynamoDB table does not have the correct primary key schema.
B.The IAM policy used by Terraform does not include 's3:ListBucket' permission on the S3 bucket.
C.The Terraform configuration has a syntax error in the backend block.
D.The DynamoDB table is not in the same region as the S3 bucket.
AnswerB

The 'get existing workspaces' operation lists objects in the bucket path.

Why this answer

Option B is correct because the error indicates that the IAM user or role does not have permission to call the S3 ListObjects operation on the bucket, even though they can access the bucket directly via CLI (perhaps due to different IAM entity or CLI using different credentials). Option A is wrong because the error message does not mention state lock. Option C is wrong because the engineer can describe the DynamoDB table.

Option D is wrong because the configuration is consistent with other team members.

Full explanation →
145
MCQmedium

You are managing a Terraform configuration that deploys resources across multiple AWS accounts using provider aliases. The configuration uses a single backend (S3) to store the state file. Recently, you discovered that the state file has become very large (over 100 MB) and is causing slow operations and timeouts. The team wants to improve performance without losing the ability to manage all resources with a single `terraform apply`. You need to propose a solution. Which approach should you take?

A.Use state encryption to compress the state file
B.Switch the backend from S3 to Terraform Cloud to improve performance
C.Use Terraform workspaces to separate environments into different state files
D.Split the configuration into separate directories for each environment
AnswerC

Reduces state file size per workspace.

Why this answer

Option C is correct because Terraform workspaces allow you to maintain separate state files for different environments (e.g., dev, prod) while using the same configuration and backend. This reduces the size of each state file, improving performance and avoiding timeouts, while still enabling a single `terraform apply` to manage all resources by targeting the appropriate workspace.

Exam trap

HashiCorp often tests the misconception that splitting configurations into separate directories is equivalent to using workspaces, but the key difference is that workspaces maintain a single configuration and backend, allowing unified `terraform apply` while directories require separate runs.

How to eliminate wrong answers

Option A is wrong because state encryption (e.g., using AWS KMS) does not compress the state file; it only encrypts it at rest, so the file size remains unchanged and performance issues persist. Option B is wrong because switching to Terraform Cloud does not inherently reduce state file size; it may improve backend performance but the underlying large state file still causes slow operations. Option D is wrong because splitting the configuration into separate directories would require running `terraform apply` separately for each directory, breaking the requirement to manage all resources with a single `terraform apply`.

Full explanation →
146
Multi-Selecthard

Which THREE practices are recommended when using Terraform modules? (Select THREE.)

Select 3 answers
A.Design modules to have a single clear purpose.
B.Use version constraints when referencing modules from a registry.
C.Output important resource attributes that consumers may need.
D.Hardcode provider-specific details like region inside the module to simplify usage.
E.Create a new module for each individual resource type.
AnswersA, B, C

Single-responsibility modules are easier to reuse and test.

Why this answer

Option A is correct because Terraform modules should follow the single-responsibility principle: each module should encapsulate a clear, focused purpose (e.g., provisioning a VPC, an EC2 instance, or a database). This makes modules reusable, testable, and easier to compose. A module that tries to do too many things becomes brittle and hard to maintain.

Exam trap

HashiCorp often tests the misconception that modules should be as granular as possible (one per resource type) or that hardcoding provider details simplifies usage, when in fact both practices reduce reusability and violate Terraform best practices.

Full explanation →
147
Drag & Dropmedium

Drag and drop the steps to handle sensitive data in Terraform outputs 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

Sensitive outputs are redacted in CLI; -json reveals raw value for secure handling.

Full explanation →
148
MCQhard

A team manages infrastructure with Terraform. They recently updated the provider version in the configuration from 2.0 to 3.0. After running `terraform init`, they get errors that some resource arguments are no longer valid. What is the best approach to resolve this?

A.Revert the provider version back to 2.0
B.Delete the state file and re-import all resources
C.Run `terraform apply` to force the new provider
D.Change the backend configuration to use a new state file
E.Run `terraform state replace-provider` to update the state
AnswerE

Correct: This updates provider references in state.

Why this answer

Option D is correct because using the `terraform state replace-provider` command updates state to the new provider version. Option A is wrong because reverting to the old provider avoids the issue but is not a long-term solution. Option B is wrong because changing the backend does not affect provider compatibility.

Option C is wrong because re-applying will fail if arguments are invalid. Option E is wrong because state migration is not about deleting state.

Full explanation →
149
Multi-Selecthard

Which THREE statements about module configuration are correct?

Select 3 answers
A.Module sources can be local paths or remote URLs.
B.Version constraints can be specified for any module source.
C.The outputs of a module are available after apply only.
D.A module block can contain multiple resources and child modules.
E.Module inputs can be optional if the module uses a default.
AnswersA, D, E

Terraform supports various source types including local, registry, Git, HTTP, etc.

Why this answer

Options A, B, and E are correct. Module sources can be local paths or remote URLs (A). A module block can contain multiple resources and even child modules (B).

Module inputs can be optional if the module defines a default value (E). Option C is false because outputs from a module can be known during planning (using terraform plan) if the values are deterministic. Option D is false because not all source types support version constraints (e.g., local paths).

Full explanation →
150
Multi-Selecthard

Which THREE of the following are valid Terraform providers?

Select 3 answers
A.hashicorp/azurerm
B.kreuzwerker/docker
C.hashicorp/kubernetes
D.hashicorp/aws
E.hashicorp/cloudwatch
AnswersA, C, D

Official Azure provider.

Why this answer

Option A is correct because `hashicorp/azurerm` is the official Terraform provider for Microsoft Azure, published by HashiCorp in the Terraform Registry. It allows you to manage Azure resources such as virtual machines, storage accounts, and networking components using Terraform's declarative configuration language.

Exam trap

HashiCorp often tests the distinction between official HashiCorp providers and community providers, as well as the misconception that every AWS service has its own dedicated provider, when in fact all AWS services are bundled under the single `hashicorp/aws` provider.

Full explanation →
Page 1

Page 2 of 7

Page 3

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 →