Terraform / Sensitive data, governance, and recovery / Lesson 18

Deletion, forgetting, and recovery tradeoffs

Distinguish source reversal, state restoration, object recovery, and deliberate removal from management.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain why rollback is another reviewed change rather than a universal undo.
Compare destruction with supported removal from management and retained ownership duties.

Reverting source does not restore every external effect

Infrastructure changes can alter immutable identities, migrate data, change access, or delete information that cannot be recreated from configuration alone. Reverting a source commit produces another desired configuration; the resulting actions still depend on current state, provider behavior, and real objects. It is not a general undo transaction. Provider upgrades and state schema evolution can also constrain downgrade or recovery paths. Plan rollback, forward correction, and data restoration separately before adopting a sensitive transition, and establish who can authorize each path.

Leaving management is not the same as deletion

Terraform supports removed blocks for supported configuration-driven removal from state. The following independent fixture describes forgetting a prior terraform_data.legacy binding with destroy=false. That built-in resource has no external cloud object; the example illustrates the language’s ownership transition only. For a real provider resource, leaving an object in place still leaves operational cost, access, data, and eventual cleanup responsibilities. Do not remove the current declaration or binding merely to hide an unexplained plan. Deliberate ownership transfer needs a documented recipient and verification.

hcl Complete illustrative removal-from-management declaration

terraform {
  required_version = ">= 1.16.0, < 1.17.0"
}

removed {
  from = terraform_data.legacy
  lifecycle {
    destroy = false
  }
}

The address refers to an assumed prior binding and should not remain simultaneously declared as a managed resource in this fixture. The block is not executed and no state is read or changed. This does not constitute a backup, an import, or proof that cleanup responsibilities disappeared.

State recovery and data recovery answer different questions

A state backup can preserve bindings and stored attributes, but cannot by itself restore a deleted database, file contents, or external business action. Restoring an older snapshot without reconciling real objects can overwrite useful progress or reintroduce incorrect ownership assumptions. A data backup needs its own consistency, retention, encryption, version compatibility, and restore evidence. Define recovery point and recovery time objectives for the actual service, including required keys and dependencies, instead of treating the existence of any backup file as an operational guarantee.

Recovery facts produce review requirements, not automatic repair

The offline fixture below lists missing prerequisites in a fictional incident. It performs no restoration and does not decide whether a destructive action is authorized. A real incident requires trusted diagnostics, ownership, state lineage and version context, provider-specific semantics, and approved recovery steps. Treat the resulting labels as questions for the responsible owner. They are deliberately not commands, and they do not imply that reconstructing an identity or restoring data is always possible from the evidence available.

python List review prerequisites from a synthetic incident

facts = {'state_target_verified': False, 'object_present': False, 'restore_rehearsed': False}
reviews = []
if not facts['state_target_verified']:
    reviews.append('state_target')
if not facts['object_present']:
    reviews.append('object_recovery')
if not facts['restore_rehearsed']:
    reviews.append('restore_readiness')
print('required_reviews=' + ','.join(reviews))

Expected output

required_reviews=state_target,object_recovery,restore_readiness

All three fixed facts are false, so all review labels appear in declared order. No state, backup, object, credential, or Terraform command is accessed. The model does not execute a recovery procedure or promise a recoverable outcome.

Sensitive removals require deliberate ownership and verification

Review the complete proposed removal set, dependencies, retained data, access revocation, external references, and the responsible owner after management ends. prevent_destroy is one configuration-level guard, not an independent permanent backup policy. A successful destruction operation does not prove every external copy or secret was removed, and a failed operation may still have partially succeeded. Preserve redacted evidence and verify the approved end state. This course executes no deletion, forgetting, import, unlock, backend migration, state restoration, or cloud operation.

Common errors and fixes

Reverting a commit is expected to recover deleted data.

Why it happens: Configuration intent was confused with retained application contents and irreversible effects.
How to fix it: Follow the separate reviewed object and data recovery plan.
Prevent it next time: Rehearse recovery and define irreversible boundaries before change.

An old state snapshot is restored without reconciliation.

Why it happens: Stored bindings were assumed to match current reality automatically.
How to fix it: Establish actual objects, lineage, version, ownership, and approved recovery scope.
Prevent it next time: Protect state history and document supported restoration procedures.

Forgetting an object is treated as completed cleanup.

Why it happens: State removal was confused with remote deletion and responsibility transfer.
How to fix it: Assign the remaining owner and verify the intended object and access state.
Prevent it next time: Track retained resources and their future lifecycle explicitly.

Check your understanding

1. Does destroy=false in a removed block restore the object from backup?

Show worked solution

No. It describes a supported removal-from-management behavior and does not reconstruct data or create a backup. For real resources, the object can remain outside that state’s management and still need an owner. Review the exact lifecycle transition and retained responsibilities before adoption.

2. Why is a state backup insufficient evidence for a service RTO?