Infrastructure as Code assumes that the code is the single source of truth for what exists in the cloud. In practice, engineers under pressure make manual console changes, emergency fixes bypass the pipeline, and over time the live environment quietly diverges from what the code describes. This gap is called drift, and it is dangerous because scans of your Terraform files can look perfectly clean while the actual running infrastructure is not what anyone believes it to be.
Analogy🏏Cricket
🎮 Think of it like gaming: a co-op team plays off a shared strategy board that says exactly where every player should stand. But mid-match someone quietly repositions without updating the board, and now the written plan and the actual battlefield disagree. Anyone reading the plan believes the formation is intact while a hole has silently opened on the map. Infrastructure drift is precisely this gap: engineers make manual console changes that never reach the code, so a scan of your Terraform files reads perfectly clean while the live cloud has quietly shifted. This reveals why a spotless config scan can coexist with an environment nobody actually understands.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.
Drift matters for security specifically because a manual change can silently disable a control the code intended to enforce. Someone might open a port during an incident and forget to close it, or widen a bucket's permissions to unblock a script and never revert it. Since that change never touched version control, none of the scanners from earlier lessons ever see it, leaving a real, live vulnerability that no static Terraform scan will ever catch.
Analogy🏏Cricket
🎵 Think of it like music: an orchestra tunes carefully before the concert, but if one violinist nudges a peg during the interval, the written score still looks flawless while the live sound has gone sharp. Read the sheet music all night and you will never find the fault — it exists only in the room, not on the page. A manual change that opens a port during an incident or widens a bucket's permissions is that untuned string: it never touches version control, so every static scanner reading the code stays silent while a real, audible vulnerability plays on. This reveals why security gaps can live entirely outside anything a code scan can hear.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.
Under the hood, drift detection tools periodically compare the actual state of cloud resources against the state Terraform believes should exist, flagging every mismatch as a discrepancy to investigate. Some tools go further, continuously polling cloud APIs and comparing live configuration directly against compliance benchmarks, independent of whether Terraform is even involved, catching drift introduced by any tool or console action rather than only changes made outside a specific IaC pipeline.
Analogy🏏Cricket
📷 Think of it like photography: to catch what has changed in a scene, you lay last week's print beside today's shot and compare them frame against frame — any object that moved jumps straight out. Some studios go further, running a live feed continuously against a fixed reference image so a change is spotted the moment it happens, whatever caused it. Drift detection works this way: tools periodically compare the live cloud against the state Terraform expects, while continuous-compliance tools poll cloud APIs against benchmarks regardless of how the change arrived. This reveals why comparing live reality to a trusted reference is the only way to see drift.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.
bash
# Detect drift between live cloud state and Terraform's expected stateterraformplan-detailed-exitcode# exit 0 -> no changes (no drift)# exit 2 -> drift detected; review the diff before deciding next steps# Scheduled drift check (example cron-style CI job)# runs `terraform plan` nightly and alerts if exit code == 2
Analogy🏏Cricket
🏏 Think of it like cricket: drift is a fielder who quietly drifts out of position between overs, while every eye in the ground is fixed on the bowler running in. The scorecard and the agreed field setting both still insist he is stationed at cover, yet he has wandered halfway to mid-wicket without a word. Nobody notices the gap until a firm shot races straight through the space he abandoned and the runs are already gone. Regular drift checks are the captain deliberately glancing around the field at the top of every over to confirm the live setting still matches the plan. This reveals why you must re-verify reality on a schedule, not assume it held.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.
Best practice runs drift detection on a schedule, not only when someone remembers to check, and treats every detected drift as an incident requiring investigation rather than a routine notification to dismiss. Where possible, remove console access for production resources entirely so all changes must flow through the pipeline, and when a manual emergency change is unavoidable, follow up immediately by codifying it in Terraform so the source of truth catches up with reality.
Analogy🏏Cricket
✈️ Think of it like travel: an airline doesn't inspect an aircraft only when a pilot happens to feel uneasy — checks run on a fixed schedule, any anomaly is treated as a reportable incident rather than shrugged off, and access to the controls is tightly restricted so no one adjusts a system off the books. If an emergency repair is ever made on the tarmac, it is logged into the maintenance record immediately afterward. Scheduled drift detection, treating each drift as an incident, locking down console access, and codifying emergency changes into Terraform follows the same regime. This reveals why safety comes from routine verification, not memory.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.
In the real world, a nightly drift check might reveal that a database's public access flag was manually flipped on during a late-night debugging session and never reverted. Without continuous compliance checking, that exposure could persist for months, invisible to every code-level scan. Catching it the next morning turns a prolonged, unnoticed exposure into a same-day fix, closing the gap between what the code promises and what the cloud is actually doing.
Analogy🏏Cricket
🎬 Think of it like movies: a studio runs a nightly dailies screening precisely so a mistake introduced during the day's shoot — a boom mic dipping into frame — is caught the next morning, not months later at the premiere when it is baked into every reel. The overnight review compresses a potential disaster into a quick next-day reshoot. A nightly drift check that surfaces a database's public-access flag flipped on during a late-night debugging session works the same way: an exposure that could have festered for months becomes a same-day fix. This reveals how a regular review cadence turns a silent, lingering gap into a caught-and-closed one.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.
Drift is divergence between what IaC describes and what actually runs in the cloud.
Manual changes bypass version control, so static code scans never see them.
Drift detection compares live cloud state against the state Terraform expects.
Continuous compliance tools check live configuration directly against benchmarks.
Restrict console access for production and codify any emergency manual change afterward.