ClickOps Isn’t Dead: The Drift Gap Between IaC and Reality

Iuliia Petryshyn

04 Dec 2025 — 3 min read

“IaC-first” is the story most teams tell. ClickOps is the reality most teams live.

In 100+ conversations with Heads of DevOps and Platform this year, I keep hearing the same line: “We don’t really have drift.” But the best data we do have points the other way.

Datadog’s 2024 State of DevSecOps study analyzed AWS CloudTrail logs and reported that at least 38% of organizations used ClickOps across all their AWS accounts within a 14-day window, including actions in production - meaning real changes happened outside the IaC workflow.

So no - ClickOps isn’t dead. And pretending it is creates a slow-burn operational risk.

What “ClickOps” actually means (in plain English)

ClickOps is just manual infrastructure changes made in the cloud console instead of updating Terraform/Bicep/CloudFormation and going through code review.

This isn’t an “engineers are undisciplined” problem. It’s a pressure problem:

incidents
urgent customer escalations
“just open the security group for 10 minutes”
tribal knowledge fixes
experiments that accidentally become production

Why ClickOps creates drift (and why drift is not just aesthetics)

Infrastructure drift is when the actual state of your cloud resources diverges from the desired state defined in IaC.

How drift happens in real life:

A load balancer rule is tweaked in the console during an incident.
A role/policy gets broadened “temporarily.”
A resource is created manually “to test something.”
A setting is changed via console/CLI/SDK and never back-ported to code.

AWS documents drift as a first-class concept in CloudFormation (drift detection exists because out-of-band changes happen).
AWS Control Tower also treats drift as normal enough to provide built-in detection and resolution paths (Reset/Re-register).

If major platforms build drift features, it’s not because drift is rare.

The uncomfortable truth: “We don’t have drift” usually means “we don’t see drift”

Teams say “no drift” for predictable reasons:

Drift isn’t always noisy until the next deploy breaks.
Terraform state can be “green” while reality quietly diverges.
You don’t notice until security asks, “Why is this public?”
The person who clicked it forgot, left, or assumed “someone will codify it later.”

And drift tooling is increasingly a category because this is widespread (e.g., vendor playbooks explicitly center CloudTrail-based detection).

How to reduce ClickOps damage

You can’t stop humans from using the console under pressure. What you can do is shorten the time between console change → visibility → decision → IaC reconciliation.

Practical guardrails that work:

Detect console changes

Use CloudTrail as ground truth for “who changed what, when.”
Alert on sensitive actions (network exposure, IAM policy changes, encryption changes).

Force a decision for every drift event
For each detected change, choose one:

Adopt it: back-port the change into IaC (the change was correct, just done the wrong way).
Revert it: roll back the live change to match IaC (the change shouldn’t exist).

Make reconciliation cheap
Reconciliation fails when it becomes “a Jira ticket someone will do later.” It needs to be fast, reviewable, and Git-native.
Use platform drift detection where it fits
CloudFormation drift detection is useful when CloudFormation is your control plane. AWS is even expanding drift-aware workflows (e.g., drift-aware change sets) which is a signal this problem isn’t going away.

Where Cloudgeni fits: reconcile reality back into code (merge-ready)

At Cloudgeni, we don’t assume ClickOps disappears because a policy says so. The evidence says the opposite: it keeps happening.

Our stance is simple:

ClickOps will exist under pressure. The real question is whether your IaC ever catches up.

So we focus on continuous reconciliation: detect where cloud reality diverges from IaC, then generate merge-ready PRs to bring code back in line—so engineers can review, approve, and move on (instead of doing archaeology).