Task 6.3: Configure remote state using the backend block

• AUse a local value for the bucket name instead of an input variable in the backend block

  Incorrect

  A backend block cannot refer to any named values, including locals.

• BSet TF_VAR_state_bucket, which backend blocks can read

  Incorrect

  Backend blocks cannot use input variables, however they are set.

• CPut the bucket name in a .tfvars file, which init reads for the backend

  Incorrect

  Variable definition files set input variables, which backend blocks cannot use.

• DOmit bucket and pass it with init -backend-config="bucket=..."

  Correct

  Omitting arguments gives a partial configuration; the remaining values can be passed to init as key/value pairs.

• EKeep settings in a file per environment and pass it with -backend-config

  Correct

  A file of backend settings can be passed to init with -backend-config=PATH to complete a partial configuration.

Backend settings are read before variables exist; supply the varying parts at init time with partial configuration.

• Aterraform init -migrate-state, then confirm the copy when prompted

  Correct

  When the backend changes, init with -migrate-state copies the existing state to the new backend, with prompts to confirm.

• Bterraform apply, which uploads local state the first time it runs

  Incorrect

  The backend must be initialized by init before any apply.

• Cterraform state push terraform.tfstate before running init

  Incorrect

  The new backend must be initialized first, and init handles copying the state.

• Dterraform init -reconfigure, which copies the state while it reconfigures

  Incorrect

  -reconfigure ignores the existing configuration and does not migrate state.

Change the backend block, then init -migrate-state. Back up the local state file first.

• AYes; any provider can act as a backend

  Incorrect

  Providers manage resources; they are not backends.

• BNo; backends are built in and cannot be plugins

  Correct

  Terraform ships with several built-in backend types, and you cannot load additional backends as plugins.

• CYes; backends are downloaded and installed by init like providers are

  Incorrect

  init configures built-in backends; it does not download them.

• DYes, but only in HCP Terraform

  Incorrect

  HCP Terraform manages state itself, and backends are never plugins.

Choose among built-in backends; custom storage goes behind one of them.

• AInside the provider block of the storage provider

  Incorrect

  Backends are not configured in provider blocks.

• BAs a top-level block next to resources

  Incorrect

  backend is always nested in terraform.

• CNested inside the top-level terraform block

  Correct

  To configure a backend, add a nested backend block within the top-level terraform block.

• DIn the CLI configuration file

  Incorrect

  The CLI configuration does not define backends.

terraform { backend "<type>" { … } }.

• AThe backend block's arguments, written as top-level settings

  Correct

  A backend configuration file has the contents of the backend block as top-level attributes.

• BA full terraform block with the backend block nested inside it, as in main.tf

  Incorrect

  The file holds only the backend's arguments.

• CA JSON list of backend names to try in order

  Incorrect

  There is no fallback list of backends.

• DThe state data to upload during init

  Incorrect

  The file configures the backend; it is not state.

Backend config files are just backend arguments, without the block around them.

• ANothing; Terraform switches back to local state silently on the next plan

  Incorrect

  A backend change requires reinitialization.

• Bterraform destroy, because local state cannot hold remote resources

  Incorrect

  Local state can track any resources.

• Cterraform force-unlock

  Incorrect

  force-unlock releases a stale state lock; it does not change backends.

• Dterraform init, which can copy the state back

  Correct

  When you change backends, including removing one, you must run init again, and Terraform offers to migrate the state.

Any backend change, in either direction, goes through init.

• AThe block's region, because settings written in configuration files beat options

  Incorrect

  Command-line options override the backend block.

• BWhatever common.hcl says, because files beat key/value pairs

  Incorrect

  Later options override earlier ones regardless of form.

• Ceu-west-1, as later command-line options win

  Correct

  Backend settings are merged; command-line options override the main configuration and are processed in order.

• DNone; init rejects duplicate settings

  Incorrect

  Duplicates are merged by the documented rules.

For backend settings: block first, then each -backend-config in order.