Courseiva

HashiCorp Terraform Associate TF-003 (TF-003) — Questions 301–375

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

Take a mock examExam hub
Page 4

Page 5 of 7

Page 6
301
MCQeasy

A team is using a module from the Terraform Registry and wants to ensure they always get the latest patch version of the 3.2.x series. Which version constraint should they use?

A.~> 3.2
B.3.2.*
C.~> 3.2.0
D.>= 3.2, < 4.0
AnswerC

This allows only patch-level increments within 3.2.x (e.g., 3.2.0 to 3.2.1).

Why this answer

Option C is correct because the pessimistic constraint operator ~> with three parts (e.g., ~> 3.2.0) allows only patch-level changes (3.2.0, 3.2.1, etc.). Option A (~> 3.2) allows minor version updates (3.3, 3.4). Option B (>= 3.2, < 4.0) also allows minor updates.

Option D is invalid syntax.

Full explanation →
302
MCQmedium

A team of five engineers manages infrastructure using Terraform with remote state stored in an S3 bucket and state locking via a DynamoDB table. After a power outage, an engineer notices that a terraform apply command fails with the message: 'Error: Error acquiring the state lock'. The engineer suspects that a lock from a previous run has not been released. The team needs to proceed with applying changes. Which action should the engineer take to resolve the issue safely?

A.Wait for the lock to expire automatically (locks have a 5-minute TTL).
B.Delete the lock record from the DynamoDB table using the AWS CLI.
C.Run terraform force-unlock with the lock ID obtained from the error message.
D.Run terraform apply with the -lock=false flag to bypass locking.
AnswerC

force-unlock is the safe way to remove a lock when the holding process is no longer running.

Why this answer

Option B is correct. terraform force-unlock is the intended method to remove a stuck lock, provided the lock holder process is dead. Option A is incorrect because locks do not automatically expire (unless specially configured with TTL). Option C is risky as directly modifying DynamoDB may lead to inconsistent state.

Option D bypasses locking entirely, which can cause state corruption if other operations are in progress.

Full explanation →
303
MCQhard

A developer creates a module that provisions an AWS EC2 instance and an S3 bucket. The module outputs the instance ID and bucket ARN. When using this module, the root configuration references module.my_module.instance_id and module.my_module.bucket_arn. After running terraform apply, they notice that the bucket ARN is empty. What is the most likely cause?

A.The output is defined in the module but not in the root configuration.
B.The S3 bucket creation depends on another resource that hasn't been created yet.
C.The output value in the module is defined incorrectly, e.g., referencing a non-existent attribute.
D.The IAM role used by Terraform does not have permission to read the bucket ARN.
AnswerC

A misdefined output evaluates to empty or null, leading to an empty value.

Why this answer

Option C is correct because the most likely cause of an empty output value is that the output block in the module references an attribute that does not exist on the resource. For example, if the output is defined as `output "bucket_arn" { value = aws_s3_bucket.my_bucket.arn }` but the resource is actually `aws_s3_bucket.my_bucket` and the correct attribute is `arn`, a typo like `arnn` or `id` would cause Terraform to return an empty string (or an error during plan). Terraform validates attribute references at plan time, but if the attribute is missing or misspelled, the output value will be empty or cause a failure.

Exam trap

HashiCorp often tests the misconception that missing outputs in the root configuration cause empty values, but the real issue is almost always a misconfigured output block in the module itself, such as referencing a wrong attribute name.

How to eliminate wrong answers

Option A is wrong because outputs defined in the root configuration are not required to reference module outputs; the root configuration can directly use module outputs without redefining them. Option B is wrong because dependency ordering does not cause an output to be empty; if the S3 bucket depends on another resource, Terraform will wait for that resource to be created before reading the bucket's attributes, so the output would still be populated. Option D is wrong because IAM permissions affect the ability to create or describe resources, not the ability to read an attribute that is already part of the Terraform state; the bucket ARN is computed by the provider and stored in state, so no read permission is needed to output it.

Full explanation →
304
Multi-Selecteasy

Which TWO statements about Terraform configuration files are correct? (Choose two.)

Select 2 answers
A.All .tf files in subdirectories are automatically loaded.
B.A file named terraform.tfvars is automatically processed.
C.The backend configuration must be defined in the same file as the provider configuration.
D.The -var-file flag accepts a comma-separated list of variable files.
E.Variable definitions files can have .tfvars.json extension.
AnswersB, E

Terraform automatically loads terraform.tfvars if present in the root directory.

Why this answer

Option B and C are correct because Terraform automatically loads terraform.tfvars and also supports .tfvars.json extension. Option A is incorrect because Terraform does not load .tf files recursively by default. Option D is incorrect because the -var-file flag does not accept comma-separated lists; you must use multiple flags.

Option E is incorrect because backend configuration does not have to be in the same file as provider configuration.

Full explanation →
305
Multi-Selectmedium

Which three of the following are valid command-line operations that modify the Terraform state? (Choose three.)

Select 3 answers
A.`terraform plan`
B.`terraform apply -auto-approve`
C.`terraform state rm`
D.`terraform state list`
E.`terraform import`
AnswersB, C, E

Applies changes and updates state.

Why this answer

`terraform import` writes state for imported resources (A correct). `terraform state rm` removes resources from state (B correct). `terraform apply` writes new state (D correct). `terraform state list` and `plan` are read-only.

Full explanation →
306
MCQmedium

A configuration creates multiple AWS instances using count. The developer wants to output the IDs of all instances. Which output block is valid? (Choose the best answer.)

A.output "ids" { value = aws_instance.web.*.id }
B.All of the above
C.output "ids" { value = aws_instance.web[*].id }
D.output "ids" { value = [for i in aws_instance.web : i.id] }
AnswerB

All are valid, including splat and for expressions.

Why this answer

Correct D: All three expressions are valid ways to output a list of IDs from a count resource.

Full explanation →
307
Multi-Selecteasy

Which TWO of the following are valid reasons to use Terraform state?

Select 2 answers
A.Automatically applying changes when configuration files are saved.
B.Storing sensitive data like passwords and API keys.
C.Providing a backup of the infrastructure to restore in case of disaster.
D.Improving performance for large infrastructures by caching resource attributes.
E.Mapping real-world resources to configuration.
AnswersD, E

State caches attribute values, reducing API calls during planning.

Why this answer

Option D is correct because Terraform state acts as a cache for resource attributes, which significantly improves performance for large infrastructures. By storing the current state of resources locally or remotely, Terraform avoids making repeated API calls to the cloud provider for every `plan` or `apply` operation, reducing latency and API rate limits. This caching mechanism is essential for efficiently managing complex deployments with hundreds or thousands of resources.

Exam trap

HashiCorp often tests the misconception that Terraform state is a backup or disaster recovery mechanism, but in reality, it is a mapping and caching layer that must be managed carefully to avoid drift and corruption.

Full explanation →
308
MCQmedium

A DevOps engineer needs to generate multiple similar AWS EC2 instances from a single resource block. They want each instance to have a unique name tag based on an index. Which approach should they use?

A.Use a `locals` block to define multiple resources
B.Use `for_each` and reference `each.key` for the name tag
C.Use a `terraform_data` resource to loop
D.Use `count` and reference `count.index` for the name tag
AnswerD

count creates indexed resources

Why this answer

Option B is correct because `count` creates multiple instances and `count.index` can be used to derive unique names. Option A is wrong because `for_each` expects a map or set, not an index. Option C and D are wrong because they are not mechanisms for generating multiple resources.

Full explanation →
309
MCQmedium

A team has been manually modifying cloud resources outside of Terraform. They now find that Terraform plans show changes that don't match their expectations. What core concept of Terraform's purpose does this situation violate?

A.Declarative configuration with desired state
B.Idempotency
C.Immutable infrastructure
D.Procedural scripting
AnswerA

Terraform uses a desired state model; manual changes violate this principle.

Why this answer

Terraform's purpose is to manage infrastructure based on a declarative desired state. Manual changes cause state drift, making the configuration inconsistent with actual resources. The correct answer is 'Desired state management'.

Full explanation →
310
MCQmedium

A team has a root module that calls a local module using count to conditionally create an AWS RDS instance based on a boolean variable `rds_enabled`. The root module sets `rds_enabled` to the value of a data source that checks if a tag exists on an S3 bucket. The relevant code is: `count = var.rds_enabled ? 1 : 0`. When they run terraform plan, they receive the error: "Error: Invalid count argument: The count value is not yet known". The S3 bucket already exists. What is the underlying issue?

A.Data sources cannot be used in a count condition.
B.The count in a module block cannot depend on a data source.
C.The count value must be known before planning, but data sources are not evaluated until apply without a refresh.
D.The module does not support count.
AnswerC

Terraform needs a known value for count during planning; data sources are not refreshed until apply by default, causing unknown values.

Why this answer

Option C is correct. The count value must be known during planning, but data sources are typically read during the refresh phase of apply (or plan if -refresh-only is used), and if the data source depends on managed resources, it may be unknown. However, in this case, the S3 bucket exists, but Terraform still cannot guarantee the value without refreshing.

The root cause is that data sources are not evaluated before planning unless Terraform performs a refresh, which may require existing state. Option A is false because data sources can be used in count. Option B is false because count works with modules.

Option D is false because modules do support count.

Full explanation →
311
MCQmedium

You are managing a multi-environment Terraform configuration using separate workspaces for 'dev', 'staging', and 'prod'. Each workspace uses the same root module but different variable values stored in terraform.tfvars files per workspace. Your team reports that after a recent change to the root module, running `terraform plan` in the 'dev' workspace shows that it will destroy and recreate a critical RDS database instance, even though no changes were made to the database configuration. The state file for 'dev' is stored in a remote S3 backend with DynamoDB locking. You suspect the issue is related to how Terraform generates and reads configuration. What is the most likely cause?

A.The S3 backend is misconfigured, causing the 'dev' workspace to use the 'prod' state file.
B.A new variable with a default value that forces recreation of the database was added to the root module, but the 'dev' workspace's tfvars file does not override it, so Terraform uses the default which differs from the current state.
C.The root module was changed to use a different Terraform provider version that is incompatible with the existing state.
D.The DynamoDB lock is not being released after previous operations, causing state corruption.
AnswerB

This is a common issue: adding a variable with a default that differs from the existing attribute causes a plan to update in-place or recreate.

Why this answer

Option B is correct because when a new variable with a default value is added to the root module, and the 'dev' workspace's terraform.tfvars does not override it, Terraform uses the default value. If that default differs from the value currently tracked in the state (e.g., a database engine version or instance class), Terraform interprets this as a configuration change and plans to destroy and recreate the resource to match the new default. This is a common pitfall when variables are introduced without updating all workspace-specific variable files.

Exam trap

HashiCorp often tests the misconception that state corruption or backend misconfiguration is the root cause, when the real issue is Terraform's variable default behavior and its interaction with 'ForceNew' attributes in resource schemas.

How to eliminate wrong answers

Option A is wrong because a misconfigured S3 backend would typically cause an error or use the wrong workspace entirely, but the question states the 'dev' workspace is being used and the state file is stored correctly; using the 'prod' state would produce different resource addresses, not a targeted destroy/recreate of the same database. Option C is wrong because an incompatible provider version would cause a provider initialization error or state serialization mismatch, not a clean plan showing destroy/recreate of a single resource without provider-related errors. Option D is wrong because DynamoDB lock issues would prevent Terraform from acquiring a lock or cause a locking error, not silently corrupt state to produce a false destroy/recreate plan; state corruption typically manifests as parse errors or inconsistent results, not a coherent plan.

Full explanation →
312
MCQhard

A company uses Terraform Cloud and wants to enforce policies that prevent creating resources with public IP addresses unless explicitly approved. What Terraform Cloud feature should they use?

A.Sentinel policies
B.VCS integration
C.Workspaces
D.Run tasks
AnswerA

Sentinel is a policy-as-code framework that can enforce rules before apply.

Why this answer

Option C is correct because Sentinel is the policy-as-code framework in Terraform Cloud. Option A is wrong because workspaces are for state isolation, not policy. Option B is wrong because VCS integration is for triggering runs.

Option D is wrong because run tasks allow custom validation but Sentinel is the built-in policy engine.

Full explanation →
313
MCQeasy

An organization wants to ensure that running the same Terraform configuration multiple times produces the same result without unintended changes. Which IaC concept is most critical for this goal?

A.Dynamic provider credentials
B.Modularity
C.Version control
D.Idempotency
AnswerD

Idempotency guarantees repeated runs produce the same outcome.

Why this answer

Idempotency ensures that applying the same Terraform configuration multiple times results in the same desired state, with no unintended changes on subsequent runs. Terraform achieves this by comparing the current state (stored in a state file) with the desired configuration and only making changes necessary to reconcile differences. This is the core principle behind Terraform's 'plan and apply' workflow, which guarantees repeatable infrastructure provisioning.

Exam trap

HashiCorp often tests the distinction between 'version control' and 'idempotency' by presenting version control as a plausible answer, since it is a fundamental IaC practice, but the question specifically asks about producing the same result across multiple runs, which is the definition of idempotency.

How to eliminate wrong answers

Option A is wrong because dynamic provider credentials (e.g., using AWS STS AssumeRole) relate to authentication and access control, not to ensuring repeatable, unchanged results across multiple runs. Option B is wrong because modularity improves code organization and reusability but does not inherently guarantee that repeated executions produce the same outcome; a non-idempotent module can still cause drift. Option C is wrong because version control tracks changes to configuration files over time but does not enforce that applying the same configuration multiple times yields identical infrastructure state; it is a best practice for collaboration, not a mechanism for idempotent execution.

Full explanation →
314
MCQhard

Refer to the exhibit. An engineer sees this error. Which command should they run to force-unlock?

A.terraform force-unlock my-company-terraform-state/prod/terraform.tfstate
B.terraform unlock -id=123456
C.terraform state unlock 123456
D.terraform init -force-unlock=123456
E.terraform force-unlock 123456
AnswerE

This is the correct command using the lock ID.

Why this answer

The `terraform force-unlock` command requires the lock ID as an argument. In the exhibit, the lock ID is '123456', so the correct command is `terraform force-unlock 123456`. Other options use incorrect syntax or incorrect identifiers.

Full explanation →
315
MCQhard

During a `terraform apply`, the operation fails mid-way due to a network outage, leaving some resources created. The operator wants to resume applying from where it left off without destroying the already-created resources. What should they do?

A.Run terraform apply again
B.Run terraform destroy and then apply
C.Run terraform refresh
D.Run terraform apply -auto-approve
AnswerA

Idempotent; creates missing resources.

Why this answer

Option A is correct because Terraform uses a state file to track the resources it manages. When `terraform apply` fails mid-way, the state file is updated to reflect the resources that were successfully created. Running `terraform apply` again will cause Terraform to compare the current state with the configuration, detect that the already-created resources exist, and proceed to create only the remaining resources, effectively resuming from where it left off without destroying anything.

Exam trap

The trap here is that candidates may think a failed apply requires a full destroy or refresh, but Terraform's state-driven design allows idempotent resumption, and the exam tests understanding that `terraform apply` is the correct command to re-run after any partial failure.

How to eliminate wrong answers

Option B is wrong because `terraform destroy` would delete all resources, including those already created, which defeats the goal of resuming without destruction. Option C is wrong because `terraform refresh` only updates the state file to match real-world infrastructure; it does not create any resources or resume a failed apply. Option D is wrong because `terraform apply -auto-approve` simply skips the interactive approval prompt; it does not change the core behavior of the apply command and would still work correctly, but the key issue is that the operator must run `terraform apply` again, and the `-auto-approve` flag is irrelevant to the question's focus on resuming without destruction.

Full explanation →
316
MCQmedium

An operator runs 'terraform plan' and sees that a resource will be replaced. They want to avoid destroying the resource, but still apply other changes. What should they do?

A.Use 'terraform apply -replace=resource_address' to replace only that resource.
B.Add a 'lifecycle' block with 'create_before_destroy = true'.
C.Set 'ignore_changes' to the attribute causing the replacement.
D.Add 'prevent_destroy = true' to the resource.
AnswerB

Creates new resource before destroying old one, reducing downtime.

Why this answer

Option B is correct because adding a `lifecycle` block with `create_before_destroy = true` instructs Terraform to create the new resource before destroying the old one, which avoids downtime but does not prevent the resource from being replaced. However, the question asks how to avoid destroying the resource entirely while still applying other changes. The correct approach is to use `ignore_changes` to exclude the attribute that triggers the replacement, so Terraform will not attempt to modify that attribute and thus will not schedule a destroy.

Option B is marked as correct in the provided answer key, but this is a common exam trap: `create_before_destroy` does not prevent destruction; it only reorders the lifecycle. The actual solution to avoid destruction is to use `ignore_changes` or `prevent_destroy` depending on the goal.

Exam trap

HashiCorp often tests the misconception that `create_before_destroy` prevents destruction, when in reality it only changes the order of operations; the trap here is that candidates confuse lifecycle ordering with lifecycle prevention, leading them to select B instead of the correct option C.

How to eliminate wrong answers

Option A is wrong because `terraform apply -replace=resource_address` explicitly forces Terraform to destroy and recreate that specific resource, which is the opposite of avoiding destruction. Option C is wrong because setting `ignore_changes` to the attribute causing the replacement tells Terraform to ignore future changes to that attribute, thereby preventing the replacement from being triggered; this is the correct technical solution to avoid destroying the resource while applying other changes. Option D is wrong because `prevent_destroy = true` prevents any destroy operation on the resource, which would block the replacement but also block any other changes that require modification of the resource (e.g., in-place updates that Terraform cannot perform), leading to an error during apply.

Full explanation →
317
Multi-Selectmedium

Which three of the following describe correct practices or behaviors when interacting with Terraform modules? (Choose three.)

Select 3 answers
.A module source can be a local file path, such as './modules/networking'.
.The `terraform get` command downloads and updates module sources from remote registries.
.Module outputs are accessible from the root configuration using the syntax `module.<MODULE_NAME>.<OUTPUT_NAME>`.
.Terraform modules can only be sourced from the public Terraform Registry.
.When using a module from a Git repository, Terraform automatically applies any local changes made inside the `.terraform/modules` directory.
.Module input variables are automatically populated from environment variables without explicit variable declarations.

Why this answer

Option null is correct because Terraform modules can be sourced from a local file path using the `source` argument, such as `'./modules/networking'`, which allows referencing modules stored within the same repository or filesystem. This is a fundamental feature for organizing infrastructure code without relying on remote registries.

Exam trap

HashiCorp often tests the misconception that modules can only come from the public Terraform Registry, but the exam expects you to know that local paths, Git repos, and HTTP URLs are also valid sources.

Full explanation →
318
MCQhard

A CI/CD pipeline runs 'terraform plan' and needs to automatically approve only if no resources will be destroyed. Which approach should be used?

A.Run 'terraform apply -auto-approve' after a successful plan.
B.Run 'terraform plan -destroy' and check the exit code.
C.Run 'terraform fmt' to check for formatting issues.
D.Run 'terraform validate' to ensure no destroys are needed.
E.Run 'terraform plan -out=plan.tfplan', then 'terraform show -json plan.tfplan' and parse the output for destroy actions.
AnswerE

Correctly parses the plan to detect destroy actions.

Why this answer

Option A is correct because 'terraform show -json plan.tfplan' outputs the plan in JSON format, which can be parsed to detect destroy actions. Option B is wrong because '-destroy' flag always shows destroy actions, not a detection method. Option C is wrong because auto-approve would apply without checking.

Option D is wrong because validate only checks syntax, not changes. Option E is wrong because fmt only formats code.

Full explanation →
319
MCQmedium

A developer accidentally deleted a resource from the Terraform state file using 'terraform state rm'. The resource still exists in the cloud provider. How can the developer re-import the resource without affecting other resources?

A.Re-run 'terraform apply' to recreate the resource.
B.Use 'terraform state push' with a previous state backup.
C.Run 'terraform refresh' to discover and add the resource.
D.Use 'terraform import' with the resource address and ID.
AnswerD

Import adds the resource back to state.

Why this answer

Option A is correct because 'terraform import' can re-import the specific resource using its ID. Option B is wrong because 'terraform apply' with existing state would try to create the resource, potentially conflicting. Option C is wrong because 'terraform refresh' would not add the resource; it only updates existing state.

Option D is wrong because 'terraform state push' is for pushing a state file, not importing.

Full explanation →
320
MCQhard

An organization has a multi-cloud strategy using Terraform. They need to ensure that secrets such as API keys are not stored in plaintext in the configuration files. Which Terraform feature should they use to securely manage sensitive data?

A.Terraform variable definitions with environment variables
B.Terraform workspaces
C.Integration with a secrets management tool like Vault
D.Terraform state file encryption
E.Terraform's sensitive parameter in output blocks
AnswerC

Vault provides secure storage and dynamic secrets, keeping them out of configuration files.

Why this answer

Option E is correct because integrating with a secrets management tool like Vault provides secure storage and retrieval of secrets. Option A (workspaces) separates state but not secrets. Option B (state encryption) protects state but not the source code.

Option C (environment variables) still exposes secrets in the execution environment. Option D (sensitive parameter) only masks output, not the source.

Full explanation →
321
MCQhard

An organization uses Terraform Cloud workspaces to manage multiple environments. They notice that after promoting a configuration change from development to production workspace, the production workspace's state file contains references to resources that were only created in development. What is the most likely cause?

A.The workspaces were configured to use the same S3 backend and prefix, causing state overlap.
B.The user ran `terraform state mv` to move resource instances from development to production workspace.
C.A user manually edited the production state file to include development resources.
D.The development workspace's output values were used in production via `terraform_remote_state`.
AnswerB

This directly moves resource addresses between workspace states.

Why this answer

Option C is correct because `terraform state mv` can move resources between workspace state files. Options A and D would cause data references but not state file content changes. Option B is unlikely as manual editing is error-prone.

Full explanation →
322
MCQhard

You are a platform engineer at a large e-commerce company that uses Terraform Enterprise to manage thousands of infrastructure resources across multiple teams. The company has a central 'networking' workspace that provisions shared VPCs and subnets, and several application workspaces that consume these networking resources via remote state data sources. Recently, the networking team changed the CIDR block of a shared subnet from '10.0.1.0/24' to '10.0.2.0/24' and applied the change successfully. However, the application teams are now reporting that their Terraform runs are failing with errors indicating that the subnet ID they reference does not exist. The application workspaces use the following configuration to consume the subnet: ```hcl data "terraform_remote_state" "networking" { backend = "remote" config = { organization = "mycompany" workspaces = { name = "networking" } } } resource "aws_instance" "app" { subnet_id = data.terraform_remote_state.networking.outputs.subnet_id ... } ``` The application workspaces have not been modified recently. The networking workspace output 'subnet_id' now contains the ID of the updated subnet. What is the most likely cause of the failures?

A.The application workspaces do not have permission to read the networking workspace's state.
B.The networking workspace output variable 'subnet_id' was removed or renamed.
C.The application workspaces are using a cached version of the remote state outputs and need to run 'terraform plan' to refresh.
D.The application workspaces need to update the remote state data source to reference the new subnet ID.
AnswerC

Terraform caches remote state data for the duration of a run; a new plan refreshes the data.

Why this answer

Option C is correct because Terraform caches remote state data during the planning phase, and the `terraform_remote_state` data source only fetches the latest state when `terraform plan` or `terraform apply` is executed. Since the application workspaces have not been modified or re-planned, they are using a stale cached version of the networking workspace's outputs, which still contains the old subnet ID. Running `terraform plan` forces a refresh of the remote state data, retrieving the updated `subnet_id` and resolving the error.

Exam trap

The trap here is that candidates may assume the remote state data source always reads the latest state on every run, when in fact Terraform caches the data from the last plan and only refreshes it during a new plan or apply operation.

How to eliminate wrong answers

Option A is wrong because if the application workspaces lacked permission to read the networking workspace's state, the error would be an authorization failure (e.g., 403 Forbidden), not a 'subnet ID does not exist' error. Option B is wrong because the scenario explicitly states that the networking workspace output 'subnet_id' now contains the ID of the updated subnet, meaning the output was not removed or renamed. Option D is wrong because the remote state data source configuration does not need to be updated; it already references the correct workspace and output name, and the issue is simply that the cached data is stale.

Full explanation →
323
MCQmedium

A company has a Terraform configuration that creates many AWS resources. They want to check the estimated cost of the plan before applying. Which approach should they use?

A.Use 'terraform plan -cost' command.
B.Manually use 'terraform show -json' and parse pricing.
C.Enable cost estimation in Terraform Cloud.
D.Use 'terraform validate' with a custom script.
AnswerC

Terraform Cloud can estimate costs for AWS resources.

Why this answer

Option A is correct because Terraform Cloud provides cost estimation as a built-in feature. Options B and D are not available. Option C is a manual analysis but not a built-in feature.

Full explanation →
324
MCQeasy

A user wants to use a remote state backend for the first time. After adding the backend configuration, which command must they run to migrate the state from local to remote?

A.`terraform plan`
B.`terraform init`
C.`terraform apply`
D.`terraform state push`
AnswerB

This command initializes the backend and offers to copy state.

Why this answer

`terraform init` with backend configuration will prompt to migrate state. Option A correct. Options B, C, D are not designed for initial migration.

Full explanation →
325
MCQhard

A user runs `terraform plan` and notices that the plan includes 'Outgoing changes' for a number of resources that were not modified in the configuration. What is the most likely cause?

A.The provider version has changed.
B.The resources were manually changed in the cloud provider.
C.The backend configuration changed.
D.The state file is outdated and needs to be refreshed.
AnswerD

State may not reflect current infrastructure, causing planned changes.

Why this answer

`terraform plan` compares configuration to state. If state is outdated (e.g., after manual changes), plan will show drift even without config changes. Option A correct.

Option B could cause, but less likely. Option C is possible but most likely state is not refreshed. Option D unrelated.

Full explanation →
326
MCQeasy

A DevOps engineer is managing a multi-cloud infrastructure using Terraform. The team relies on a module sourced from the Terraform Registry to deploy a standard web application. This module defines an input variable called 'instance_count' with a default value of 2. For the production environment, the engineer wants to deploy 3 instances. They create a root module configuration that references the module. In the root module's main.tf, they write a block that sets instance_count = 3. However, when they run terraform plan, the output indicates that the module will still use instance_count = 2. The engineer double-checks the configuration: the root module's main.tf is syntactically correct, the module source points to the correct registry module and version, and they have run terraform init and terraform validate without errors. What is the most likely reason the variable override is not taking effect?

A.The module version specified does not support variable overrides; the engineer must use a different module.
B.The variable 'instance_count' is not declared as an input variable in the child module's variables.tf.
C.The engineer forgot to run terraform init after modifying the root module's configuration.
D.The root module defines instance_count as a local value rather than passing it as an argument to the module block.
AnswerD

To override a module variable, it must be passed as an argument within the module block (e.g., module "web" { instance_count = 3 }). A local value does not affect the module.

Why this answer

Option B is correct because the most common mistake is defining the variable as a local value rather than passing it as an argument to the module block. Option A is incorrect because the variable exists in the module (it has a default). Option C is incorrect because terraform init is not required for variable changes; terraform validate passed, so syntax is fine.

Option D is incorrect because module version does not affect variable overrides.

Full explanation →
327
MCQhard

An organization uses Terraform with a remote backend in Azure. After a network outage, a developer attempts to run `terraform apply` and receives the error: "Error: Failed to get existing workspaces: blob (key) not found". What is the most likely cause?

A.The Terraform backend configuration has incorrect access key
B.The Azure storage account was deleted
C.The state file for the current workspace was deleted or corrupted
D.The workspace was not created via `terraform workspace new`
AnswerC

Correct! The blob key for the workspace's state is missing, so Terraform cannot find the state.

Why this answer

Option C is correct because the error 'blob (key) not found' indicates that Terraform cannot locate the state file for the current workspace in the Azure storage container. After a network outage, the state file may have been deleted or corrupted, preventing Terraform from reading the existing state. This error is specific to the missing blob key, not to authentication or storage account availability.

Exam trap

HashiCorp often tests the distinction between authentication/authorization errors and resource-not-found errors; the trap here is that candidates may confuse a missing state file with a misconfigured backend or deleted storage account, but the specific 'blob (key) not found' message points directly to the state file blob being absent.

How to eliminate wrong answers

Option A is wrong because an incorrect access key would produce an authentication error (e.g., 'Failed to obtain existing workspaces: storage: service returned error: StatusCode=403'), not a 'blob not found' error. Option B is wrong because if the storage account were deleted, the error would indicate that the container or account does not exist (e.g., 'The specified storage account was not found'), not that a specific blob key is missing. Option D is wrong because workspaces are created via `terraform workspace new` only when using multiple workspaces; the default workspace exists without explicit creation, and the error is about the state file itself, not workspace existence.

Full explanation →
328
MCQeasy

Which Terraform command is used to validate the syntax of configuration files without accessing any cloud provider?

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

Validates syntax and internal consistency without accessing providers.

Why this answer

`terraform validate` checks syntax and internal consistency of configuration files. `init` initializes backends and providers, `plan` accesses remote state, `fmt` formats code.

Full explanation →
329
Multi-Selectmedium

Which three of the following are core characteristics of Terraform's execution plan? (Choose three.)

Select 3 answers
.It is generated by the `terraform plan` command.
.It shows what actions Terraform will take to reach the desired state.
.It can be saved to a file and later applied using `terraform apply` with that file.
.It automatically applies changes to infrastructure without user confirmation.
.It only shows changes for resources that were manually modified outside Terraform.
.It is a read-only view of the current state file with no indication of future actions.

Why this answer

The `terraform plan` command generates an execution plan that shows exactly what actions Terraform will take to reach the desired state defined in the configuration. This plan can be saved to a file and later applied using `terraform apply` with that file, ensuring the exact same changes are executed. These three characteristics are fundamental to Terraform's workflow, providing a safe and predictable way to manage infrastructure changes.

Exam trap

HashiCorp often tests the misconception that the execution plan is an automatic apply mechanism or that it only detects drift from manual changes, when in fact it is a deliberate, user-initiated preview that compares the entire configuration against the current state.

Full explanation →
330
MCQhard

A Terraform configuration uses `count` to create multiple EC2 instances. After adding a new variable for instance type, the user runs `terraform plan` and sees that all instances are marked for recreation. What is the most likely cause?

A.The `count` index changed, causing all resources to be re-indexed
B.The user forgot to run `terraform refresh` after changing the variable
C.The state file is corrupt and needs to be refreshed
D.The variable change triggers a new value for each resource, causing Terraform to see differences
E.The provider version is incompatible with the new variable type
AnswerD

Correct: Changing attributes on a resource with count may cause recreation.

Why this answer

Option A is correct because `count` treats the resource as a list; changing `count` or any argument used in the resource can cause recreation. Option B is wrong because the state file is not modified by plan. Option C is wrong because re-indexing only happens if the order changes, not for all.

Option D is wrong because `terraform refresh` does not alter config. Option E is wrong because provider issues do not cause this.

Full explanation →
331
MCQeasy

A developer wants to see the list of resources currently managed by Terraform in the state file. Which command should they use?

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

Lists all resources in the state file.

Why this answer

`terraform state list` lists all resources in the state. `output` shows outputs, `show` shows state or plan details, `graph` creates a dependency graph.

Full explanation →
332
MCQhard

You are a platform engineer at a fintech company. Your team manages a multi-region application on AWS using Terraform. The infrastructure includes VPCs, subnets, EC2 instances, and an Application Load Balancer (ALB). The configuration uses modules from the Terraform Registry and remote state in S3 with DynamoDB locking. Recently, after a colleague ran `terraform apply` in the us-east-1 region, the application experienced downtime because the ALB's target group was accidentally updated to point to instances in us-west-2 instead of us-east-1. The root cause was that the Terraform configuration for the ALB used a variable `target_region` which was hardcoded to us-west-2 in a `terraform.tfvars` file that was not intended for that workspace. Your team wants to prevent such misconfigurations in the future. Which course of action would most effectively reduce the risk of using incorrect variable values across workspaces?

A.Implement a CI/CD pipeline that runs `terraform plan` for every workspace and requires manual approval before apply
B.Use the same S3 backend for all regions but with different state file keys, and enforce naming conventions
C.Store all variables in a single `terraform.tfvars` file and use conditionals with `terraform.workspace` to select values
D.Create separate Terraform configurations for each region, each with its own backend configuration and variable files, and use directory structure to enforce separation
AnswerD

Physical separation prevents accidental use of wrong variable files.

Why this answer

Option D is correct because creating separate Terraform configurations for each region enforces strict isolation at the directory and backend level, preventing accidental cross-region variable injection. This approach ensures that each region's configuration has its own dedicated variable files and state, eliminating the risk of a `terraform.tfvars` file from one workspace affecting another. It aligns with infrastructure-as-code best practices for multi-region deployments where environment boundaries must be explicit.

Exam trap

The trap here is that candidates often assume workspaces provide sufficient isolation for multi-region deployments, but workspaces share the same variable files and backend configuration, making them unsuitable for preventing cross-region variable misconfigurations.

How to eliminate wrong answers

Option A is wrong because a CI/CD pipeline with manual approval only adds a process gate but does not prevent the root cause—the hardcoded variable value in the tfvars file—and can still allow the same misconfiguration to pass through if the plan output is not carefully reviewed. Option B is wrong because using the same S3 backend with different state file keys and naming conventions does not prevent a developer from accidentally applying a configuration that references the wrong region variable; it only organizes state files, not variable values. Option C is wrong because storing all variables in a single tfvars file with conditionals based on `terraform.workspace` still allows a single file to contain the wrong default or a typo, and it does not enforce separation of concerns; a misconfigured workspace name could still select the wrong value.

Full explanation →
333
MCQeasy

Which Terraform command is used to check the syntax and internal consistency of configuration files?

A.terraform validate
B.terraform fmt
C.terraform plan
D.terraform graph
AnswerA

Validates syntax and internal consistency.

Why this answer

Correct D: terraform validate checks syntax and internal consistency. Option A formats code, B shows execution plan, C generates a graph of dependencies.

Full explanation →
334
MCQeasy

What is the most likely cause of this error?

A.The AWS credentials used do not have permission to launch EC2 instances.
B.The Terraform configuration has a syntax error.
C.The instance type 't2.micro' is not available in the region.
D.The AMI ID is invalid or does not exist in the region.
AnswerA

UnauthorizedOperation error indicates lack of permissions.

Why this answer

The error is most likely caused by insufficient AWS permissions because Terraform uses the configured AWS credentials to make API calls. If the IAM user or role lacks the `ec2:RunInstances` permission, the API will return an authorization error, even if the configuration is syntactically correct and the AMI/instance type are valid.

Exam trap

HashiCorp often tests the distinction between API authorization errors (HTTP 403) and resource validation errors (HTTP 400), leading candidates to confuse permission issues with configuration mistakes like invalid AMIs or unavailable instance types.

How to eliminate wrong answers

Option B is wrong because a syntax error in Terraform configuration would be caught during `terraform validate` or `terraform plan` with a specific parser error message, not an AWS API authorization error. Option C is wrong because if 't2.micro' were unavailable in the region, the error would indicate an 'Unsupported' or 'InsufficientInstanceCapacity' message, not a permissions failure. Option D is wrong because an invalid or missing AMI ID would return an 'InvalidAMIID.NotFound' or 'InvalidAMIID.Malformed' error from the EC2 API, not an authorization error.

Full explanation →
335
Multi-Selectmedium

Which TWO of the following are valid use cases for using Terraform Cloud's Sentinel policies? (Choose two.)

Select 2 answers
A.Provide cost estimates for infrastructure changes
B.Enforce that all Terraform code follows a specific formatting style
C.Enforce that all AWS instances are of a specific type
D.Automatically rotate database passwords
E.Enforce that all resources have required tags
AnswersC, E

Sentinel can restrict resource attributes.

Why this answer

Option C is correct because Sentinel policies can enforce that all AWS instances are of a specific type by using a `validate` rule that checks the `aws_instance` resource's `instance_type` attribute against an allowed list. This is a common compliance use case for Sentinel in Terraform Cloud, where policy-as-code ensures infrastructure adheres to organizational standards before provisioning.

Exam trap

HashiCorp often tests the distinction between Sentinel's policy enforcement capabilities and other Terraform Cloud features (like cost estimation or formatting tools), so candidates mistakenly select options that are valid Terraform functions but not Sentinel use cases.

Full explanation →
336
MCQmedium

A DevOps engineer needs to integrate Terraform with a CI/CD pipeline. What is a common practice?

A.Run terraform plan in a pull request
B.Avoid using variables
C.Use -auto-approve always
D.Store state in a local file
AnswerA

Plan in PRs gives visibility into changes before apply.

Why this answer

Running `terraform plan` in a pull request allows team members to review proposed changes before applying them, promoting collaboration and safety.

Full explanation →
337
MCQeasy

Refer to the exhibit. What will happen when terraform plan is run?

A.It will fail with an error about missing required argument.
B.It will prompt for the bucket name.
C.It will create a bucket with a random name.
D.It will succeed because bucket name can be generated automatically.
AnswerA

Correct. The bucket argument is required for aws_s3_bucket.

Why this answer

The aws_s3_bucket resource requires a bucket name argument. Without it, Terraform will return an error indicating a missing required argument.

Full explanation →
338
MCQmedium

Based on the exhibit, what will happen to the existing Elastic IP (aws_eip.web_eip) when this plan is applied?

A.It will remain unchanged
B.It will be updated in-place
C.It will be created
D.It will be destroyed
AnswerD

The '-' symbol indicates destroy.

Why this answer

Option D is correct because the Terraform configuration shows that the `aws_eip.web_eip` resource is no longer defined in the configuration after the plan is applied. Terraform will detect that the resource exists in the state but is absent from the configuration, and by default, it will destroy the Elastic IP to reconcile the state with the configuration. This is standard Terraform behavior for resources removed from `.tf` files.

Exam trap

HashiCorp often tests the misconception that removing a resource from configuration leaves it unchanged in the cloud, but Terraform's default behavior is to destroy any resource not present in the configuration, unless lifecycle rules or `removed` blocks are used.

How to eliminate wrong answers

Option A is wrong because Terraform does not leave orphaned resources; if a resource is removed from the configuration, it will be destroyed unless explicitly protected with `prevent_destroy` or `lifecycle` settings. Option B is wrong because in-place updates occur only when the resource still exists in the configuration but has attribute changes; here the resource is entirely absent, so no update is possible. Option C is wrong because the resource already exists in the state (as indicated by the exhibit showing an existing Elastic IP), so Terraform will not create a new one; it will destroy the existing one.

Full explanation →
339
Multi-Selectmedium

Which TWO of the following are best practices when writing Terraform configuration for a team? (Select TWO.)

Select 2 answers
A.Always use the `latest` version for providers.
B.Pin provider versions using `required_providers`.
C.Hardcode all values in the configuration for simplicity.
D.Use a remote backend with state locking.
E.Store the entire infrastructure in a single configuration file.
AnswersB, D

ensures consistent behavior

Why this answer

Options A and E are correct. Using remote state with locking prevents conflicts, and pinning provider versions ensures reproducibility. Option B is wrong because using `latest` is not reproducible.

Option C is wrong because hardcoding secrets is insecure. Option D is wrong because large monolithic configurations are harder to maintain.

Full explanation →
340
MCQhard

A team is using Terraform to manage multiple environments (dev, staging, prod) with the same configuration but different variable values. They want to avoid duplicating configuration files. Which Terraform feature is best suited for this?

A.Terraform modules with separate directories for each environment
B.Terraform data sources to fetch environment-specific variables
C.Using multiple Terraform configuration files in a single directory
D.Terraform workspaces
AnswerD

Workspaces enable multiple environments with one configuration.

Why this answer

Terraform workspaces allow you to manage multiple environments (e.g., dev, staging, prod) using the same root configuration and variable definitions, but with separate state files. This avoids duplicating configuration files while enabling environment-specific variable values via `terraform.workspace` interpolation or separate `.tfvars` files per workspace. Option D is correct because workspaces are the native Terraform feature designed for this exact use case.

Exam trap

HashiCorp often tests the misconception that Terraform modules (Option A) are the primary tool for environment separation, but modules are for code reuse, not state isolation—workspaces handle state separation without duplicating configuration.

How to eliminate wrong answers

Option A is wrong because using separate directories for each environment with modules still duplicates the root configuration and state files, which is exactly what the team wants to avoid. Option B is wrong because data sources are used to fetch or compute data from providers (e.g., AWS, Azure) at plan/apply time, not to manage environment-specific variable values or state separation. Option C is wrong because placing multiple configuration files in a single directory does not inherently separate state or variable values per environment; it would still require manual management and risks state corruption.

Full explanation →
341
MCQhard

A Terraform configuration uses a module from the public registry. After a provider update, the module's resources fail to create. What is the most probable cause?

A.The provider binary is corrupted
B.The state file is corrupted
C.The module is incompatible with the new provider version
D.The backend configuration is incorrect
AnswerC

Most likely cause; module may depend on removed or changed provider features.

Why this answer

Provider updates often introduce breaking changes, and modules may rely on older provider features. Incompatibility with a new provider version can cause failures. Other options are less likely.

Full explanation →
342
MCQeasy

What is the primary purpose of 'terraform init'?

A.To format the Terraform configuration files.
B.To apply changes to the infrastructure.
C.To preview infrastructure changes before applying them.
D.To initialize the working directory, download providers, and set up the backend.
AnswerD

Init prepares the directory for other commands.

Why this answer

The 'terraform init' command is the first step in the core Terraform workflow. Its primary purpose is to initialize the working directory containing Terraform configuration files, download and install the required provider plugins (e.g., AWS, Azure, GCP), and configure the backend (e.g., local, S3, Terraform Cloud) for state storage. Without running 'terraform init', subsequent commands like 'terraform plan' or 'terraform apply' will fail because the providers and backend are not set up.

Exam trap

HashiCorp often tests the distinction between the initialization phase and the planning/execution phases, so the trap here is that candidates confuse 'terraform init' with 'terraform plan' or 'terraform apply' because they all appear early in the workflow, but only 'init' handles provider and backend setup.

How to eliminate wrong answers

Option A is wrong because 'terraform fmt' is the command used to format Terraform configuration files, not 'terraform init'. Option B is wrong because 'terraform apply' is the command that applies changes to the infrastructure, not 'terraform init'. Option C is wrong because 'terraform plan' is the command used to preview infrastructure changes before applying them, not 'terraform init'.

Full explanation →
343
Multi-Selectmedium

Which TWO of the following are valid ways to use Terraform outside the core workflow (i.e., in automation or CI/CD pipelines)?

Select 2 answers
A.Using the Terraform CLI in a CI/CD pipeline with -auto-approve after a successful plan.
B.Using 'terraform state mv' to reorganize state files.
C.Using 'terraform init -from-module' to force module re-download.
D.Using the Terraform Cloud API to trigger runs and check results.
E.Using 'terraform graph' to generate visual output.
AnswersA, D

Common automation pattern.

Why this answer

Options A and D are correct. A uses the CLI with -auto-approve in a pipeline. D uses the Terraform Cloud API to trigger runs.

B is not a common pattern. C is for state migration. E is a tool for visualization, not automation.

Full explanation →
344
MCQeasy

A developer runs `terraform plan` and it fails with a provider plugin error. Which command should they run first to resolve the issue?

A.terraform validate
B.terraform apply
C.terraform fmt
D.terraform init
AnswerD

Downloads required provider plugins and reinitializes the backend.

Why this answer

The `terraform init` command is the correct first step because it initializes the working directory, downloads the required provider plugins, and sets up the backend configuration. A provider plugin error typically indicates that the provider plugins are missing, outdated, or not properly installed, and `terraform init` resolves this by fetching the correct versions from the Terraform registry.

Exam trap

HashiCorp often tests the misconception that `terraform validate` can fix runtime errors, but candidates must remember that `validate` only checks syntax and schema, not the availability of external dependencies like provider plugins.

How to eliminate wrong answers

Option A is wrong because `terraform validate` checks the syntax and internal consistency of the configuration files but does not download or install provider plugins, so it cannot fix a missing or corrupted provider. Option B is wrong because `terraform apply` attempts to execute the plan and apply changes, but it will fail if the provider plugins are not available, and it is not designed to resolve plugin installation issues. Option C is wrong because `terraform fmt` only reformats the configuration files for consistent style and has no effect on provider plugin availability or installation.

Full explanation →
345
Multi-Selectmedium

Which TWO of the following are core components of Terraform's workflow? (Select TWO.)

Select 2 answers
A.terraform validate
B.terraform init
C.terraform install
D.terraform destroy
E.terraform plan
AnswersB, E

Initializes providers, modules, and backend configuration.

Why this answer

Options A and C are correct. `terraform init` initializes the working directory, and `terraform plan` creates an execution plan. Option B is not a valid command. Option D (`validate`) is a subcommand but not part of the core workflow (init, plan, apply).

Option E (`destroy`) is a separate command, not part of the core provisioning workflow.

Full explanation →
346
MCQhard

A company uses Terraform workspaces to manage environments. They have a monorepo with separate configurations for each environment. They want to introduce a new team that will manage only the staging environment. The new team will run terraform commands only on the staging workspace. They are using a single S3 backend for all workspaces. The team is concerned about accidentally applying changes to other workspaces. What is the best way to restrict the team's access?

A.Create a separate S3 bucket for staging and configure a different backend.
B.Use Terraform Cloud with team-based permissions.
C.Use terraform workspace select staging in the CI/CD pipeline and only allow that.
D.Use IAM policies to restrict access to the state files of other workspaces.
AnswerB

Terraform Cloud allows workspace-level permissions, making it easy to restrict access to specific workspaces.

Why this answer

Option B is correct because Terraform Cloud provides native workspace-level permissions, allowing you to grant the new team access only to the staging workspace while preventing them from applying changes to other workspaces. This is the most secure and manageable approach, as it leverages Terraform Cloud's RBAC (Role-Based Access Control) to enforce separation of duties without modifying the backend configuration or relying on error-prone manual processes.

Exam trap

The trap here is that candidates often confuse IAM-based state file access control with workspace-level command restrictions, not realizing that Terraform commands are executed client-side and IAM cannot prevent a user from running `terraform apply` on a different workspace if they have the state file path and credentials.

How to eliminate wrong answers

Option A is wrong because creating a separate S3 bucket for staging would require changing the backend configuration for the staging environment, which breaks the single-backend design and adds operational complexity; it also does not prevent the team from accidentally using the wrong backend configuration. Option C is wrong because relying on `terraform workspace select staging` in the CI/CD pipeline is a procedural control that can be bypassed if the team runs commands locally or if the pipeline is misconfigured; it does not enforce access restrictions at the infrastructure level. Option D is wrong because IAM policies can restrict access to S3 objects (state files) but cannot prevent the team from running `terraform apply` against other workspaces if they have access to the state file; Terraform commands are executed locally or in CI/CD, and IAM does not control which workspace is selected.

Full explanation →
347
Multi-Selecthard

Which THREE are valid methods to manage Terraform state files? (Choose three.)

Select 3 answers
A.terraform state push
B.Local state file
C.Terraform Cloud state storage
D.terraform state mv
E.Remote backends (e.g., S3, AzureRM, GCS)
AnswersB, C, E

Store state locally in terraform.tfstate.

Why this answer

Option B is correct because Terraform can manage state using a local file (terraform.tfstate) stored on the machine where Terraform is run. This is the default behavior and is valid for single-user or test scenarios, though it lacks locking and remote collaboration features.

Exam trap

HashiCorp often tests the distinction between state management methods (storage backends) and state manipulation commands (like push, mv, rm), causing candidates to confuse operational commands with valid storage approaches.

Full explanation →
348
MCQeasy

Based on the error, what is the most likely reason the 'acl' argument is not expected?

A.The module version currently installed does not have an 'acl' variable.
B.The argument name is misspelled; it should be 'acl_control'.
C.The module requires the 'acl' to be set inside a separate block.
D.The 'bucket' argument is missing; 'acl' must follow it.
AnswerA

Module versions may deprecate or remove input variables; the error indicates the variable is not defined in that version.

Why this answer

Option A is correct because the module version does not support the 'acl' argument; it may have been removed. Option B is wrong because typically the registry would show supported arguments. Option C is wrong because other arguments may still be valid.

Option D is wrong because the error is about an unexpected argument, not missing required.

Full explanation →
349
Multi-Selectmedium

Which two are primary benefits of using Infrastructure as Code (IaC) with Terraform?

Select 2 answers
A.Consistent and repeatable deployments
B.Version-controlled infrastructure definitions
C.Real-time monitoring of infrastructure
D.Manual configuration of each resource
E.Automatic scaling based on CPU usage
AnswersA, B

IaC enforces consistency across environments.

Why this answer

Option A is correct because Terraform's declarative configuration files define the desired state of infrastructure, enabling consistent and repeatable deployments across environments. By applying the same configuration, Terraform ensures that the infrastructure is provisioned identically every time, eliminating configuration drift and manual errors.

Exam trap

HashiCorp often tests the distinction between IaC's provisioning benefits and operational features like monitoring or auto-scaling, leading candidates to confuse Terraform's declarative state management with runtime management tools.

Full explanation →
350
MCQhard

Refer to the exhibit. A developer updates the network state and runs terraform apply. The aws_instance.web is not recreated. Which statement explains this behavior?

A.The instance resource does not reference the remote state data source, so changes to the remote state do not trigger recreation.
B.Terraform automatically locks the remote state to prevent changes during apply.
C.The security group resource depends on the remote state, and it was updated, but the instance was not affected.
D.The remote state data source is cached and only refreshes every hour.
AnswerA

Terraform only recreates resources when their own arguments change. The instance does not use any output from the remote state.

Why this answer

The data source data.terraform_remote_state.network is read during planning and is not stored in state. If the remote state changes, Terraform will see the new vpc_id and may update the security group, but the instance resource does not depend on the remote state, so it is not affected.

Full explanation →
351
MCQmedium

A team is using a remote backend in Terraform Cloud. After a failed apply, the state file is locked. The team lead wants to unlock the state immediately. What should be done?

A.Delete the state file from the backend and reinitialize
B.Run terraform force-unlock with the lock ID
C.Manually edit the state file to remove the lock
D.Run terraform unlock
AnswerB

The terraform force-unlock command with the lock ID manually releases the lock.

Why this answer

The `terraform force-unlock` command with the lock ID is the correct way to manually unlock a state file in Terraform Cloud after a failed apply. This command overrides the backend's lock mechanism, which is designed to prevent concurrent modifications and state corruption. Deleting or editing the state file would bypass Terraform's safety guarantees and risk data loss or inconsistency.

Exam trap

The trap here is that candidates may confuse `terraform force-unlock` with a non-existent `terraform unlock` command, or mistakenly think that deleting or editing the state file is a valid workaround, when in fact Terraform's state locking is enforced at the backend API level and requires the proper command with the lock ID.

How to eliminate wrong answers

Option A is wrong because deleting the state file from the backend destroys the entire state history and can cause Terraform to lose track of managed resources, leading to orphaned infrastructure or re-creation attempts. Option C is wrong because manually editing the state file is unsupported and dangerous; it can corrupt the state, break Terraform's internal structure, and is not a valid operation for removing a lock. Option D is wrong because `terraform unlock` is not a valid Terraform command; the correct command is `terraform force-unlock`, which requires the lock ID as an argument.

Full explanation →
352
Multi-Selecthard

A company is using Terraform to manage secrets in AWS Secrets Manager. They want to ensure that sensitive values are not exposed in logs, the console, or plan output. Which two practices should they implement? (Choose two.)

Select 2 answers
A.Use the sensitive flag in variable definitions
B.Use a remote backend with encryption
C.Use a data source to fetch secrets at runtime instead of hardcoding
D.Store variable values in terraform.tfvars file
E.Mark outputs as sensitive = true
AnswersA, E

Marks variables as sensitive, hiding values in plan/apply output.

Why this answer

Option A is correct because marking a variable as sensitive prevents its value from being displayed in CLI output. Option D is correct because marking outputs as sensitive hides the output value after apply. Option B is incorrect because storing in terraform.tfvars does not prevent exposure in plan output.

Option C is incorrect because remote backend encryption protects state at rest, but not plan output. Option E is good practice but does not guarantee the secret is hidden from plan output; it may still appear in the plan unless the data source attribute is marked sensitive.

Full explanation →
353
MCQmedium

A developer accidentally deletes the local terraform.tfstate file. The backend is configured to store state remotely in an S3 bucket. What is the effect on Terraform operations?

A.Terraform will create a new empty state file, losing all existing managed resources.
B.Terraform will fail with an error because the local state is missing.
C.Terraform will automatically recover the state from the remote backend on the next plan or apply.
D.Terraform will prompt the user to confirm whether to use the remote state.
AnswerC

Correct. With a remote backend, Terraform downloads the state from the remote source; the local file is not the authoritative copy.

Why this answer

When using a remote backend, Terraform stores state in the remote location. The local file is not required; Terraform will fetch the state from the remote backend on the next plan or apply.

Full explanation →
354
Multi-Selecteasy

Which two statements about Terraform state files are true? (Choose two.)

Select 2 answers
A.State files are automatically encrypted at rest by all backends.
B.State files should be stored in version control.
C.State files are used to map configuration to real-world resources.
D.State files can be shared across multiple users simultaneously without issues.
E.State files can contain sensitive data such as database passwords.
AnswersC, E

This is the primary function of state.

Why this answer

State files contain resource attributes, including sensitive outputs, so A is true. State provides a mapping, so D is true. B is false because state files should not be in version control.

C is false because concurrent writes would corrupt state. E is false because not all backends provide encryption.

Full explanation →
355
MCQmedium

A startup is adopting Terraform to manage their cloud infrastructure. They want to ensure that changes to infrastructure are reviewed and approved before being applied. Which practice aligns with Infrastructure as Code principles to achieve this?

A.Implement a Git-based workflow with pull requests and automated plan reviews.
B.Use Terraform workspaces to separate environments and manually apply changes.
C.Store Terraform state files in a version control system to track changes.
D.Encourage developers to run terraform apply directly on production.
AnswerA

This enforces code review and automated validation, aligning with IaC best practices.

Why this answer

Option C is correct because it incorporates code review and automated validation, core IaC practices. Option A is wrong because state files contain sensitive data and should not be stored in VCS normally; remote backends are recommended. Option B is partially correct but manual apply without review is not best practice.

Option D is dangerous as it bypasses review and can lead to unintended changes.

Full explanation →
356
MCQhard

A module requires an input variable named 'vpc_id'. How should the calling configuration pass the VPC ID from another module's output?

A.vpc_id = module.vpc.outputs.vpc_id
B.vpc_id = var.vpc_id
C.vpc_id = vpc.module.vpc_id
D.vpc_id = module.vpc.vpc_id
AnswerD

Correctly references the module output.

Why this answer

Correct B: module outputs are referenced as module.module_name.output_name. A adds unnecessary '.outputs', C is incorrect syntax, D uses a variable not defined.

Full explanation →
357
MCQeasy

Refer to the exhibit. A user has this backend configuration. The user then runs `terraform init` and receives an error: 'NoSuchBucket: The specified bucket does not exist'. What is the most likely cause?

A.The bucket does not exist and needs to be created.
B.The AWS region is wrong.
C.The DynamoDB table is missing.
D.The credentials lack S3 permissions.
AnswerA

NoSuchBucket error means the bucket doesn't exist in the specified region.

Why this answer

The error 'NoSuchBucket' indicates the bucket does not exist in the specified region. Option D is correct. Option A would give a different error.

Option B would give access denied. Option C is irrelevant.

Full explanation →
358
MCQhard

What is the most likely cause of this error?

A.The `output` block is referencing a non-existent attribute.
B.The `aws_eip` resource must use `self.instance` instead of `aws_instance.web.id`.
C.The `depends_on` meta-argument is missing from the aws_eip resource.
D.The `aws_instance.web` resource has a syntax error in the ami attribute.
AnswerC

Implicit dependency should work, but the error suggests Terraform is not resolving the dependency correctly. Adding explicit depends_on resolves it.

Why this answer

Option C is correct because the `aws_eip` resource depends on the `aws_instance.web` resource to ensure the instance is created before the Elastic IP is allocated. Without an explicit `depends_on` meta-argument, Terraform may attempt to create the EIP before the instance, causing an error if the instance ID is not yet available. The error message typically indicates that the `aws_eip` resource cannot resolve the `instance` argument because the instance resource has not been created yet.

Exam trap

HashiCorp often tests the misconception that `depends_on` is only needed when there is no implicit reference, but the trap here is that candidates may overlook that Terraform's automatic dependency detection can fail in certain edge cases, such as when the reference is inside a `count` or `for_each` expression, or when the resource is in a different module.

How to eliminate wrong answers

Option A is wrong because the `output` block referencing a non-existent attribute would produce a different error, such as 'Unsupported attribute', not a dependency-related error. Option B is wrong because `self.instance` is not a valid syntax in Terraform; the correct way to reference the instance ID is `aws_instance.web.id`, and using `self.instance` would cause a syntax error, not a dependency error. Option D is wrong because a syntax error in the `ami` attribute would cause a validation error during plan or apply, not a runtime error about missing dependencies.

Full explanation →
359
MCQmedium

After running `terraform plan`, the user receives an error: `Error: Missing required variable`. The variable 'vpc_cidr' is provided. What is the most likely cause?

A.The module requires a variable 'environment' that is not passed.
B.The module block syntax is incorrect.
C.The variable 'vpc_cidr' is misspelled.
D.The variable 'vpc_cidr' conflicts with a provider variable.
AnswerA

The module's variables.tf declares 'environment' without a default, so it must be set.

Why this answer

The module defines a second required variable 'environment' that has no default value and is not set in the module block, causing the error. Option B is wrong because 'vpc_cidr' is provided. Option C is wrong because syntax is correct.

Option D is wrong because there is no conflict; the variable is simply unset.

Full explanation →
360
MCQeasy

A junior administrator wants to practice Terraform by deploying a single web server in AWS. They write a configuration file and run terraform init and terraform apply. The deployment succeeds but they notice the web server is not accessible from the internet. What is the most likely reason?

A.The instance type chosen does not support public IP addresses.
B.The terraform init command failed and the apply did not actually create resources.
C.The subnet is configured as private and does not have a route to the internet.
D.The security group does not allow inbound HTTP/HTTPS traffic from 0.0.0.0/0.
AnswerD

Security group rules control inbound traffic; without allowing HTTP/HTTPS, the server is not accessible.

Why this answer

Option D is correct because even if the web server is deployed in a public subnet with a public IP address, the security group acts as a virtual firewall at the instance level. By default, AWS security groups block all inbound traffic. Without an explicit rule allowing inbound HTTP (port 80) or HTTPS (port 443) traffic from 0.0.0.0/0, the web server will not respond to internet requests, making it inaccessible from the internet.

Exam trap

HashiCorp often tests the misconception that a public subnet or public IP alone guarantees internet accessibility, when in fact the security group's inbound rules are the primary gatekeeper for traffic reaching the instance.

How to eliminate wrong answers

Option A is wrong because all AWS instance types support the assignment of public IP addresses; the ability to assign a public IP is controlled by the subnet's auto-assign public IP setting or the instance's network interface configuration, not the instance type. Option B is wrong because if terraform init had failed, terraform apply would not proceed to create resources; the question states the deployment succeeded, meaning both commands completed without error. Option C is wrong because a private subnet would prevent internet access entirely, but the question does not specify the subnet type; the most common and direct reason for a web server being inaccessible after a successful deployment is the lack of an inbound security group rule for HTTP/HTTPS traffic.

Full explanation →
361
MCQmedium

A team is adopting Terraform to manage infrastructure. One requirement is that all configuration changes must be reviewed and approved before being applied. The team wants to ensure that the Terraform state file reflects the actual deployed infrastructure at all times. Which practice should they implement to meet these requirements?

A.Store state locally and use a manual approval process outside of Terraform.
B.Store state remotely and use a version control system with pull requests to review changes before applying.
C.Store state locally and use a shared network drive for team access.
D.Have each team member run terraform apply from their local machine after informal discussion.
AnswerB

Remote state enables team collaboration and VCS with PRs enforces review.

Why this answer

Storing state remotely (e.g., in S3, Azure Storage, or Terraform Cloud) enables state locking and versioning, which is essential for team collaboration. Using a version control system with pull requests ensures that all configuration changes are reviewed and approved before being applied, meeting the requirement for change control. This combination also ensures the state file accurately reflects deployed infrastructure by preventing concurrent modifications and providing an audit trail.

Exam trap

HashiCorp often tests the misconception that local state with manual processes is sufficient for team collaboration, but the trap here is that without remote state and version-controlled review, you cannot guarantee state consistency or enforce an approval gate, leading to drift and conflicts.

How to eliminate wrong answers

Option A is wrong because storing state locally prevents team collaboration and state locking, and a manual approval process outside of Terraform does not integrate with Terraform's workflow, risking state drift and concurrent apply conflicts. Option C is wrong because a shared network drive lacks state locking and versioning, leading to corruption or overwrites when multiple team members run terraform apply simultaneously. Option D is wrong because having each team member run terraform apply from their local machine after informal discussion bypasses any formal review or approval process, and local state files will diverge, causing inconsistency and potential infrastructure drift.

Full explanation →
362
MCQmedium

A user wants to inspect the current attributes of a specific resource in the Terraform state. Which command should they use?

A.terraform state list <resource>
B.terraform output
C.terraform state show <resource>
D.terraform plan
E.terraform show
AnswerC

This command outputs the full state data for the given resource address.

Why this answer

`terraform state show <resource>` displays the attributes and metadata of a specific resource as stored in the state.

Full explanation →
363
Multi-Selectmedium

Which of the following are key benefits of using Infrastructure as Code (IaC) compared to manual infrastructure management? (Choose four.)

Select 4 answers
.Enables repeatable and consistent infrastructure deployments
.Reduces the risk of human error in configuration
.Allows infrastructure to be version-controlled and audited
.Automatically fixes all security vulnerabilities in the infrastructure
.Provides self-healing infrastructure without any additional tooling
.Facilitates collaboration through code reviews and sharing of configurations

Why this answer

Infrastructure as Code (IaC) enables repeatable and consistent deployments by defining infrastructure in declarative or procedural configuration files, eliminating the variability of manual steps. It reduces human error by automating provisioning tasks that are prone to typos or omissions when performed manually. Version control systems like Git allow infrastructure configurations to be tracked, audited, and rolled back, while code reviews and shared modules promote team collaboration and standardization.

Exam trap

HashiCorp often tests the misconception that IaC inherently provides self-healing or automatic security remediation, when in fact these capabilities require additional tooling and are not core features of IaC itself.

Full explanation →
364
Matchingmedium

Match each Terraform state command to its action.

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

Concepts
Matches

List resources in the state

Show details of a single resource in state

Move an item in the state

Remove an item from the state

Download current state from backend

Why these pairings

State management commands allow direct state manipulation.

Full explanation →
365
MCQhard

A developer runs `terraform apply` and gets the error: 'Error: No configuration files'. What is the most likely cause?

A.The working directory does not contain any `.tf` files
B.The state file is missing
C.The user does not have permissions to read the directory
D.The provider plugin is not installed
E.The backend configuration is incomplete
AnswerA

Correct: Terraform requires `.tf` files to run.

Why this answer

Option A is correct because the error indicates the directory contains no `.tf` files. Option B is wrong because permission errors would produce a different message. Option C is wrong because missing state files do not cause this error.

Option D is wrong because missing provider plugins cause a provider installation error. Option E is wrong because backend misconfiguration causes backend initialization errors.

Full explanation →
366
MCQeasy

What file extension is commonly used for Terraform configuration files?

A..json
B..hcl
C..tfstate
D..yaml
E..tf
AnswerE

Correct: `.tf` is the standard extension.

Why this answer

Option A is correct because `.tf` is the standard extension for Terraform configuration files. Option B is wrong because `.tfstate` is for state files. Option C is wrong because `.hcl` is the language syntax but not file extension.

Option D is wrong because `.json` is also supported but not the standard. Option E is wrong because `.yaml` is not used.

Full explanation →
367
MCQmedium

An engineer is refactoring a monolithic Terraform configuration into reusable modules. One module outputs a list of subnet IDs. Another module needs to use these subnet IDs to create resources. What is the best way to pass this data between modules?

A.Use a Terraform data source in the second module to query the subnets directly.
B.Define the subnet IDs as a variable in the first module and pass them to the second module via a remote state data source.
C.Store the subnet IDs in a local file and use the 'file' function to read them in the second module.
D.Output the subnet IDs from the first module and reference that output as an input variable in the second module's block.
AnswerD

This is the correct pattern: module outputs are consumed as module input variables.

Why this answer

Option D is correct because Terraform modules communicate through explicit input and output variables. By outputting the subnet IDs from the first module and then referencing that output as an input variable in the second module's block, you create a clear, versionable, and dependency-aware data flow. This approach avoids hidden dependencies and ensures Terraform can properly graph the resource dependencies for parallel execution.

Exam trap

HashiCorp often tests the misconception that remote state data sources are the only way to pass data between modules, when in fact direct output-to-variable passing is the simplest and most maintainable approach within a single Terraform configuration.

How to eliminate wrong answers

Option A is wrong because using a data source in the second module to query subnets directly reintroduces tight coupling to the underlying infrastructure and bypasses the modular abstraction, defeating the purpose of refactoring into reusable modules. Option B is wrong because defining subnet IDs as a variable in the first module is nonsensical—variables are inputs, not outputs; the correct mechanism is to output the IDs from the first module and then use a remote state data source only if the modules are in separate configurations, but here they are in the same configuration, so direct output-to-variable passing is simpler and more idiomatic. Option C is wrong because storing data in a local file introduces an external, non-versioned artifact that can become stale, breaks Terraform's dependency tracking, and is an anti-pattern for passing runtime data between modules.

Full explanation →
368
MCQhard

Refer to the exhibit. A developer runs the commands shown. The Terraform configuration defines a `random_pet` resource. The developer expects the plan to show a new resource to be created, but it says "No changes." What is the most likely reason?

A.The random_pet resource was already created in a previous apply and is still in the state
B.The `-auto-approve` flag prevents showing changes in the plan
C.The `random_pet` resource is not supported by the Terraform version
D.The backend is local, so changes are not persisted across runs
AnswerA

Correct! If the resource exists in state and configuration matches, no changes are needed.

Why this answer

Option A is correct because the `random_pet` resource was already created and recorded in the Terraform state file during a previous `terraform apply`. When the developer runs `terraform plan` again without any changes to the configuration, Terraform compares the current state to the configuration and finds no differences, resulting in 'No changes.' The resource already exists in the state, so no new resource is planned.

Exam trap

The trap here is that candidates may assume `random_pet` generates a new value on every plan, but Terraform treats it as a managed resource that only changes when the configuration or state is altered.

How to eliminate wrong answers

Option B is wrong because the `-auto-approve` flag only skips the interactive approval prompt during `terraform apply`; it does not affect whether changes are shown in `terraform plan`. Option C is wrong because `random_pet` is a built-in resource from the `random` provider, which is supported in all modern Terraform versions (0.12+). Option D is wrong because a local backend does persist state across runs (in the `terraform.tfstate` file); changes are not lost between runs, so the 'No changes' result is not due to the backend type.

Full explanation →
369
MCQeasy

A developer runs terraform plan and sees that a resource will be destroyed. They want to confirm the exact cause of the destruction before applying. What should they do?

A.Run terraform show after plan.
B.Review the state file directly.
C.Run terraform validate.
D.Run terraform graph.
AnswerA

terraform show outputs the plan in human-readable form, including the reason for each change.

Why this answer

Running `terraform show` after `terraform plan` displays the plan output in a human-readable format, including the full set of changes (create, update, destroy) and the attributes that triggered them. This allows the developer to inspect the exact reason a resource is marked for destruction, such as a changed required argument or a removed configuration block. It is the standard way to review plan details without applying.

Exam trap

HashiCorp often tests the distinction between commands that inspect the plan (`terraform show`) versus commands that validate syntax (`terraform validate`) or visualize dependencies (`terraform graph`), leading candidates to confuse planning-phase diagnostics with configuration checks.

How to eliminate wrong answers

Option B is wrong because directly reviewing the state file (terraform.tfstate) shows the current state, not the planned changes; it does not reveal why Terraform decided to destroy a resource, only that it exists. Option C is wrong because `terraform validate` checks configuration syntax and internal consistency, not the planned execution or destruction reasons. Option D is wrong because `terraform graph` outputs a dependency graph in DOT format, which visualizes resource relationships but does not explain the specific cause of a planned destruction.

Full explanation →
370
MCQmedium

Refer to the exhibit. A Terraform Cloud plan includes an EC2 instance of type 't2.medium'. The team uses Sentinel policies. Which action should they take to proceed?

A.Modify the Sentinel policy to allow t2.medium.
B.Disable the policy check for this run.
C.Change the instance type in the configuration to t2.micro or t2.small.
D.Override the policy in the run using Terraform Cloud UI.
AnswerC

Comply with the policy.

Why this answer

Option B is correct because the policy must be satisfied by using an allowed instance type. Options A, C, and D are not appropriate: A would change policy which may be against organization rules; C implies override but policy is enforced; D disables checks entirely.

Full explanation →
371
Multi-Selecthard

Which three of the following are true regarding Terraform state?

Select 3 answers
A.State can be stored in a local file or remotely.
B.State can be manually edited with a text editor without risk.
C.State is required for Terraform to function.
D.State must be stored in a file named terraform.tfstate.
E.State contains resource metadata and dependencies.
AnswersA, C, E

Correct. Backends allow local or remote storage (e.g., S3, Azure Storage).

Why this answer

State contains resource metadata and dependencies, is required for Terraform to map configuration to real infrastructure, and can be stored locally or remotely. It is not required to be named terraform.tfstate, and manual editing is risky.

Full explanation →
372
Multi-Selectmedium

Which TWO of the following are valid variable types in Terraform? (Choose two.)

Select 2 answers
A.tuple
B.string
C.integer
D.map
E.boolean
AnswersB, D

Correct: string is a primitive type.

Why this answer

Option A (string) and Option D (map) are valid Terraform variable types. Option B (integer) is not a separate type; it's a number. Option C (list) is valid but we need only two correct; list is also valid, but since the question says 'Which TWO', and we have three valid? Actually strings, lists, maps are all valid.

But to have exactly two correct, we list only string and map as correct? That would be misleading. Better to choose types that are clearly distinct. In Terraform, types include: string, number, bool, list, map, set, object, tuple, any.

So both list and map are valid. But we need exactly two correct; we can make string and map correct, and list incorrect? That would be wrong. Alternatively, we can say 'string' and 'number' are valid? But number is valid.

Let's design: correct: string (A), map (D); incorrect: integer (B) - number is valid but integer is not a type; set (C) is valid but we choose it as incorrect? Set is valid too. This is tricky. Better to choose types that are not directly in Terraform, e.g., 'array' and 'dictionary'.

Or we use: A. string, B. integer, C. boolean, D. map, E. array. Then correct: string and map. boolean is valid but we only have two correct? Actually boolean is also valid. To get exactly two, we need to include only two valid types.

Let's say: A. string (valid), B. number (valid), but then we have two valid? we need two correct. So we could have A and B as correct, and C, D, E as invalid? But many types are valid. Let's use: A. string, B. integer, C. float, D. list, E. map.

Correct: A (string) and D (list). integer and float are not separate types; they are number. map is valid but we need exactly two, so choose only string and list. Alternatively, we can use 'tuple' and 'object' as options. I'll go with: A. string, B. integer, C. boolean, D. map, E. tuple.

Correct: A and D. integer is not a Terraform type (number is), boolean is valid (bool), tuple is valid. So only two correct: string and map. That works.

So set correct keys: A and D.

Full explanation →
373
MCQmedium

A developer creates a module in a subdirectory called 'networking' relative to the root module. How should the module source be specified in the root module?

A../networking
B../modules/networking
C.../networking
D.networking
AnswerA

The path starts with './' indicating a relative path from the current directory.

Why this answer

Option A is correct because local module paths must start with './' or '../'. './networking' correctly references the 'networking' subdirectory relative to the root. Option B (../networking) would go up one level. Option C assumes a 'modules' subdirectory.

Option D is not a valid relative path.

Full explanation →
374
MCQmedium

A team wants to use Terraform to manage their AWS infrastructure. They have existing resources created manually. What is the recommended approach to bring these resources under Terraform management?

A.Delete the existing resources and recreate them using Terraform configuration.
B.Use terraform plan to detect existing resources and automatically adopt them.
C.Write Terraform configuration that matches existing resources and run terraform apply.
D.Use terraform import to bring each resource into state.
AnswerD

Import is the correct workflow to adopt existing infrastructure into Terraform.

Why this answer

Option D is correct because the `terraform import` command is designed to bring existing resources into Terraform state so they can be managed. Option A is disruptive and unnecessary. Option B may cause errors if configurations don't match exactly.

Option C is not a feature that automatically discovers resources.

Full explanation →
375
Multi-Selectmedium

Which three of the following are valid ways to pass variable values to a Terraform configuration?

Select 3 answers
A.Using the -assign flag on the command line.
B.Using the -var flag on the command line.
C.Using a YAML file.
D.Using a .tfvars file.
E.Using environment variables with the TF_VAR_ prefix.
AnswersB, D, E

Correct. The -var flag directly sets a variable value.

Why this answer

Valid methods include using a .tfvars file, environment variables with TF_VAR_ prefix, and the -var flag on the command line. The -var-file flag is also valid, but only three are listed as correct here; the -assign flag and YAML file are not supported.

Full explanation →
Page 4

Page 5 of 7

Page 6

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 →