Sample questions
HashiCorp Terraform Associate TF-003 practice questions
Which TWO statements accurately describe the purpose of Terraform? (Choose two.)
Trap 1: Terraform is designed to work exclusively with AWS.
Terraform supports many providers, not just AWS.
Trap 2: Terraform is a configuration management tool used for installing…
Terraform is for provisioning, not configuration management.
Trap 3: Terraform is a continuous integration and deployment tool.
Terraform is an IaC tool, not a CI/CD tool.
- A
Terraform allows users to define infrastructure resources in a declarative configuration language.
Terraform uses HCL to declare desired state.
- B
Terraform can be used to create, modify, and destroy infrastructure resources.
Terraform manages full lifecycle of resources.
- C
Terraform is designed to work exclusively with AWS.
Why wrong: Terraform supports many providers, not just AWS.
- D
Terraform is a configuration management tool used for installing software on existing servers.
Why wrong: Terraform is for provisioning, not configuration management.
- E
Terraform is a continuous integration and deployment tool.
Why wrong: Terraform is an IaC tool, not a CI/CD tool.
A team is evaluating Terraform for managing their multi-cloud infrastructure. Which TWO statements accurately describe Terraform's purpose and capabilities? (Choose two.)
Trap 1: Terraform requires all configuration files to be placed in a single…
Terraform works with any directory structure; configurations can be organized as needed.
Trap 2: Terraform uses an imperative language to specify the exact steps to…
Terraform's language (HCL) is declarative, not imperative.
Trap 3: Terraform is primarily a configuration management tool for…
Terraform is an orchestration tool; configuration management is done by tools like Ansible, Chef, etc.
- A
Terraform requires all configuration files to be placed in a single directory named 'terraform'.
Why wrong: Terraform works with any directory structure; configurations can be organized as needed.
- B
Terraform can provision, update, and destroy infrastructure resources across multiple providers.
Terraform manages the full lifecycle of infrastructure resources.
- C
Terraform's configuration language (HCL) is designed to be human-readable and machine-friendly.
HCL is specifically designed to be easy for humans to read and write while being machine-parseable.
- D
Terraform uses an imperative language to specify the exact steps to create resources.
Why wrong: Terraform's language (HCL) is declarative, not imperative.
- E
Terraform is primarily a configuration management tool for installing software on servers.
Why wrong: Terraform is an orchestration tool; configuration management is done by tools like Ansible, Chef, etc.
Which TWO of the following are valid use cases for using Terraform Cloud's Sentinel policies? (Choose two.)
Trap 1: Provide cost estimates for infrastructure changes
Cost estimation is a separate Terraform Cloud feature.
Trap 2: Enforce that all Terraform code follows a specific formatting style
Formatting is enforced by terraform fmt, not Sentinel.
Trap 3: Automatically rotate database passwords
Not a Sentinel feature; managed by vault or similar.
- A
Provide cost estimates for infrastructure changes
Why wrong: Cost estimation is a separate Terraform Cloud feature.
- B
Enforce that all Terraform code follows a specific formatting style
Why wrong: Formatting is enforced by terraform fmt, not Sentinel.
- C
Enforce that all AWS instances are of a specific type
Sentinel can restrict resource attributes.
- D
Automatically rotate database passwords
Why wrong: Not a Sentinel feature; managed by vault or similar.
- E
Enforce that all resources have required tags
Sentinel can check for tags.
Match each Terraform function to its category.
Drag a concept onto its matching description — or click a concept then click the description.
List function
Map function
IP network function
Encoding function
Date and time function
Match each Terraform provisioner to its typical use case.
Drag a concept onto its matching description — or click a concept then click the description.
Copy files to the remote resource
Run a script on the machine running Terraform
Run a script on the remote resource
Configure resource using Chef
Configure resource using Puppet
Match each Terraform meta-argument to its purpose.
Drag a concept onto its matching description — or click a concept then click the description.
Create multiple instances from one resource block
Create multiple instances from a map or set of strings
Explicitly specify hidden resource dependencies
Control resource creation/destruction behavior
Select a non-default provider configuration
Match each Terraform cloud/enterprise feature to its purpose.
Drag a concept onto its matching description — or click a concept then click the description.
Organize state and runs for different environments
Integrate third-party policy or compliance checks
Policy as code framework for governance
Store state securely in Terraform Cloud
Trigger runs automatically from version control
Match each Terraform state command to its action.
Drag a concept onto its matching description — or click a concept then click the description.
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
Match each Terraform feature to its description.
Drag a concept onto its matching description — or click a concept then click the description.
Maps real-world resources to configuration
Plugin to interact with a specific cloud or service API
Container for multiple resources used together
Defines where state snapshots are stored
Executes scripts on local or remote machine during creation/destruction
Match each Terraform command to its primary function.
Drag a concept onto its matching description — or click a concept then click the description.
Initialize a working directory with provider plugins
Create an execution plan
Execute the actions proposed in a plan
Destroy previously-created infrastructure
Check configuration for syntax and internal consistency
Match each Terraform workflow stage to its description.
Drag a concept onto its matching description — or click a concept then click the description.
Author infrastructure as code configuration
Preview changes before applying
Execute the planned changes
Tear down managed infrastructure
Restructure configuration without changing external resources
Match each Terraform error code to its meaning.
Drag a concept onto its matching description — or click a concept then click the description.
Success – no errors
Error – command failed
Error – CLI argument parsing error
Error – configuration errors
Error – state lock error
Match each Terraform variable type to its example value.
Drag a concept onto its matching description — or click a concept then click the description.
"hello"
42
true
["a", "b"]
{"key" = "value"}
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?
Trap 1: Store state locally and use a manual approval process outside of…
Manual approval outside Terraform is not integrated and local state is not shared.
Trap 2: Store state locally and use a shared network drive for team access.
Local state on a network drive can cause corruption and lacks locking.
Trap 3: Have each team member run terraform apply from their local machine…
Local apply bypasses review and risks inconsistent state.
- A
Store state locally and use a manual approval process outside of Terraform.
Why wrong: Manual approval outside Terraform is not integrated and local state is not shared.
- 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.
Why wrong: Local state on a network drive can cause corruption and lacks locking.
- D
Have each team member run terraform apply from their local machine after informal discussion.
Why wrong: Local apply bypasses review and risks inconsistent state.
Which THREE of the following are benefits of using Infrastructure as Code (IaC) compared to manual infrastructure management?
Trap 1: The same code can be used for any cloud provider without…
Terraform providers are provider-specific; code needs changes.
Trap 2: No learning curve is required; existing knowledge of manual…
IaC introduces new tools and languages that require learning.
- 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.
Why wrong: Terraform providers are provider-specific; code needs changes.
- 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 wrong: IaC introduces new tools and languages that require learning.
A company wants to use Terraform to manage resources across AWS and Azure. They need a single workflow that can apply changes to both providers. What is the best practice?
Trap 1: Use separate Terraform configurations for each provider
Requires separate workflows.
Trap 2: Use Terraform Cloud workspaces with different providers
Still requires separate configurations per workspace.
Trap 3: Use Terraform workspaces to separate providers
Workspaces separate state, not providers.
- A
Use separate Terraform configurations for each provider
Why wrong: Requires separate workflows.
- B
Use Terraform Cloud workspaces with different providers
Why wrong: Still requires separate configurations per workspace.
- C
Use Terraform workspaces to separate providers
Why wrong: Workspaces separate state, not providers.
- D
Define both providers in a single configuration
Allows unified workflow.
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?
Trap 1: Run terraform destroy and then apply
Unnecessarily destroys existing resources.
Trap 2: Run terraform refresh
Only updates state, does not create resources.
Trap 3: Run terraform apply -auto-approve
Same as apply, but auto-approve doesn't resume.
- A
Run terraform apply again
Idempotent; creates missing resources.
- B
Run terraform destroy and then apply
Why wrong: Unnecessarily destroys existing resources.
- C
Run terraform refresh
Why wrong: Only updates state, does not create resources.
- D
Run terraform apply -auto-approve
Why wrong: Same as apply, but auto-approve doesn't resume.
A company uses Terraform to manage infrastructure across multiple AWS accounts. They want to use a single S3 bucket to store state files for all accounts, but ensure that state files are isolated per account. What is the best approach?
Trap 1: Use Terraform workspaces with a single state file
Workspaces still store state in the same backend, but separate state files; however, they can be used with different keys.
Trap 2: Store all state in the same S3 key
Using the same key would overwrite state, causing data loss.
Trap 3: Use a DynamoDB table with different lock IDs per account
Locking doesn't isolate state; it only prevents concurrent access.
- A
Use Terraform workspaces with a single state file
Why wrong: Workspaces still store state in the same backend, but separate state files; however, they can be used with different keys.
- B
Use separate state files with unique S3 key prefixes per account
Unique key prefixes ensure each account has its own state file.
- C
Store all state in the same S3 key
Why wrong: Using the same key would overwrite state, causing data loss.
- D
Use a DynamoDB table with different lock IDs per account
Why wrong: Locking doesn't isolate state; it only prevents concurrent access.
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?
Trap 1: Terraform state locking prevented the apply from executing…
Locking prevents concurrent applies but doesn't cause plan mismatch.
Trap 2: The state file was corrupted during the apply.
State corruption would cause errors, not a different number of changes.
Trap 3: The 'terraform apply' command includes an implicit refresh that…
Refresh updates state but does not change the planned actions unless the config changed.
- A
Terraform state locking prevented the apply from executing correctly.
Why wrong: Locking prevents concurrent applies but doesn't cause plan mismatch.
- B
The state file was corrupted during the apply.
Why wrong: State corruption would cause errors, not a different number of changes.
- 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 wrong: Refresh updates state but does not change the planned actions unless the config changed.
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?
Trap 1: Delete the state file from the backend and reinitialize
Deleting the state file is destructive and can cause data loss.
Trap 2: Manually edit the state file to remove the lock
Editing the state file directly is risky and not recommended.
Trap 3: Run terraform unlock
There is no terraform unlock command; the correct command is terraform force-unlock.
- A
Delete the state file from the backend and reinitialize
Why wrong: Deleting the state file is destructive and can cause data loss.
- 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
Why wrong: Editing the state file directly is risky and not recommended.
- D
Run terraform unlock
Why wrong: There is no terraform unlock command; the correct command is terraform force-unlock.
A configuration uses variables defined in a 'variables.tf' file. The operator wants to override these variables for a specific run without modifying the file. Which method should they use?
Trap 1: Edit the state file directly.
State does not store variable values.
Trap 2: Set environment variables with the same name as the variables.
Environment variables work but must be prefixed with 'TF_VAR_'.
Trap 3: Create a 'terraform.tfvars' file.
This is a persistent file, not for a single run.
- A
Edit the state file directly.
Why wrong: State does not store variable values.
- B
Set environment variables with the same name as the variables.
Why wrong: Environment variables work but must be prefixed with 'TF_VAR_'.
- C
Create a 'terraform.tfvars' file.
Why wrong: This is a persistent file, not for a single run.
- D
Use the '-var' flag with 'terraform plan' or 'terraform apply'.
Command-line flag overrides variables for that run.
Drag and drop the steps to handle sensitive data in Terraform outputs in the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Drag and drop the steps to use Terraform workspaces for environment separation in the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Drag and drop the steps to import existing infrastructure into Terraform state in the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.