TF-004 Read, generate and modify configuration Practice Question
Which TWO of the following are best practices when writing Terraform configuration for a team? (Select TWO.)
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Pin provider versions using `required_providers`.
Options B and D are correct. Pinning provider versions using `required_providers` ensures reproducibility across team members. Using a remote backend with state locking prevents state corruption and conflicts. Option A is wrong because using `latest` versions can introduce breaking changes unexpectedly. Option C is wrong because hardcoding values (especially secrets) is insecure and inflexible. Option E is wrong because a single monolithic configuration file is harder to maintain and collaborate on.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Always use the `latest` version for providers.
Why it's wrong here
Always using the `latest` version for providers is a significant anti-pattern in Terraform configurations because it introduces non-deterministic behavior into your infrastructure deployments. New provider versions can frequently introduce breaking changes, deprecations, or altered resource behaviors that lead to unexpected infrastructure modifications or outright failures during `terraform apply`. This practice severely compromises the reproducibility and stability of your infrastructure code, making debugging and auditing substantially more challenging across different deployment cycles.
- ✓
Pin provider versions using `required_providers`.
Why this is correct
Pinning specific provider versions within the `terraform` block's `required_providers` configuration is a crucial best practice for ensuring consistent and reproducible infrastructure deployments. This explicit version constraint guarantees that Terraform always uses a known, tested version of the provider, preventing unexpected behavior or breaking changes that might be introduced in newer, untested releases. It fosters reliability, predictability, and stability across different environments and among team members, making your infrastructure code robust and dependable.
- ✗
Hardcode all values in the configuration for simplicity.
Why it's wrong here
Hardcoding all configuration values directly into your Terraform files is a detrimental practice that severely limits the reusability and flexibility of your infrastructure code. This approach makes it impossible to deploy the same configuration across different environments (e.g., development, staging, production) without manual modification, leading to configuration drift and errors. Furthermore, it poses significant security risks by embedding sensitive information directly into the codebase, making it difficult to manage secrets securely and share configurations safely.
- ✓
Use a remote backend with state locking.
Why this is correct
Employing a remote backend with state locking is an essential best practice, particularly in collaborative or automated Terraform environments. A remote backend, such as AWS S3 with DynamoDB or Azure Storage, securely stores the Terraform state file, making it accessible to all authorized users and processes. Crucially, state locking mechanisms prevent multiple concurrent `terraform apply` operations from modifying the state file simultaneously, thereby averting state corruption, lost updates, and ensuring the integrity and consistency of your infrastructure state.
- ✗
Store the entire infrastructure in a single configuration file.
Why it's wrong here
Storing an entire infrastructure's definition within a single Terraform configuration file is an unsustainable practice that quickly leads to an unmanageable and error-prone codebase as the infrastructure scales. This monolithic approach severely hinders modularity, reusability, and maintainability, making it exceedingly difficult to navigate, understand, or modify specific components. It prevents the logical separation of concerns and the creation of reusable modules, which are fundamental for organizing complex infrastructure and promoting efficient collaboration.
Go deeper
Related to this question
About these practice questions
One of 428 original TF-004 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This TF-004 practice question is part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the TF-004 exam.