Coverage — Cloudkeel

Field-level cross-check

200 resource types get a true field-level diff — desired state against live reality, property by property, naming the exact field that moved. How many of the 200 you get depends on where your Terraform state lives, not on which cloud you run.

Terraform Cloud

also Terraform Enterprise, or a local plan file

68 Azure types and all 59 GCP types, field-level. On AWS, security groups only.

Two Azure types — role assignments and role definitions — are reachable only on this path. The AWS limit is the one to know before you evaluate: from a plan we field-diff security groups and nothing else.

Raw .tfstate

S3, GCS, or Azure Blob

All 62 AWS types, all 59 GCP types, and 77 of 79 Azure types, field-level.

This is the path that unlocks AWS depth — every AWS spec runs here, against one on the plan path. Azure loses only role assignments and role definitions.

Kubernetes

Helm release records — no GitOps tool needed

Deployments, StatefulSets, DaemonSets, Services, ConfigMaps, Ingress.

Helm’s own stored release manifest is the desired state and a live API read is the actual, so no Argo or Flux is required. Secret values are never read or diffed.

Unmanaged-resource detection

A different question, and a different list: what is running that no Terraform state declares? This is the half terraform plan structurally cannot answer, so the coverage is broader than the field-level set above.

Azure

79 types

Every Azure type above. Across the subscriptions your credential can see.

AWS

64 types

The 62 above, plus 2 enumerated-only types. One account per credential.

GCP

59 types

The 59 above, plus 0 enumerated-only types. One project per credential.

Managed-state sources

Where Cloudkeel-DD learns what’s supposed to be running.

Terraform Cloud

Reads the workspace’s plan JSON over the API, including the resources Terraform’s own refresh already found drifted.

Terraform Enterprise

Same as Terraform Cloud, against your own hostname.

Terraform local

Reads a terraform show -json plan file — no Terraform Cloud account needed.

S3 / GCS / Azure Blob

Reads raw .tfstate straight from your bucket or container. This is the path that unlocks field-level AWS coverage.

Helm

Helm’s own release records, read from the cluster.

ArgoCD

Managed-resource state via the ArgoCD API.

Flux

HelmRelease / Kustomization drift via the Kubernetes API.

Where the depth ends

The honest edges. Everything below is either by design or on the roadmap, and stated up front rather than discovered in week three.

Field-level coverage is path-dependent, and the two paths are not equal. AWS is the sharpest asymmetry: on the Terraform Cloud path you get security groups only, while raw state gets all six AWS types. If AWS depth is what you need, point us at your state bucket.
Two Azure types are plan-path only — role assignments and role definitions. Raw state cannot cross-check them today. (GCP service accounts and IAM custom roles used to sit on this list; both are raw-state cross-checked now.)
2 types are enumerated for unmanaged detection but never field-diffed: aws_eip, aws_route_table. We will tell you they exist and that nothing declares them. We will not tell you which field changed.
Unmanaged detection needs a connected Terraform state source to define what “managed” means. A cloud credential on its own produces no findings — it is the cross-check, never the scan target.
There is no filter for service-created resources yet, so your first scan will flag things your cloud provider made: default VPC security groups, service-linked roles, GCP default-allow-* firewall rules. Expect noise on scan one, and tell us which patterns to baseline.
One AWS account or GCP project per connected credential. No AssumeRole, no Organizations-wide discovery. Azure is the exception — one credential covers every subscription it can read.
SSO / SAML is on the roadmap, not shipped. Today it is email and password with per-tenant roles: owner, admin, viewer.
Reports export to CSV as aggregate metrics. There is no per-finding export and no PDF.

Anything outside field-level coverage is still discovered and tracked as clearly-labelled inventory — never silently assumed clean. You always know which resources are diffed and which are only tracked.

Two bars, kept separate. Engine-verified means a type passes golden-fixture tests. Real-cloud-proven means we’ve injected drift into a live account and watched the finding name the field. All 200 types are engine-verified. Three are real-cloud-proven — Azure NSG rules, AWS security-group rules, GCP firewall rules — and we would rather show you that ratio than average it into one number. The table generated from the product’s own type registry lives in the docs.

Install in 15 minutes How the read-only model works