TF-Associate-004 - Terraform state management (11% of the exam) - Section 6c
Configure remote state using the backend block.
A backend block inside terraform configures remote state (for example S3, or HCP Terraform via cloud), giving shared state and locking. Candidates should know changing the backend requires terraform init and that Terraform can migrate existing state.
backend blockremote stateshared state and lockingstate migration on init
Practice question for this objective
lock_openFree sampleTerraform state managementmedium
A practitioner wants to move an existing project from a local backend to HCP Terraform for remote state and remote runs. Which configuration block belongs inside the terraform block to connect the working directory to an HCP Terraform workspace?
terraform {
# which block goes here?
}
AA backend "remote" block pointing at app.terraform.io, since that is the only supported way to reach HCP Terraform.
BA backend "cloud" block, because every remote integration is declared as a named backend.
CA cloud block naming the organisation and the workspace to use in HCP Terraform.check_circle Correct
DA provider "tfe" block configured with the organisation token and workspace name.
HCP Terraform is connected via the cloud block inside the terraform block, not a backend block. HCP Terraform integration is declared with a dedicated cloud block that names the organisation and workspace. It is distinct from a backend block, and it enables remote state storage and remote execution once init runs.
Why A is wrong: Tempting because the remote backend was the older approach and still works, but it is no longer the recommended way; the cloud block is the current integration.
Why B is wrong: Plausible by analogy with backend "s3", but there is no backend named cloud; HCP Terraform uses a top-level cloud block, not a backend block.
Why C is correct: Correct: HCP Terraform is configured with the cloud block, which names the organisation and workspace and enables remote state and runs after init.
Why D is wrong: This confuses managing HCP Terraform resources with connecting to it; the tfe provider manages settings via the API but does not wire state to a workspace.
Answers that look right on this material and are not. Each one is a distractor from a different question in the TF-Associate-004 bank for this domain.
Run terraform apply, which recreates all resources against the new empty remote state.
errorWhy it is wrong: This is tempting because apply is the usual way to change infrastructure, but changing a backend is an initialisation concern, and apply would not migrate state; assuming recreation also misreads how state works.
Run terraform apply; the backend block takes effect on the next apply and the local state is uploaded automatically.
errorWhy it is wrong: Tempting because apply writes state, but a backend change is not initialised by apply. Terraform will error asking you to run init before any apply.
Inside the provider block for the service that stores the state.
errorWhy it is wrong: This is tempting because the state often lives in a cloud service that also has a provider, but backend configuration is independent of any provider block and is not read from it.