HCP Terraform (formerly Terraform Cloud) does drift detection through health assessments. If you already run your Terraform there, on a paid tier, it is the obvious answer and this page is not for you.
This page is for the teams who are not there, and there are more of them than the tooling market usually admits.
The question it does not ask
Health assessments compare declared state against reality. So does
terraform plan. Neither can see a resource that is in no state file,
because the comparison starts from state, and something absent from state has
nothing to compare against.
That category is where most of the uncomfortable findings live: a security group opened by hand during an incident, a “temporary” resource that outlived its test, a managed identity nobody remembers creating. Cloudkeel-DD enumerates live resources and subtracts what Terraform declares, which is a different operation with a different answer.
It also does not say who. A plan diff and a health assessment both report what changed; neither reports the actor. We read the native cloud audit logs (Azure Activity Log, AWS CloudTrail, GCP Audit Logs) on a best-effort basis within a lookback window. Attribution is not mentioned in HCP Terraform’s health-assessment documentation.
And two things gate what it does ask
Edition. Health assessments, which is where drift detection lives, require Standard or Premium. They are excluded from the Free edition.
Scope. The mechanism is workspace-scoped: it assesses what HCP Terraform manages. If your state is in an S3 bucket, an Azure storage account, a GCS bucket, or on someone’s disk, it is not in scope, because it is not a workspace.
That second one is the real dividing line. Moving state into HCP Terraform is a migration, not a setting, and plenty of teams have good reasons not to do it yet: an estate split across accounts, a self-hosted requirement, a procurement cycle that has not started.
Where that leaves you
Ordered by the gap first, then by the mechanics.
| Cloudkeel-DD | HCP Terraform | |
|---|---|---|
| Unmanaged resource discovery | Yes: AWS, Azure, GCP | Not addressed; the mechanism is state-scoped |
| Kubernetes | Live cluster read: Helm, ArgoCD, Flux, sixteen kinds | No |
| Change attribution (who made it) | Best-effort, all three clouds, within a lookback window | Not mentioned in the health-assessment docs |
| Where state can live | S3, Azure Blob, GCS, local, or a plan file | HCP Terraform workspaces |
| Drift detection available on | any tier: it is the product | Standard or Premium |
| Cloud write access | None (read-only, enforced in code) | Applies runs |
| Deployment | Self-hosted Helm chart | SaaS, or Terraform Enterprise |
Where HCP Terraform is ahead
- It runs your Terraform. We do not. If you want state management, run orchestration and drift in one product, that is a real advantage and we address none of it.
- It is a first-party HashiCorp product, with the support and procurement story that implies.
- We are pre-launch. No public customers, no SOC 2. Against a regulated buyer that is a blocker, not a feature gap.
What we do not do
- Unmanaged detection needs a Terraform state source. Something must define “managed”; a cloud credential alone finds nothing.
- Attribution is best-effort and can fail quietly. If the IAM permission it needs is missing, the actor is simply absent and nothing on screen says why.
- Kubernetes coverage is sixteen kinds, not arbitrary custom resources.
- Codify emits a Terraform
import{}block only, never a resource body. - No PDF export, and the CSV carries aggregate report metrics only.
- No cost governance and no pull-request-time gate.
- Scans are point-in-time, on a schedule you set: not a live feed.
- Nothing phones home: no telemetry, analytics or licence server, and it runs air-gapped. Three paths do carry finding data outward when you configure them: notification webhooks, GitHub, and GitLab. We will not say nothing leaves your environment, because that would not be true.
If you are already on HCP Terraform
Then use its health assessments for the workspaces it manages, and consider this only for the two things it does not cover: state that lives outside HCP Terraform, and resources that live in no state at all.
What about the clouds’ own tools?
Azure Policy, AWS Config and GCP Asset Inventory each answer part of this: inside their own cloud, in their own query language, without reference to your Terraform. If your estate is one cloud, evaluate them first; they are already paid for. If it spans clouds, the check becomes three different checks, and none of them can say “this resource is in no Terraform state”, because that comparison needs your state, which is the input they do not take.
Read more
- What Cloudkeel-DD is: the product page
- Exactly where the depth ends: coverage, generated from the engine
- Install it yourself: no call, no account
Sources
- HCP Terraform health assessments and edition gating: developer.hashicorp.com/terraform/cloud-docs/workspaces/health
Read 2026-07-31; re-read for change attribution 2026-08-15. If this has changed, tell us and we will correct it.