Terraform state management

A configuration using the default local backend provisions a database whose randomly generated password is exposed as an output. A reviewer asks whether the password is protected at rest in the state file. What should the practitioner tell them?

resource "random_password" "db" {
  length = 20
}
output "db_password" {
  value     = random_password.db.result
  sensitive = true
}

• AMarking the output 'sensitive = true' encrypts the value inside terraform.tfstate, so it is protected at rest.
• BThe password never reaches state because 'random_password' keeps generated secrets only in provider memory.
• CThe local backend hashes all output values before writing them, so only an irreversible digest is stored.
• DThe value is stored as plaintext in terraform.tfstate, so the file must be treated as a secret and access to it restricted.check_circle Correct

Why A is wrong: The 'sensitive' flag only hides the value from CLI output; it does not encrypt anything written to state, so this overstates its effect.

Why B is wrong: Resource attributes, including generated passwords, are always persisted to state so Terraform can detect drift, so this is incorrect.

Why C is wrong: The local backend performs no hashing of values; it records real attribute values verbatim, so no irreversible digest is produced.

Why D is correct: The local backend writes state as plaintext JSON, so the generated password appears in clear text and the file itself must be guarded.

You renamed a resource block from aws_s3_bucket.logs to aws_s3_bucket.audit_logs. The bucket already exists and holds production data. You want a plan that shows no changes after the rename. Which command reconciles the state so Terraform tracks the existing bucket under the new address?

# before: resource "aws_s3_bucket" "logs" { ... }
# after:  resource "aws_s3_bucket" "audit_logs" { ... }

• Aterraform state rm aws_s3_bucket.logs, then re-run apply so Terraform imports the bucket under the new name automatically.
• Bterraform state mv aws_s3_bucket.logs aws_s3_bucket.audit_logs to move the existing state entry to the new address.check_circle Correct
• Cterraform apply -replace=aws_s3_bucket.audit_logs to align the new address with the running bucket.
• Dterraform taint aws_s3_bucket.logs so Terraform re-registers the bucket under audit_logs on the next apply.

Why A is wrong: state rm only forgets the resource; a following apply would try to create a brand-new bucket and clash with the existing one rather than adopting it.

Why B is correct: state mv rebinds the existing state object to the renamed address without touching the real bucket, so the next plan shows no changes.

Why C is wrong: The -replace flag forces destroy-and-recreate of the resource, which would delete the production bucket and its data rather than simply renaming the state entry.

Why D is wrong: taint is deprecated and marks a resource for recreation, not renaming; it would schedule destruction of the bucket and never reconciles a changed address.

Before running a plan you want to update Terraform's state to match the real infrastructure and see which resources have drifted, but you must not propose or apply any configuration changes. Which command achieves exactly this in Terraform 1.x?

$ terraform ____

• Aterraform refresh, because it is the actively recommended command for updating state without side effects.
• Bterraform plan -refresh=false to compare state to reality while skipping any changes.
• Cterraform import for each resource to pull current values back into the state file.
• Dterraform apply -refresh-only to reconcile state with real infrastructure and report drift without changing resources.check_circle Correct

Why A is wrong: The standalone terraform refresh command still exists but is deprecated; HashiCorp now steers practitioners to the refresh-only plan and apply modes instead.

Why B is wrong: Setting -refresh=false does the opposite of what is wanted: it skips the refresh entirely, so drift is not detected and state is not updated.

Why C is wrong: import brings unmanaged resources under management one address at a time; it is not a way to refresh already-managed resources or to report drift across the state.

Why D is correct: The refresh-only apply updates the state file to match live infrastructure and surfaces drift, while proposing no changes to the resources themselves.

A team currently keeps Terraform state in a local file and wants to move to an S3 backend so the whole team shares one state. After adding the backend configuration shown, what must the practitioner do for Terraform to start using it, and what happens to the existing local state?

terraform {
  backend "s3" {
    bucket = "acme-tfstate"
    key    = "prod/terraform.tfstate"
    region = "eu-west-1"
  }
}

• ARun terraform init; Terraform detects the new backend and offers to migrate the existing local state to S3.check_circle Correct
• BRun terraform apply; the backend block takes effect on the next apply and the local state is uploaded automatically.
• CRun terraform plan; planning re-reads the configuration and silently switches the backend without touching the old state.
• DManually copy terraform.tfstate into the S3 bucket first, because init refuses to move an existing local state.

Why A is correct: Correct: a backend change is only picked up by terraform init, which prompts to copy the current local state into the new backend so nothing is lost.

Why B 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.

Why C is wrong: Plausible because plan reads the whole configuration, but plan never changes backends or infrastructure, and it does not migrate state.

Why D is wrong: This sounds safe but is wrong: init handles the migration for you and prompts before copying, so a manual upload is unnecessary and risks a mismatched lineage.

An engineer notices that state locking behaves differently depending on how state is stored. Which statement most accurately describes when Terraform can lock state?

• ALocking depends on the backend, and it is available only where the backend supports it, so some backends offer no locking at all.check_circle Correct
• BLocking is always applied identically regardless of backend, because Terraform itself owns the lock rather than the backend.
• CLocking is available only when using the local backend, since remote backends cannot coordinate a shared lock.
• DLocking works for every remote backend but is unavailable for the local backend under any circumstances.

Why A is correct: Correct: locking is a backend feature, so whether and how state is locked is determined by the configured backend.

Why B is wrong: Tempting because locking feels like core behaviour, but the locking mechanism is provided by the backend, so support varies.

Why C is wrong: Tempting but reversed: remote backends such as S3 with a lock table and HCP Terraform are exactly where robust locking is provided.

Why D is wrong: Tempting because remote backends are associated with locking, but the local backend does lock the on-disk file during operations.