- A
Keep 'Auto Apply' enabled but restrict the production workspace to only the infrastructure lead's Terraform Cloud account.
Why wrong: This would prevent developers from even planning, which is not desired.
- B
Use run triggers to promote runs from dev to staging to production, and only the lead can promote to production.
Why wrong: Run triggers automate runs but do not enforce approval per plan.
- C
Disable 'Auto Apply' on the production workspace and configure team permissions so that developers have 'plan' role and the infrastructure lead has 'write' role.
This enforces manual approval and restricts apply permissions.
- D
Use VCS branch restrictions to only allow applies from the 'main' branch, and have developers plan from feature branches.
Why wrong: This only works if all runs come from VCS; developers might still apply via UI from a plan.
Quick Answer
The correct answer is to disable 'Auto Apply' on the production workspace and configure team permissions so that developers have the 'plan' role while the infrastructure lead has the 'write' role. This combination directly addresses the security gap because disabling Auto Apply removes the automated trigger that allowed a developer’s plan to become an apply without intervention, while the 'plan' role explicitly restricts developers to only running plans—preventing them from applying even through the UI. The 'write' role for the lead preserves the ability to approve and apply changes, enforcing the required approval workflow. On the HashiCorp Terraform Associate TF-003 exam, this scenario tests your understanding of Terraform Cloud approval workflow permissions and the distinction between workspace-level roles versus team-level permissions; a common trap is assuming that removing 'write' access alone suffices, but without disabling Auto Apply, a plan can still auto-apply. Remember the memory tip: “Plan to see, Write to be—Auto Apply breaks the key.”
TF-003 Use Terraform outside the core workflow Practice Question
This TF-003 practice question tests your understanding of use terraform outside the core workflow. This is a configuration task: choose the command set that satisfies every stated requirement. Small differences — like 'secret' vs 'password' or 'transport input ssh' vs 'all' — change whether the answer is correct. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
A large enterprise uses Terraform Cloud with remote execution mode to manage infrastructure across multiple AWS accounts. Each environment (dev, staging, prod) has a separate workspace. The security team requires that all changes to production must be approved by a senior engineer before applying. Additionally, developers should be able to plan changes in production to preview the impact, but not apply them. The current setup uses the same Terraform Cloud team membership for all workspaces. When a developer runs a plan in production, the plan succeeds but they are unable to apply. However, the security team notices that the developer can accidentally apply if they quickly approve their own plan via the UI because the workspace is configured with 'Auto Apply' enabled. The security team wants to enforce the approval process without removing the developer's ability to plan. Which combination of changes should be made? (Select only one option.)
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
Disable 'Auto Apply' on the production workspace and configure team permissions so that developers have 'plan' role and the infrastructure lead has 'write' role.
Option C is correct because disabling 'Auto Apply' on the production workspace ensures that no apply occurs without explicit approval. Configuring team permissions so that developers have the 'plan' role (which allows running plans but not applying) and the infrastructure lead has the 'write' role (which allows applying) enforces the required approval process while preserving the developer's ability to preview changes via plan.
Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Keep 'Auto Apply' enabled but restrict the production workspace to only the infrastructure lead's Terraform Cloud account.
Why it's wrong here
This would prevent developers from even planning, which is not desired.
- ✗
Use run triggers to promote runs from dev to staging to production, and only the lead can promote to production.
Why it's wrong here
Run triggers automate runs but do not enforce approval per plan.
- ✓
Disable 'Auto Apply' on the production workspace and configure team permissions so that developers have 'plan' role and the infrastructure lead has 'write' role.
Why this is correct
This enforces manual approval and restricts apply permissions.
Related concept
Read the scenario before looking for a memorised answer.
- ✗
Use VCS branch restrictions to only allow applies from the 'main' branch, and have developers plan from feature branches.
Why it's wrong here
This only works if all runs come from VCS; developers might still apply via UI from a plan.
Common exam traps
Common exam trap: answer the scenario, not the keyword
HashiCorp often tests the distinction between run triggers (which automate promotion) and manual approval workflows, leading candidates to incorrectly choose run triggers as a solution for approval enforcement when they actually bypass manual approval.
Detailed technical explanation
How to think about this question
In Terraform Cloud, the 'plan' role grants permission to create and view plans but not to confirm applies, while the 'write' role includes apply capability. Disabling 'Auto Apply' ensures that even if a plan is created, a separate manual confirmation (approval) is required, which can be restricted to users with the 'write' role. This setup is commonly used in regulated environments to enforce separation of duties, where developers can propose changes but only senior engineers can approve and apply them.
KKey Concepts to Remember
- Read the scenario before looking for a memorised answer.
- Find the constraint that changes the correct option.
- Eliminate answers that are true in general but not in this case.
TExam Day Tips
- Watch for words such as best, first, most likely and least administrative effort.
- Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Real-world example
How this comes up in practice
A small business has 20 workstations on the 192.168.1.0/24 network and one public IP from its ISP. The router uses PAT (NAT overload) so all 20 devices share one public address using different source ports. NAT questions test whether you understand the four address terms and which direction each translation applies.
What to study next
Got this wrong? Here's your next step.
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
- →
Use Terraform outside the core workflow — study guide chapter
Learn the concepts, then practise the questions
- →
Use Terraform outside the core workflow practice questions
Targeted practice on this topic area only
- →
All TF-003 questions
519 questions across all exam domains
- →
HashiCorp Terraform Associate TF-003 study guide
Full concept coverage aligned to exam objectives
- →
TF-003 practice test guide
How to use practice tests most effectively before exam day
Related practice questions
Related TF-003 practice-question pages
Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.
Understand IaC concepts practice questions
Practise TF-003 questions linked to Understand IaC concepts.
Understand Terraform basics practice questions
Practise TF-003 questions linked to Understand Terraform basics.
Understand Terraform's purpose practice questions
Practise TF-003 questions linked to Understand Terraform's purpose.
Use Terraform outside the core workflow practice questions
Practise TF-003 questions linked to Use Terraform outside the core workflow.
Interact with Terraform modules practice questions
Practise TF-003 questions linked to Interact with Terraform modules.
Use the core Terraform workflow practice questions
Practise TF-003 questions linked to Use the core Terraform workflow.
Implement and maintain state practice questions
Practise TF-003 questions linked to Implement and maintain state.
Read, generate and modify configuration practice questions
Practise TF-003 questions linked to Read, generate and modify configuration.
TF-003 fundamentals practice questions
Practise TF-003 questions linked to TF-003 fundamentals.
TF-003 scenario practice questions
Practise TF-003 questions linked to TF-003 scenario.
TF-003 troubleshooting practice questions
Practise TF-003 questions linked to TF-003 troubleshooting.
Practice this exam
Start a free TF-003 practice session
Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.
FAQ
Questions learners often ask
What does this TF-003 question test?
Use Terraform outside the core workflow — This question tests Use Terraform outside the core workflow — Read the scenario before looking for a memorised answer..
What is the correct answer to this question?
The correct answer is: Disable 'Auto Apply' on the production workspace and configure team permissions so that developers have 'plan' role and the infrastructure lead has 'write' role. — Option C is correct because disabling 'Auto Apply' on the production workspace ensures that no apply occurs without explicit approval. Configuring team permissions so that developers have the 'plan' role (which allows running plans but not applying) and the infrastructure lead has the 'write' role (which allows applying) enforces the required approval process while preserving the developer's ability to preview changes via plan.
What should I do if I get this TF-003 question wrong?
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
What is the key concept behind this question?
Read the scenario before looking for a memorised answer.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
3 more ways this is tested on TF-003
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. An organization uses Terraform Cloud for team collaboration. They have a workspace that manages production infrastructure. Due to a security policy, they must ensure that all changes go through a peer review process before they are applied. How can they enforce this requirement?
medium- ✓ A.Enable 'apply on merge' and set the workspace to require approval before applying.
- B.Require all changes to be submitted via a VCS pull request.
- C.Use run triggers to automatically apply after a successful plan in another workspace.
- D.Lock the workspace and only unlock it for approved changes.
Why A: Option A is correct because enabling 'apply on merge' combined with requiring approval before applying enforces a peer review process: changes must be merged via a VCS pull request (triggering the plan), and then a separate approval step is needed before Terraform Cloud applies the changes. This ensures that no change is applied without explicit human approval after the plan is reviewed.
Variation 2. 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?
hard- A.Store state in a remote backend and use terraform apply in the pipeline
- ✓ B.Configure Terraform Cloud with run triggers and policy checks
- C.Use the Terraform CLI in the CI/CD pipeline with remote state
- D.Run terraform apply locally after manual approval
Why B: 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.
Variation 3. You are a platform engineer at a large enterprise that uses Terraform Cloud with a VCS-backed workflow for all infrastructure. Your team manages a configuration that provisions AWS EC2 instances for a critical application. Recently, a junior team member accidentally committed a change that removed a required tag from the EC2 instance resource. The change passed the plan stage but was blocked by a Sentinel policy during the apply, preventing the infrastructure from being updated. The team needs to fix the configuration and apply the change. However, the repository is configured to automatically trigger runs on every push to the main branch. The team wants to avoid triggering an unwanted run while they work on the fix. What should the team do?
hard- A.Temporarily disable the VCS connection in Terraform Cloud to prevent runs
- B.Run terraform apply locally with the fixed configuration to bypass Terraform Cloud
- ✓ C.Create a feature branch, fix the configuration, and merge via pull request
- D.Amend the commit on main and force push to overwrite history
Why C: Option C is correct because using a feature branch and pull request allows the team to fix the configuration without triggering a run on the main branch, since Terraform Cloud’s VCS integration only auto-triggers runs on pushes to the configured branch (typically main). Once the fix is merged via pull request, the change will be applied through the normal VCS-backed workflow, maintaining audit trails and policy enforcement. This approach avoids disrupting the VCS connection or bypassing Terraform Cloud’s governance.
Last reviewed: Jun 30, 2026
This TF-003 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-003 exam.
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.