CoursesCompliance as codeDrift & IaC gates

Drift as a compliance signal

Out-of-band change = potential control failure.

Advanced30 min · lesson 10 of 15

A control you enforced at deploy can be quietly undone afterward. Configuration drift — live state diverging from the approved baseline — is therefore a first-class compliance signal, because an out-of-band change may have weakened or removed a control you certified.

Drift as a compliance violation

When someone edits a resource directly in the console instead of through the IaC, the live configuration no longer matches the declared, reviewed baseline — and that drift can silently break compliance: a security group opened, encryption toggled off, logging disabled, a public-access block removed. In a compliance program, unexplained drift on a security-relevant resource is treated as a potential control failure to investigate, not a cosmetic difference. It might be a mistake that weakened a control, or an attacker loosening one; either way it means a control you certified may no longer be operating, which is exactly what continuous compliance exists to catch.

detect drift from the compliant baseline
# Scheduled drift check — does live state still match the reviewed IaC?
terraform plan -detailed-exitcode
# exit 0 = no drift; exit 2 = drift → a resource changed out-of-band → ALERT
#
# Runtime equivalent — a Config rule flags a resource that regresses:
# s3-bucket-public-access → was compliant, now NON_COMPLIANT
# ⇒ investigate: mistake that weakened a control, or malicious change?

Detect, investigate, reconcile

The standard drift tripwire is a scheduled evaluation — a periodic terraform plan or a continuous Config/CSPM rule — that alerts the moment live state diverges from the baseline. When drift fires, the first step is to investigate why, not to blindly overwrite it: a blind apply could revert a legitimate emergency fix. Once you understand it, reconcile — codify the change if it was intentional and compliant, or revert it if it weakened a control. Better still, prevent drift where you can with preventive guardrails (SCPs, Org Policy, admission) and IaC-only change workflows, so out-of-band changes are blocked rather than merely detected. Detection plus prevention keeps live state continuously matching your certified baseline.

Drift as a compliance signal
1approved baseline (IaC)
reviewed, compliant state
2out-of-band change
console edit, weakened control
3drift detected
scheduled plan / Config rule
4investigate + reconcile
codify or revert
Drift can silently break a certified control. Detect it, understand it before overwriting, and prevent it with guardrails + IaC-only workflows.
Unexplained drift on a security control is a potential incident
A security group opened or logging disabled out-of-band is not a cosmetic difference — it may be a mistake that broke compliance or an attacker weakening a control. Treat unexplained drift on security-relevant resources as an event to investigate, and never blind-apply over it before you understand why it happened.