The most detailed free FDE + DevOps library: 140+ lessons, 70+ labs and 80 long-form articles, in English and Turkish. Start learning →

DevOps Practitioner · Module 4: Infrastructure as Code

Lifecycle Rules That Stop Surprises

Lifecycle rules are seatbelts for infrastructure: they turn classes of accidents into errors at plan time. Combined with validation and checks, they make the dangerous plans fail before they run.

10 min reading

Objectives

  • Explain what prevent_destroy, create_before_destroy and ignore_changes do
  • Stop an unexpected destroy plan with the right lifecycle rule
  • Use targeted testing (validate, plan checks) before apply
  • State the limit: local provider work never proves real cloud behavior

Why this matters

A variable rename looks harmless; the plan replaces the stateful resource because the new name means a new object. Nobody reads that far into the plan on a Friday, apply runs, and the data is gone. Lifecycle rules exist for exactly this Friday: prevent_destroy would have failed the plan with an error instead of a quiet replacement, and the rename would have become a proper migration. The rule costs one block; the incident costs the data.

Concepts

Three rules cover most accidents. prevent_destroy fails any plan that would destroy the resource, forcing an explicit removal of the rule (a reviewable act) before destruction. create_before_destroy reverses the default replacement order for resources that must never gap (a new object first, then the old one retires). ignore_changes tells the tool to stop fighting over attributes managed elsewhere (tags by a cost tool, passwords by rotation); overuse hides real drift, so each ignored attribute needs a named owner outside the code.

Testing stacks in layers. Validate catches syntax and type errors without credentials. Plan with saved output is the review artifact. Policy checks (constraint libraries appropriate to the setup) reject forbidden shapes at plan time. None of this requires a cloud account: local fixtures run the whole stack, and the L34-L36 labs stay local on purpose.

The honesty limit is printed on the module: everything proved with local or container providers demonstrates workflow, state discipline and safety habits, and demonstrates nothing about real cloud behavior: no IAM, no real networking, no actual bills, no provider quirks. Graduates carry habits to the cloud; they do not carry claims about it.

Worked example

A fixture stateful resource gains prevent_destroy; a renaming edit plans destruction and the tool errors instead of proposing. The learner quotes the error, performs the deliberate migration path (rule lifted in review, state moved, rule restored), and the next plan is clean. The error text is the deliverable: proof the seatbelt engaged.

Common wrong move

Sprinkling ignore_changes to silence every diff instead of reconciling drift. The plans go quiet while reality diverges, and the quiet lasts until the divergence matters. Ignore only named external owners; adopt or revert everything else.

Quick check

An optional 4-question self-check. Answers never leave your device, are not stored, and never count toward any assessment.

Lesson feedback

No published feedback yet.

Log in and complete the lesson to leave feedback.

Exercise

On local fixtures, set prevent_destroy on a stateful resource, stage a renaming edit, quote the plan error, and complete the deliberate migration path.

Pass criteria

The record shows the plan error quoting the rule, the reviewed migration steps, and the clean plan after with the rule restored.

Sources

Log in to track progressFree account: stores only your lesson progress and quiz results.