Cause drift, detect it, and decide what to do about it

short · 45 min · Objective 2.2

Task

Make a change outside the code, discover it the way a scheduled plan would, and then take both possible decisions -- revert and adopt -- so you have done each once.

Steps

  1. Apply a small environment from code and confirm a second apply reports no changes.
  2. Change something by hand outside the tool -- rename a container, change a label, alter a file the template manages.
  3. Run plan WITHOUT applying, and save the output to lab/drift-plan.txt -- tofu plan -no-color > lab/drift-plan.txt (or terraform): both colour their output even into a file, and the escape codes break the Verify's line matching. Record which resource it wants to change and whether it says update or REPLACE.
  4. Apply, confirm the manual change was reverted, and write in lab/decisions.md what this proves about an emergency fix made in a console at 2am.
  5. Now make a second manual change that is actually CORRECT, update the code to match it instead, and confirm plan is empty. Record that as the adopt decision.

Verify

grep -c '^Plan: ' lab/drift-plan.txt                     # must be 1
grep -ci 'no changes' lab/drift-plan.txt                 # must be 0
grep -Eo 'will be updated in-place|must be replaced' lab/drift-plan.txt
grep -Eci 'revert' lab/decisions.md
grep -Eci 'adopt' lab/decisions.md

The first two lines prove the plan SAW your manual change: a plan with nothing to do prints "No changes." and no Plan: line -- and still contains the word "change", so grepping for that word cannot tell the two apart. The third says whether the fix is an update or a replacement. Both decisions must be recorded. Drift left undecided is the state that causes the surprise, because the next apply decides for you.

This is an independent study companion for CompTIA Cloud+ CV0-004 and is not produced by or endorsed by CompTIA.