Describe the Terraform workflow from code to live

This tests Terraform workflows beyond local commands. A strong answer covers: version-controlled code, terraform plan for speculative validation, then terraform apply via remote runs with policies. Red flag: only local apply without reviews or remote state.
What's really being asked
Whether you understand that team-based Terraform is not just local CLI commands but a structured workflow involving version control, remote execution, policy enforcement, and state management. Interviewers want to see you know the difference between a solo developer running commands on a laptop and a production-grade pipeline that uses HCP Terraform or similar remote backends for collaboration.
The full answer
First, write and commit configuration changes to version control so the code is reviewable. Second, authenticate to the remote environment, for example with terraform login for HCP Terraform. Third, run terraform plan to start a speculative plan that executes remotely using workspace variables and enforces any applicable Sentinel or OPA policies without copying sensitive values locally. Fourth, after review, execute terraform apply to start a standard plan and apply in the remote workspace, or use a two-part saved plan run with terraform plan -out FILE followed by terraform apply FILE to ensure the exact approved plan is what gets deployed. Fifth, verify the run completed and outputs are correct. The answer should mention that remote runs use the private registry and remote state inputs, and that this CLI-driven workflow can integrate with existing CI/CD pipelines.
The mistakes people make
Describing only a local workflow where the developer runs terraform init, plan, and apply on their own machine with local state. Forgetting to mention code review or version control. Saying terraform apply runs immediately without a plan phase in remote workflows. Claiming that speculative plans modify infrastructure. Not mentioning policy enforcement, workspace variables, or state locking. Confusing the CLI-driven workflow with purely local execution.
What usually comes next
How would you handle a failed apply or partial state? When would you use a saved plan run versus a standard remote apply? How do you manage secrets and sensitive variables in a team setting? What is the difference between UI/VCS-driven runs and CLI-driven runs? How do you roll back a Terraform change?
A concrete example
A developer needs to add an AWS subnet. They branch, edit the Terraform configuration, and open a pull request. After peer review, they run terraform plan from their local terminal which triggers a speculative plan in HCP Terraform. The plan shows the subnet and passes Sentinel policy checks. Because the workspace has no linked VCS repository, they then run terraform apply to execute a standard remote plan and apply. The run executes in HCP Terraform using workspace variables and remote state, locks the state during the operation, and creates the subnet. The developer verifies the new resource in the AWS console.
Interview question
A developer runs terraform plan in a CLI-driven HCP Terraform workspace. What occurs during this step?
- a.The workspace locks state and provisions the proposed resources immediately after policy checks pass
- b.A remote speculative plan previews changes, validates against policies, and leaves infrastructure unchangedCorrect
- c.All workspace variables and sensitive values are downloaded to the developer's local machine for execution
- d.The configuration is automatically committed to version control before the remote run begins
Why? this is the answer
terraform plan initiates a remote speculative run that shows proposed changes and checks policies without altering infrastructure. Distractor A is wrong because provisioning and state locking happen during terraform apply, not during the speculative plan phase.
Just read this? Test yourself on what you have been reading.
Read the original → developer.hashicorp.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles