{"id":8309,"date":"2026-11-08T22:10:00","date_gmt":"2026-11-08T22:10:00","guid":{"rendered":"https:\/\/www.devopsconsulting.in\/blog\/?p=8309"},"modified":"2026-11-08T22:10:00","modified_gmt":"2026-11-08T22:10:00","slug":"declared-vs-running-primer","status":"publish","type":"post","link":"https:\/\/www.devopsconsulting.in\/blog\/declared-vs-running-primer\/","title":{"rendered":"Configuration Drift for Beginners: A Primer With a Mini-Glossary"},"content":{"rendered":"

When a company brings in outside help for a digital transformation, one of the first discoveries is usually uncomfortable. The written description of the environment, the diagrams, the wiki pages, the infrastructure code, no longer matches what is actually running. Consultants have a name for the gap: configuration drift<\/strong>. This primer explains how drift arises, why a regular comparison of “declared” against “observed” state is the cheapest remedy, and gives you a short glossary so the vocabulary stops being a barrier.<\/p>\n

The core idea in one paragraph<\/h2>\n

Every environment has two descriptions. One is what people intended: the templates, the pipeline definitions, the approved change tickets. The other is what exists: the servers answering requests, the settings on each of them, the accounts that can log in. Over time the two diverge, mostly through small, well-meant actions. Reconciliation is simply the act of putting both descriptions side by side on a regular schedule and resolving every difference.<\/p>\n

How drift appears, step by step<\/h2>\n
    \n
  1. An engineer fixes a production problem by editing a setting directly, intending to update the code afterwards.<\/li>\n
  2. The urgent matter passes and the follow-up slips.<\/li>\n
  3. Months later a rebuild from code quietly reverses the fix, and the original problem returns.<\/li>\n<\/ol>\n

    The same story plays out with firewall rules opened for a test and never closed, test servers that outlive their projects, and temporary accounts that become permanent. None of it is negligence. It is what happens when change is fast and records are slow.<\/p>\n

    Why the gap costs more the longer it sits<\/h2>\n

    Evidence from consulting engagements points the same way again and again. A difference found within days usually has one author, one reason, and a one-line fix. A difference found after a year is entangled with later changes, and nobody remembers who touched what. Cost grows with age, so frequency of comparison matters more than sophistication of tooling. A crude weekly check beats an elegant annual one.<\/p>\n

    Three reasons a fixed rhythm works<\/h3>\n