Task 3.1: Manage and scale infrastructure projects

• ARecreate the app servers in the new configuration; move the database with removed and import blocks

  Correct

  HashiCorp recommends recreating stateless resources when that causes no downtime, and moving stateful ones with a removed block (destroy = false) in the source and an import block in the destination, both visible in plans.

• BMove every resource, the database and servers included, with terraform state mv -state and -state-out

  Incorrect

  state mv between state files is the legacy approach and changes state outside the plan and apply workflow, so the moves are not reviewable.

• CKeep one configuration and use CLI workspaces named network, data and app

  Incorrect

  Workspaces are not a tool for system decomposition; each component should have its own configuration and backend.

• DCopy the state file into each new backend, then prune each copy with terraform state rm until it fits

  Incorrect

  Copying state duplicates every binding first and depends on manual pruning outside plans, which risks two configurations managing one object.

Group resources by rate of change, statefulness and ownership. Recreate what is cheap and safe to recreate, and use removed and import blocks (Terraform 1.7 or later) for objects that must survive the move.

• AEach module in its own repository, apart from the infrastructure configuration

  Correct

  The style guide recommends storing infrastructure configuration separately from module code and keeping each module in an individual repository, so each one can be versioned and published on its own.

• BAll modules in a modules/ folder of the production configuration

  Incorrect

  Local modules share their caller's version and cannot be versioned or published independently.

• COne repository holding every module, tagged with a single version

  Incorrect

  A shared tag forces every module to release together.

• DInside the .terraform directory, copied in by terraform init

  Incorrect

  .terraform is a local directory that init manages for one working directory, not a place to keep shared code.

Separate module repositories let teams version each module independently and publish it to a private registry.

• AThe registry cannot publish any module that is stored in a monorepo

  Incorrect

  The style guide mentions module publishing for separate repositories, but the drawback it lists for monorepos concerns automation and access.

• BTerraform cannot read local modules from another directory

  Incorrect

  Root modules in a monorepo routinely call local modules by relative path.

• CCI must target changed directories, and access is less granular

  Correct

  Any change can trigger a deployment for the whole repository unless the workflow targets modified directories, and repository access is not scoped per component.

• DState for every directory must live in one state file for the repo

  Incorrect

  Each root module in a monorepo still has its own state.

If a monorepo is required, HCP Terraform and Terraform Enterprise can scope each workspace to a directory of the repository.

• AOnly the app/ directory that the command runs in

  Incorrect

  With a combined repository and workspace working directories, the upload is not limited to the directory you run from.

• Bapp/ plus the local modules it calls by path

  Incorrect

  Terraform does not work out which files a configuration needs; it uploads the combined configuration directory.

• COnly the files changed since the last run

  Incorrect

  CLI-driven runs upload an archive of the configuration directory, not a diff.

• DThe entire combined configuration directory

  Correct

  Whether you run from the real working directory or the root of the combined configuration directory, Terraform uploads the entire combined configuration directory.

In a large monorepo every CLI-driven run uploads everything, so keep large unrelated files out of the configuration directory or exclude them from the upload.

• ATerraform loads only the newest file in the directory

  Incorrect

  Terraform loads all configuration files in a directory.

• BIt fails with duplicate declarations from the merged files

  Correct

  Terraform appends every file in the directory together, so resources with the same name collide.

• Cprod.tf overrides dev.tf as the later file alphabetically

  Incorrect

  Ordinary files are not override files, so neither one replaces the other.

• DTerraform creates two separate states, one per file

  Incorrect

  State belongs to the working directory, not to each file.

Separate environments into their own directories or workspaces instead of adding parallel files to one directory.