Recover missing state ownership under verified lock evidence
A hands-on TERRAFORM-004 lab. You produce the real artefact and 10 automated checks verify it behaves the way the exam expects.
Try this labAll TERRAFORM-004 practice
- Certification
- TERRAFORM-004
- Format
- Structured configuration
- Difficulty
- hard
- Estimated time
- 40 min
- Automated checks
- 10
The brief
Edit recovery.runbook.json. A command is {argv:[...]}; terraform state pull also needs saveAs with a distinct .tfstate backup name. First run inspect lock and inspect state. A guard is {when:"${...}", otherwise:"stop", steps:[...]}. Read fields are evidence.workspace, ownerStatus, heartbeatExpired, lockId, currentLineage, snapshotLineage, currentSerial and snapshotSerial. Conditions support literals, comparisons, Boolean operators and contains; unknown references/functions fail. Require payments/dev, stopped owner, expired heartbeat and matching lineages before mutation; live owner, foreign workspace and foreign snapshot probes must stop. Save current state before force actions; last-good.tfstate is read-only. Unlock with terraform force-unlock -force stale-job-lock. One route restores last-good.tfstate with terraform state push -force after verifying compatible lineage and known serial regression. Another imports service-existing at terraform_data.service, plans -out=recovery.plan, reviews recovery.plan, then applies recovery.plan to initialize approved-payload. Import starts with null input: review its expected update, with no creation/deletion. Keep audit-existing/security-log at terraform_data.audit unchanged and exactly these two bindings. Finish with terraform plan -detailed-exitcode after the final write and no remaining actions. Supported argv forms are inspect lock/state; terraform state pull with saveAs; terraform force-unlock -force <id>; terraform state push [-force] <file.tfstate>; terraform import <terraform_data.address> <id>; terraform state rm <address> (forgets ownership); terraform plan -out=recovery.plan; review recovery.plan; terraform apply recovery.plan; terraform plan -detailed-exitcode. Commands only rehearse fixture consequences. Inspect trace, ownershipProbes, lineageProbe, backups and remainingActions. Repair normally without Reset.
What the checks verify
Your work is graded on 10 independent properties, not on matching one reference answer.
- Use supported bounded command records and executable guarded steps.
- Read both lock ownership evidence and state/snapshot metadata before recovery.
- Stop without mutation for a live owner or another workspace.
- Stop without mutation when the supplied recovery snapshot has another lineage.
- Save the current state under a distinct backup name before unlock or state writes.
- Unlock only the verified stale-job-lock on the intended workspace.
- Restore exactly the requested service and audit IDs with their approved inputs.
- Keep the existing audit ID and security-log input unchanged.
- Review any saved initialization plan before applying it.
- After the final write, run detailed-exitcode plan and reach zero remaining actions.
Where this sits in the TERRAFORM-004 blueprint
- Domain
- Terraform state management
- Objective
- Collaborative State
- Skill
- Backend Configuration and Locking
Part of TERRAFORM-004 preparation
Labs are written by ExamNova to teach the decisions the exam tests. They are not reproductions of vendor lab content.