Skip to content
Cheat sheets

004 · Domain 6: Terraform state management · 13% of the exam

Task 6.2: Describe state locking

Locking that stops two runs from writing the same state: which operations lock, backends that support it, -lock-timeout, and force-unlock as a last resort.

Study it

Sample questions

Try each one before opening the answer. Every option is explained, with the HashiCorp documentation page that proves it.

Question 1 · choose 1

A team using a backend that supports locking asks whether they must acquire the state lock themselves before running terraform apply. What is the answer?

  1. AYes; they must run terraform force-unlock -lock before each apply
  2. BYes; they must add a lock block to the terraform block of the configuration
  3. CNo, because state locking only applies to terraform destroy operations
  4. DNo; it is locked automatically for operations that could write it
Show the answer and why

  • AYes; they must run terraform force-unlock -lock before each apply

    Incorrect

    force-unlock removes a lock; nobody runs it to take one.

  • BYes; they must add a lock block to the terraform block of the configuration

    Incorrect

    There is no lock block; locking is a backend feature used automatically.

  • CNo, because state locking only applies to terraform destroy operations

    Incorrect

    Every operation that could write state is locked, not just destroy.

  • DNo; it is locked automatically for operations that could write it

    Correct

    State locking happens automatically on all operations that could write state, without any message unless acquiring the lock takes a while.

Locking is automatic and silent; you notice it only when someone else holds the lock.

HashiCorp documentation

Task 6.2Report a problem with this question

Question 2 · choose 1

A CI job was killed during an apply, and every later run fails because the state is still locked. The team has confirmed that nothing else is running against this state. What should they do?

  1. ARun terraform force-unlock with the lock ID shown in the error
  2. BWait for the lock to expire, which happens one hour after it was taken
  3. CDelete the state file in the backend and run apply again
  4. DRun terraform init -reconfigure, which clears any locks on the state
Show the answer and why

  • ARun terraform force-unlock with the lock ID shown in the error

    Correct

    force-unlock removes a lock by its unique ID; use it only for your own lock when automatic unlocking failed.

  • BWait for the lock to expire, which happens one hour after it was taken

    Incorrect

    Terraform state locks are not released on a timer; a stale lock stays until it is removed.

  • CDelete the state file in the backend and run apply again

    Incorrect

    Deleting state throws away Terraform's record of what it manages, which is far worse than a stale lock and never the way to clear one.

  • DRun terraform init -reconfigure, which clears any locks on the state

    Incorrect

    -reconfigure changes backend settings handling; it does not release locks.

force-unlock is a last resort for a lock you know is abandoned; the lock ID makes sure you remove the right one.

HashiCorp documentation

Task 6.2Report a problem with this question

Question 3 · choose 1

What problem does state locking solve?

  1. APeople changing the managed resources by hand in the cloud console
  2. BProviders being upgraded unexpectedly
  3. CTwo runs writing the same state at once
  4. DSensitive values appearing in plan output
Show the answer and why

  • APeople changing the managed resources by hand in the cloud console

    Incorrect

    Terraform cannot lock remote objects against manual changes.

  • BProviders being upgraded unexpectedly

    Incorrect

    That is what the dependency lock file prevents.

  • CTwo runs writing the same state at once

    Correct

    Locking prevents others from acquiring the lock and potentially corrupting state during operations that could write it.

  • DSensitive values appearing in plan output

    Incorrect

    That is handled by sensitive values.

State locks protect the state file, not the infrastructure.

HashiCorp documentation

Task 6.2Report a problem with this question

Question 4 · choose 1

A user notices that terraform apply never mentions locking. Does that mean the state was not locked?

  1. AYes; Terraform always prints a lock line when it locks
  2. BYes; locks are taken only with the -lock=true option
  3. CNo; but the lock is only taken after the apply finishes
  4. DNo; locking is silent unless the lock takes a while
Show the answer and why

  • AYes; Terraform always prints a lock line when it locks

    Incorrect

    There is no message in the normal case.

  • BYes; locks are taken only with the -lock=true option

    Incorrect

    Locking is the default for operations that write state.

  • CNo; but the lock is only taken after the apply finishes

    Incorrect

    The lock protects the whole operation.

  • DNo; locking is silent unless the lock takes a while

    Correct

    Locking happens automatically without a message; Terraform prints a status message only if acquiring the lock takes a while.

You see locking only when it makes you wait.

HashiCorp documentation

Task 6.2Report a problem with this question

Question 5 · choose 1

A team stores state in Azure Blob Storage with the azurerm backend. How is the state locked?

  1. AIt is not locked; the azurerm backend leaves locking to the team
  2. BThe backend locks it with Azure Blob Storage's native capabilities
  3. CIt needs a separate Azure Table storage table for the lock records
  4. DThrough a file on the local disk of the machine running Terraform
Show the answer and why

  • AIt is not locked; the azurerm backend leaves locking to the team

    Incorrect

    The azurerm backend documentation lists state locking among its features.

  • BThe backend locks it with Azure Blob Storage's native capabilities

    Correct

    The azurerm backend supports state locking and consistency checking using Azure Blob Storage native capabilities.

  • CIt needs a separate Azure Table storage table for the lock records

    Incorrect

    No extra table is involved; the azurerm backend locks with Azure Blob Storage itself.

  • DThrough a file on the local disk of the machine running Terraform

    Incorrect

    A lock on one machine's disk would not stop runs started from other machines.

For azurerm, locking is built in: the backend uses Azure Blob Storage's own capabilities.

HashiCorp documentation

Task 6.2Report a problem with this question

Question 6 · choose 1

An apply fails half way with a provider error. What does Terraform do with the state lock before exiting?

  1. AIt keeps the lock in place until someone runs force-unlock on it
  2. BIt deletes the state to avoid inconsistency
  3. CIt saves the changes made, unlocks state and exits
  4. DIt holds the lock for one hour, then releases it
Show the answer and why

  • AIt keeps the lock in place until someone runs force-unlock on it

    Incorrect

    Terraform releases the lock on a normal error exit.

  • BIt deletes the state to avoid inconsistency

    Incorrect

    State is updated, never deleted.

  • CIt saves the changes made, unlocks state and exits

    Correct

    On an apply error, Terraform reports the error, updates the state file with any changes, unlocks the state and exits.

  • DIt holds the lock for one hour, then releases it

    Incorrect

    Locks are not timed.

Errors release the lock; only a crashed or killed process leaves one behind.

HashiCorp documentation

Task 6.2Report a problem with this question

Question 7 · choose 1

While an apply holds the state lock, can a colleague still change the managed resources in the cloud console?

  1. AYes; the lock covers Terraform's state, not the remote objects
  2. BNo; Terraform locks every resource in the cloud during apply
  3. CNo; the provider rejects console changes while the lock is held
  4. DOnly if the colleague uses the same credentials
Show the answer and why

  • AYes; the lock covers Terraform's state, not the remote objects

    Correct

    State locking stops other Terraform runs from writing the same state; it cannot block changes made outside Terraform.

  • BNo; Terraform locks every resource in the cloud during apply

    Incorrect

    Terraform has no way to lock remote objects.

  • CNo; the provider rejects console changes while the lock is held

    Incorrect

    Providers do not enforce Terraform's lock.

  • DOnly if the colleague uses the same credentials

    Incorrect

    Credentials do not matter to the state lock.

Locks coordinate Terraform runs; they do not freeze infrastructure.

HashiCorp documentation

Task 6.2Report a problem with this question

Practise domain 6 →Practise all domains →