HashiCorp Terraform Associate (004) Question 48
Single answer3 Core Terraform workflowYour team stores Terraform configuration in Git and uses a shared remote backend for state. A developer updates the AWS provider version constraint in the configuration and adds a new module that uses a different provider. On a clean CI runner, the pipeline immediately runs terraform plan and fails before showing any execution plan. The team wants the smallest change to the workflow that will make the pipeline reliable when provider selections or modules change. Which action should be added?
- A
Run
terraform refreshbeforeterraform planso Terraform updates provider information from the real infrastructure - B
Run
terraform initbeforeterraform planso Terraform installs required providers and initializes modules and backend settings - C
Run
terraform fmt -recursivebeforeterraform planso Terraform can detect the new provider and module dependencies - D
Run
terraform validatebeforeterraform planso Terraform automatically downloads any missing plugins and modules
Show answer and explanation
Correct answer: B
Explanation
The correct answer is to add terraform init before terraform plan. Terraform's core workflow is typically init, plan, and apply. The init step is required to prepare the working directory, including backend initialization, child module installation, and provider plugin installation based on the dependency lock file and version constraints. This is especially important on ephemeral CI runners, where no prior initialization exists, and after changes to provider requirements or module sources. HashiCorp documentation for terraform init describes it as the command that initializes a working directory containing Terraform configuration files, including downloading and installing providers and modules. Best practice in automation is to run terraform init in each fresh execution environment before planning or applying.
- A. Incorrect.
terraform refreshis not the right fix here. Refresh updates state data to reflect real infrastructure, but it does not perform the initialization required on a clean runner. It will not reliably install required providers or initialize modules and backend configuration for the working directory. A common misconception is that refresh prepares Terraform for planning, but initialization is a separate core workflow step. - B. Correct.
terraform initis correct. In the core Terraform workflow,initprepares the working directory by initializing the backend, installing and selecting required provider plugins, and downloading child modules. On a clean CI runner, or whenever provider requirements or modules change,terraform initshould be run beforeterraform plan. This is the minimal workflow change that directly addresses the failure scenario. - C. Incorrect.
terraform fmt -recursiveonly rewrites configuration files into canonical formatting. It helps with code consistency and review quality, but it does not initialize the working directory, download modules, or install providers. Someone might choose this option because formatting is often enforced in CI, but it does not solve initialization failures. - D. Incorrect.
terraform validatechecks whether a configuration is syntactically valid and internally consistent, but it is not the step that should be relied on to initialize the environment. Validation is typically run after initialization because Terraform needs the working directory prepared first, especially when providers and modules are involved. It does not replaceterraform initin the workflow.