Courseiva
Knowledge + Practice
CertificationsVendorsCareer RoadmapsLabs & ToolsStudy GuidesGlossaryPractice Questions
C
Courseiva

Free IT certification practice questions with explained answers for CCNA, CompTIA, AWS, Azure, Google Cloud, and more.

Certification Practice Questions

CCNA practice questionsSecurity+ SY0-701 practice questionsAWS SAA-C03 practice questionsAZ-104 practice questionsAZ-900 practice questionsCLF-C02 practice questionsA+ Core 1 practice questionsGoogle Cloud ACE practice questionsCySA+ CS0-003 practice questionsNetwork+ N10-009 practice questions
View all certifications →

Product

CertificationsCertification PathsExam TopicsPractice TestsExam Dumps vs Practice TestsStudy HubComparisons

Company

AboutContactEditorial PolicyQuestion Writing PolicyTrust Center

Legal

Privacy PolicyTerms of Service

Courseiva is a free IT certification practice platform offering original exam-style practice questions, detailed explanations, topic-based practice, mock exams, readiness tracking, and study analytics for Cisco, CompTIA, Microsoft, AWS, and other technology certifications.

© 2026 Courseiva. Courseiva is operated by JTNetSolutions Ltd. All rights reserved.

Courseiva is an independent certification practice platform and is not affiliated with, endorsed by, or sponsored by Cisco, Microsoft, AWS, CompTIA, Google, ISC2, ISACA, or any other certification vendor. Vendor names and certification marks are used only to identify the exams learners are preparing for.

HomeCertificationsTF-003Exam Questions

HashiCorp · Free Practice Questions · Last reviewed May 2026

TF-003 Exam Questions and Answers

48real exam-style questions organised by domain, each with the correct answer highlighted and a plain-English explanation of why it's right — and why the others are wrong.

57 exam questions
60 min time limit
Pass: 700/1000 / 1000
8 exam domains
OverviewDomain BlueprintStudy GuideAll QuestionsSample by Domain
1. Understand IaC concepts2. Understand Terraform basics3. Understand Terraform's purpose4. Use Terraform outside the core workflow5. Interact with Terraform modules6. Use the core Terraform workflow7. Implement and maintain state8. Read, generate and modify configuration
1

Domain 1: Understand IaC concepts

All Understand IaC concepts questions
Q1
mediumFull explanation →

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.

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

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.

Why: 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.
Q2
hardFull explanation →

An organization manages multiple environments (dev, staging, prod) using Terraform. They want to minimize code duplication while allowing environment-specific variable values. Which approach best achieves this goal?

A

Use a separate Git branch for each environment, each with its own Terraform configuration.

B

Write a single Terraform configuration that uses count and conditional expressions to create resources based on environment variable.

C

Use Terraform workspaces with a single configuration and define all variable values in one .tfvars file.

D

Organize the repository with a shared modules directory and separate subdirectories for each environment that call the same modules with environment-specific .tfvars files.

This structure maximizes reuse and keeps environment-specific variables separate.

Why: Option D is correct because it leverages Terraform's module system to define reusable infrastructure components in a shared directory, while each environment (dev, staging, prod) has its own subdirectory with a root configuration that calls those modules and passes environment-specific `.tfvars` files. This minimizes code duplication by keeping the module logic in one place, and allows per-environment variable values without mixing concerns. It follows the recommended pattern for multi-environment management in Terraform, avoiding the pitfalls of branches, workspaces, or conditional logic that can lead to complexity or state corruption.
Q3
easyFull explanation →

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.

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

Why: 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.
Q4
hardFull explanation →

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

A

Remove the DynamoDB table and use local state files to avoid locking issues.

B

Configure all team members to use the same workspace so that only one person can apply at a time.

C

Keep the current setup because the error is harmless and users can retry.

D

Use separate state files per workspace and ensure each workspace has its own lock entry in DynamoDB; the current setup already supports this.

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

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

Which THREE of the following are benefits of using Infrastructure as Code (IaC) compared to manual infrastructure management?

A

Automated testing and deployment pipelines can be integrated.

IaC can be tested and deployed in CI/CD.

B

Infrastructure can be replicated consistently across environments.

Same configuration can be applied to multiple environments with different variables.

C

The same code can be used for any cloud provider without modification.

D

Infrastructure can be version controlled and changes tracked.

Configuration files are text, easily versioned.

E

No learning curve is required; existing knowledge of manual processes applies directly.

Why: Option A is correct because IaC enables infrastructure to be defined in code, which can be integrated into automated CI/CD pipelines. Tools like Terraform or AWS CloudFormation allow infrastructure validation, testing, and deployment to be automated, reducing human error and speeding up delivery.
Q6
mediumFull explanation →

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

A

Install Terraform on the existing instance, run terraform init and apply directly to manage it, and store state locally. Have team members share the state file via a shared folder.

B

Write Terraform configuration from scratch to match the existing instance, but do not import; instead, destroy the old instance and recreate it with Terraform.

C

Create separate Git branches for each environment (dev, staging, prod) and have each team member work independently on their branch, merging occasionally.

D

Create a Git repository with a main branch. Write a minimal Terraform configuration that describes the existing EC2 instance. Use terraform import to bring the instance under Terraform management. Store the state file remotely in S3 with DynamoDB locking. Set up a CI pipeline that runs terraform plan on pull requests and requires approval before merging.

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

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

Want more Understand IaC concepts practice?

Practice this domain
2

Domain 2: Understand Terraform basics

All Understand Terraform basics questions
Q1
mediumFull explanation →

A DevOps engineer is writing a Terraform configuration to provision an AWS EC2 instance. They want to ensure that the instance is replaced if the AMI ID changes, but not if the instance type changes. Which lifecycle meta-argument should be used?

A

Set `prevent_destroy = true`

B

Set `ignore_changes = all`

C

Set `create_before_destroy = true` and add `instance_type` to `ignore_changes`

Correct: creates new before destroying old, ignores instance type changes.

D

Set `create_before_destroy = true` only

Why: Option C is correct because `create_before_destroy = true` ensures the new instance is created before the old one is destroyed, which is a best practice for zero-downtime deployments when the AMI changes. Adding `instance_type` to `ignore_changes` tells Terraform to ignore changes to the instance type attribute during plan/apply, so the instance is not replaced when only the instance type changes. This combination precisely meets the requirement: replacement on AMI change, no replacement on instance type change.
Q2
easyFull explanation →

A team is using Terraform to manage infrastructure across multiple environments (dev, staging, prod). They want to reuse the same root module configuration but with different variable values. Which approach is the most efficient?

A

Use environment variables to switch between configurations

B

Use a single state file that includes all environments

C

Copy the entire configuration into separate directories for each environment

D

Use Terraform workspaces

Allows multiple environments with the same configuration and separate state.

Why: Terraform workspaces allow you to manage multiple distinct sets of infrastructure resources (e.g., dev, staging, prod) from the same root module configuration by maintaining separate state files for each workspace. This avoids duplicating code or manually managing state file switching, making it the most efficient approach for reusing configuration with different variable values across environments.
Q3
hardFull explanation →

A Terraform configuration includes a module from the Terraform Registry. After running `terraform init`, the module is downloaded. However, a subsequent `terraform plan` fails with an error that a required provider is not installed, even though it is declared in the module. What is the most likely cause?

A

The module uses a different Terraform version

B

The provider version constraint is incompatible

C

The `required_providers` block is not declared in the root module

Terraform may not install providers only declared in modules; root should also declare them.

D

The module source URL is incorrect

Why: Option C is correct because in Terraform, the `required_providers` block must be declared in the root module to ensure all providers are installed during `terraform init`. When a module from the Registry declares a provider but the root module does not, `terraform init` may not automatically install that provider, leading to a 'required provider not installed' error during `terraform plan`. The root module acts as the top-level configuration that aggregates all provider requirements.
Q4
mediumFull explanation →

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

A

The Terraform version in the VCS pipeline is different

B

The local `terraform plan` left the state locked in Terraform Cloud

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

C

The VCS branch is not configured as the workspace's working branch

D

The VCS pipeline does not have access to the Terraform Cloud workspace

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

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

A

`module.vpc.output`

B

`data.aws_ami.ubuntu.id`

C

`var.instance_type`

D

`module.vpc.vpc_id`

Correct: references the vpc_id output from module vpc.

E

`aws_instance.web.id`

Correct: references the id attribute of an aws_instance resource named web.

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

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

A

Terraform will recreate the EC2 instance and reassociate the Elastic IP

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

B

The Elastic IP will be disassociated and the instance will be recreated

C

Terraform will only recreate the EC2 instance without reassociating the Elastic IP

D

The apply will fail because the Elastic IP is still attached to the terminated instance

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

Want more Understand Terraform basics practice?

Practice this domain
3

Domain 3: Understand Terraform's purpose

All Understand Terraform's purpose questions
Q1
mediumFull explanation →

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

A

Terraform is a configuration management tool for installing software on existing servers.

B

Terraform is a cloud-specific orchestration tool that only works with AWS.

C

Terraform is a monitoring and logging tool for cloud resources.

D

Terraform is an infrastructure-as-code tool for provisioning and managing any infrastructure across multiple providers.

Correctly defines Terraform's purpose.

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

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

A

The `terraform apply` command

B

The `terraform validate` command

C

The `terraform plan` command

Plan shows a preview of changes.

D

The `terraform state` command

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

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

Workspaces enable multiple environments with one configuration.

Why: 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.
Q4
mediumFull explanation →

An organization uses Terraform Cloud for remote state management. A user runs `terraform apply` locally but receives an error that the state is locked. What is the most likely cause?

A

The Terraform configuration has a syntax error.

B

The user does not have access to the remote state backend.

C

Another user or process is currently running a Terraform operation that modifies the same state.

State locking prevents concurrent writes.

D

The remote backend is temporarily unavailable.

Why: Option C is correct because Terraform Cloud uses a state locking mechanism to prevent concurrent modifications that could corrupt the state file. When a user runs `terraform apply` locally, the command first attempts to acquire a lock on the remote state. If another user or process (e.g., a Terraform Cloud run, a CI/CD pipeline, or another local apply) is already holding that lock, the new operation will fail with a 'state is locked' error. This is a fundamental safety feature to ensure state consistency.
Q5
mediumFull explanation →

Which TWO of the following are benefits of using Terraform's infrastructure as code approach?

A

Provisioning can be automated and repeated consistently across environments.

Automation and consistency are key benefits.

B

Infrastructure can be version-controlled and reviewed like application code.

IaC allows code reviews and version history.

C

Terraform automatically scales resources based on load.

D

Manual configuration of servers is eliminated entirely.

E

Terraform provides real-time monitoring of infrastructure health.

Why: Option A is correct because Terraform's infrastructure as code approach allows you to define your entire infrastructure in declarative configuration files (HCL). These configurations can be executed repeatedly using `terraform apply`, ensuring that the same provisioning steps are performed consistently across development, staging, and production environments without manual intervention or drift.
Q6
hardFull explanation →

Which THREE of the following are valid Terraform providers?

A

hashicorp/azurerm

Official Azure provider.

B

kreuzwerker/docker

C

hashicorp/kubernetes

Official Kubernetes provider.

D

hashicorp/aws

Official AWS provider.

E

hashicorp/cloudwatch

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

Want more Understand Terraform's purpose practice?

Practice this domain
4

Domain 4: Use Terraform outside the core workflow

All Use Terraform outside the core workflow questions
Q1
easyFull explanation →

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

Downloads required provider plugins and reinitializes the backend.

Why: 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.
Q2
mediumFull explanation →

A team uses Terraform Cloud for remote state management. They want to ensure that state file changes are only made through the Terraform Cloud API and not through direct access to the storage backend. Which feature should they enable?

A

Sentinel policy enforcement

Enforces policies that prevent direct state modifications outside the API.

B

Remote state locking

C

VCS integration

D

Team tokens

Why: Option A is correct because Sentinel policy enforcement allows the team to define rules that restrict direct modifications to the state file in the storage backend, ensuring that all state changes must go through the Terraform Cloud API. This prevents bypassing Terraform Cloud's access controls and audit logging, which is essential for maintaining integrity and compliance in remote state management.
Q3
hardFull explanation →

A company uses Terraform with multiple cloud providers and wants to integrate with their existing CI/CD pipeline. They need to enforce that all infrastructure changes go through code review and automated testing before being applied to production. Which approach best meets these requirements?

A

Store state in a remote backend and use terraform apply in the pipeline

B

Configure Terraform Cloud with run triggers and policy checks

Enforces code review and automated testing via workflows.

C

Use the Terraform CLI in the CI/CD pipeline with remote state

D

Run terraform apply locally after manual approval

Why: Option B is correct because Terraform Cloud's run triggers and policy checks (e.g., Sentinel) enforce that all infrastructure changes must pass code review and automated testing before being applied. This integrates directly with the CI/CD pipeline by requiring a pull request to trigger a plan, which is then reviewed and approved via Terraform Cloud's governance controls, ensuring no change reaches production without validation.
Q4
easyFull explanation →

An operator runs `terraform apply` and receives an error that the state file is locked. What is the most likely cause?

A

The state file is outdated and needs refresh

B

The configuration has a syntax error

C

Another user is running a Terraform operation

State locking prevents concurrent operations.

D

The user lacks write permissions to the state file

Why: Option C is correct because Terraform uses a state locking mechanism (typically via a backend like S3 with DynamoDB, or Consul) to prevent concurrent operations from corrupting the state file. When another user or process is running a Terraform operation (e.g., `apply`, `plan`, `destroy`), the lock is held, and any subsequent `terraform apply` will fail with a 'state file is locked' error. This is a fundamental safety feature to ensure state consistency.
Q5
mediumFull explanation →

An organization wants to use Terraform to manage infrastructure in multiple environments (dev, staging, prod) with the same configuration but different variable values. Which approach should they use?

A

Create separate directories with duplicated configurations

B

Use Terraform workspaces and separate variable files

Reuses configuration with isolated state and variables.

C

Use a single state file with environment variables

D

Use different versions of Terraform for each environment

Why: Terraform workspaces allow you to manage multiple distinct sets of infrastructure resources within the same configuration by maintaining separate state files. By combining workspaces with separate variable definition files (e.g., `dev.tfvars`, `prod.tfvars`), you can reuse the same configuration code while applying environment-specific variable values, avoiding duplication and ensuring consistency across environments.
Q6
hardFull explanation →

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

A

Amend the previous commit and force push

B

Create a new commit with the fix

C

Use the 'Queue Plan' button in the Terraform Cloud UI

Re-runs plan with the same commit.

D

Run terraform plan locally and apply

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

Want more Use Terraform outside the core workflow practice?

Practice this domain
5

Domain 5: Interact with Terraform modules

All Interact with Terraform modules questions
Q1
easyFull explanation →

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

A

Use 'required_providers' block in the root module to lock the module version.

B

Add a 'version' argument inside the module block.

C

Set 'version' in the module's source attribute, e.g., source = "terraform-aws-modules/vpc/aws" with version = "3.2.0".

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

D

Store the module locally in a vendor directory and reference it by path.

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

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.

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

Why: 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.
Q3
hardFull explanation →

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.

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

D

The IAM role used by Terraform does not have permission to read the bucket ARN.

Why: 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.
Q4
mediumFull explanation →

Which TWO statements about Terraform module sources are correct? (Select TWO.)

A

A module source can be a local file system path.

Local paths are valid module sources.

B

Modules can only be sourced from the public Terraform Registry.

C

Running 'terraform plan' automatically downloads any missing modules.

D

A module source can be a Git repository URL using the SSH protocol.

Git SSH URLs are supported.

E

The module source is defined in a separate 'source' block within the module.

Why: Option A is correct because Terraform allows module sources to be local file system paths, enabling you to reference modules stored on your local machine. This is useful for developing and testing modules before publishing them, and the path can be relative or absolute, such as `./modules/my-module` or `/home/user/modules/my-module`.
Q5
hardFull explanation →

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

A

Design modules to have a single clear purpose.

Single-responsibility modules are easier to reuse and test.

B

Use version constraints when referencing modules from a registry.

Version pinning prevents breaking changes.

C

Output important resource attributes that consumers may need.

Outputs allow consumers to access created resources.

D

Hardcode provider-specific details like region inside the module to simplify usage.

E

Create a new module for each individual resource type.

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

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

A

The 'version' argument is not supported for this module because the source is not a registry module.

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

B

The 'version' argument must be specified as a constraint like '>= 3.19.0' instead of an exact version.

C

The module source is from a Git repository, which does not support the 'version' argument.

If the source is a Git URL, 'version' is not supported; but the exhibit shows a registry source. However, if the source was actually a Git URL, version would be invalid. The error suggests the source is not a registry module.

D

The 'version' argument should be placed inside a 'required_providers' block.

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

Want more Interact with Terraform modules practice?

Practice this domain
6

Domain 6: Use the core Terraform workflow

All Use the core Terraform workflow questions
Q1
easyFull explanation →

A team uses Terraform to manage infrastructure. After running 'terraform apply', a developer notices that a new security group rule was added, but then immediately removed. What is the most likely cause?

A

The security group rule was added manually and Terraform removed it to match the configuration.

Terraform detects drift and reverts changes not in the configuration.

B

The state file was corrupted and Terraform performed a refresh.

C

The configuration was changed to remove the rule after the apply.

D

The developer accidentally ran 'terraform destroy' instead.

Why: Option A is correct because Terraform operates on a desired-state model: it compares the configuration in `.tf` files against the real-world infrastructure and the state file. If a security group rule was added manually outside of Terraform, Terraform detects it as a drift during the next `apply` and removes it to reconcile the actual state with the declared configuration. This is the core behavior of Terraform's lifecycle management.
Q2
mediumFull explanation →

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

A

Terraform state locking prevented the apply from executing correctly.

B

The state file was corrupted during the apply.

C

The configuration was modified after the plan was generated.

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

D

The 'terraform apply' command includes an implicit refresh that changes the plan.

Why: The plan is based on the state and configuration at the time of planning. If someone else applies changes concurrently or if the configuration changes between plan and apply, the plan becomes stale. Option A is wrong because refreshing state doesn't change the plan. Option C is wrong because 'terraform apply' does not modify configuration. Option D is wrong because locking prevents concurrent applies but doesn't cause discrepancy if the plan is still valid.
Q3
hardFull explanation →

A DevOps engineer is troubleshooting a failed 'terraform apply'. The error message says: 'Error: Error applying IAM policy: The policy failed validation'. The IAM policy is defined using HCL in a JSON-encoded string. What is the most efficient way to debug this issue?

A

Run 'terraform plan' to see the detailed error.

B

Use 'terraform console' to test the policy string.

C

Use a JSON validator tool to check the policy string in the configuration.

Validating the JSON string locally identifies syntax issues before running apply.

D

Upgrade to the latest Terraform version.

Why: Option C is correct because the error 'The policy failed validation' indicates that the JSON-encoded IAM policy string in the Terraform configuration is malformed or violates AWS IAM policy syntax. Using a JSON validator tool (e.g., `jq`, online validator, or `aws iam simulate-custom-policy`) directly checks the string's structure and compliance with AWS IAM policy schema, which is the most efficient first step before re-running Terraform. This isolates the issue from Terraform's execution logic and avoids unnecessary plan/apply cycles.
Q4
easyFull explanation →

A team wants to ensure that all Terraform runs are recorded for audit purposes. Which practice should they implement?

A

Run 'terraform show' after every apply to capture state.

B

Add the state file to version control after each run.

C

Enable state locking in the backend configuration.

D

Configure a remote backend that supports state versioning.

Remote backends like S3 with versioning keep a history of state changes.

Why: Option D is correct because configuring a remote backend that supports state versioning (e.g., Terraform Cloud, S3 with versioning enabled) automatically records every state change, providing a complete audit trail of all Terraform runs. This ensures that previous state snapshots are preserved and can be reviewed or restored if needed, meeting audit requirements without manual intervention.
Q5
mediumFull explanation →

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

A

terraform fmt

B

terraform plan

Plan is the second step in the core workflow.

C

terraform validate

D

terraform apply

Apply is the final step in the core workflow.

E

terraform destroy

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

Which THREE of the following are valid reasons to use 'terraform refresh'? (Choose three.)

A

To update the state file when resources were deleted outside of Terraform.

Refresh will mark deleted resources as removed from state.

B

To detect drift between the state file and actual infrastructure.

Refresh updates state with current resource attributes, revealing drift.

C

To import existing infrastructure into Terraform management.

D

To update the state file after making manual changes to resources.

Refresh reconciles state with manual changes.

E

To update the Terraform configuration with current resource settings.

Why: Option A is correct because `terraform refresh` updates the state file to reflect the current real-world infrastructure, including resources that were deleted outside of Terraform. This ensures the state file accurately represents the actual infrastructure, preventing drift and allowing Terraform to plan correctly.

Want more Use the core Terraform workflow practice?

Practice this domain
7

Domain 7: Implement and maintain state

All Implement and maintain state questions
Q1
mediumFull explanation →

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

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

C

Manually edit the state file to remove the lock

D

Run terraform unlock

Why: 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.
Q2
hardFull explanation →

An organization uses Terraform with AWS S3 backend and DynamoDB for state locking. During a plan, you receive an error: 'Error acquiring the state lock'. The lock information in DynamoDB shows a lock from a previous session that crashed. What is the most appropriate next step?

A

Run terraform unlock

B

Run terraform force-unlock with the lock ID

This command releases the lock from the previous session.

C

Wait for the lock to expire automatically

D

Delete the lock item from DynamoDB table directly

Why: The correct answer is B because when a Terraform process crashes while holding a state lock, the lock remains in DynamoDB and must be manually released. The `terraform force-unlock` command with the specific lock ID is the designed mechanism to override a stale lock, as it directly interacts with the DynamoDB locking table to remove the lock item. This is the safest and most appropriate method, as it ensures the lock is released in a controlled manner without risking state corruption.
Q3
easyFull explanation →

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

A

terraform apply

B

terraform refresh

C

terraform import

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

D

terraform state mv

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

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

A

Using the -backend-config flag

B

Using the backend block with a workspace key

C

Using partial configuration with a backend block that has dynamic workspace references

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

D

Using a remote backend type

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

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

A

Run terraform state upgrade

B

Run terraform apply with no changes to upgrade the state format

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

C

Delete the state file and reimport resources

D

Downgrade Terraform to v0.12.0

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

A user wants to remove a specific resource from Terraform state without destroying the actual infrastructure. Which command should they use?

A

terraform state rm resource

This removes the resource from state without affecting the real infrastructure.

B

terraform taint resource

C

terraform state mv resource

D

terraform destroy -target=resource

Why: The `terraform state rm` command is the correct choice because it removes a specified resource from the Terraform state file without making any API calls to the actual infrastructure provider. This allows the resource to be detached from Terraform management while leaving the real-world resource running, which is exactly what the user wants.

Want more Implement and maintain state practice?

Practice this domain
8

Domain 8: Read, generate and modify configuration

All Read, generate and modify configuration questions
Q1
easyFull explanation →

A team wants to use Terraform to provision infrastructure across multiple cloud providers. Which configuration approach best supports this goal?

A

Define multiple provider blocks, one for each cloud provider.

Allows using multiple providers in the same configuration.

B

Use a single provider block that supports multiple clouds.

C

Terraform cannot manage multiple clouds in one configuration.

D

Create separate workspaces for each cloud provider.

Why: Option A is correct because Terraform uses multiple provider blocks to manage resources from different cloud providers within a single configuration. Each provider block configures a separate provider (e.g., aws, azurerm, google) with its own authentication and region settings, allowing Terraform to provision and manage infrastructure across AWS, Azure, GCP, and others in the same state file and execution plan.
Q2
mediumFull explanation →

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'.

Creates new resource before destroying old one, reducing downtime.

C

Set 'ignore_changes' to the attribute causing the replacement.

D

Add 'prevent_destroy = true' to the resource.

Why: 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.
Q3
hardFull explanation →

A Terraform configuration uses a module from the Terraform Registry. After updating the module version in the configuration, the operator runs 'terraform plan' but does not see the changes expected from the new version. What is the most likely cause?

A

The operator did not run 'terraform get' to update modules.

B

The operator did not run 'terraform init' after changing the version.

'terraform init' downloads the specified module version.

C

The operator did not run 'terraform refresh' to update state.

D

The module version constraint is stored in the state file and must be updated.

Why: When you change a module version in the configuration, Terraform must re-initialize the working directory to download the new version and update the dependency lock file (.terraform.lock.hcl). Running 'terraform plan' without first running 'terraform init' will use the previously cached module version, so the expected changes from the new version will not appear. 'terraform init' is the required command to fetch and lock the updated module source.
Q4
easyFull explanation →

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

A

Use 'if var.create' inside the resource block

B

Use 'for_each = var.create ? [1] : []'

C

Use 'count = var.create'

D

Use 'count = var.create ? 1 : 0'

Correct pattern: count with ternary.

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

An operator wants to pass output values from one Terraform configuration to another as input variables. Which approach is recommended?

A

Hardcode the output values in a variables file for the second configuration.

B

Store outputs in a shared file and use 'file()' function to read them.

C

Use a remote state data source to read the outputs from the first configuration's state.

Data sources allow reading outputs from remote state.

D

Use environment variables to pass the output values.

Why: Option C is correct because Terraform's remote state data source (e.g., `terraform_remote_state`) allows one configuration to securely read output values from another configuration's state file stored in a shared backend (like S3, Azure Storage, or Consul). This avoids duplication, manual errors, and ensures that the second configuration always uses the latest outputs from the first, without requiring direct file access or environment variables.
Q6
hardFull explanation →

A Terraform configuration includes a resource block with a 'lifecycle' block that has 'create_before_destroy = true'. During an apply, the create step succeeds but the destroy step fails. What is the resulting state?

A

Only the new resource remains in state, old resource is destroyed.

B

The state is empty for that resource address.

C

Only the old resource remains in state.

D

Both the old and new resources are in state.

New resource created; old resource not destroyed.

Why: When `create_before_destroy = true` is set, Terraform creates the new resource first, then destroys the old one. If the destroy step fails after the new resource is created, both resources exist in the state file because Terraform does not remove the old resource from state until the destroy operation completes successfully. The state retains both resource instances at the same address, which is why option D is correct.

Want more Read, generate and modify configuration practice?

Practice this domain

Frequently asked questions

How many questions are on the TF-003 exam?

The TF-003 exam has 57 questions and must be completed in 60 minutes. The passing score is 700/1000.

What types of questions appear on the TF-003 exam?

Scenario-based questions covering exam objectives with detailed answer explanations.

How are TF-003 questions organised by domain?

The exam covers 8 domains: Understand IaC concepts, Understand Terraform basics, Understand Terraform's purpose, Use Terraform outside the core workflow, Interact with Terraform modules, Use the core Terraform workflow, Implement and maintain state, Read, generate and modify configuration. Questions are weighted by domain — higher-weight domains appear more on your actual exam.

Are these the actual TF-003 exam questions?

No. These are original exam-style practice questions written against the official HashiCorp TF-003 exam objectives. They are not copied from the real exam. Courseiva focuses on genuine understanding, not memorisation of braindumps.

Ready to practice all 57 TF-003 questions?

Courseiva tracks your accuracy per domain and routes you toward weak areas automatically. Free, no account required.

Browse all TF-003 questionsTake a timed practice test