How to Query Cloud Infrastructure State

Queryable infrastructure means engineers can ask direct questions about cloud state instead of clicking through consoles, reading stale diagrams, or grepping Terraform folders. In ops0, the Query Console connects to infrastructure state from Terraform, OpenTofu, CloudFormation, and Oxid-backed projects so teams can find resources, drift, ownership, incidents, and policy risk with repeatable queries.

The core problem is simple: infrastructure data exists, but it is scattered. Terraform knows declared state. Cloud APIs know live state. CI/CD knows deployments. Kubernetes knows runtime health. Security scanners know findings. Humans usually have to assemble the answer manually.

What Teams Ask

The useful questions are not abstract. They sound like:

• Which production resources changed in the last 24 hours?

• Which security groups expose public ingress?

• Which resources are unmanaged by IaC?

• Which CloudFormation projects should be migrated to Terraform or OpenTofu first?

• Which incidents are tied to recent infrastructure changes?

• Which projects have drift, policy blocks, or failed deployments?

A dashboard can show a few of these. A query layer lets you ask the next question without waiting for a new chart.

Why Static Inventories Fall Short

Static inventories answer what existed at scan time. Queryable infrastructure answers what exists now, how it relates to declared state, and what changed.

That difference matters during incidents and audits. If a database is public, you need to know not only that it is public, but which project owns it, whether the exposure was intentional, which policy should have blocked it, and what depends on it.

ops0 connects those layers through Discovery, Resource Graph, IaC projects, incidents, and policy checks. The result is an operational question engine, not only a resource table.

How ops0 Uses Queryable State

ops0 supports query workflows for infrastructure projects so teams can inspect state in read-only mode. That state can come from Terraform, OpenTofu, CloudFormation migrations, and Oxid-backed infrastructure databases.

The product also connects query answers to AI workflows. Kiwi can use infrastructure context to answer questions like "what changed in prod?" or "which IaC incidents should I fix first?" and then render tables or summaries from the underlying state.

The important part is repeatability. A query can become a saved operational check, a pre-audit review, or a starting point for remediation.

Where Query Fits in the ops0 Loop

Discovery finds what exists across cloud accounts.

IaC defines or generates what should exist.

Resource Graph maps dependencies and drift.

Query Console turns that state into precise answers.

Workflows can act on those answers when a repeatable response is needed.

This is how infrastructure moves from "visible" to "answerable." Visibility shows the map. Queryability lets teams ask the map questions.

What to Look For in a Queryable Infrastructure Platform

A useful query layer needs more than a search box. It should understand IaC state, live cloud state, project ownership, deployment history, incidents, policy results, and cost context.

It should also be safe by default. Querying production infrastructure state should be read-only, permissioned, and audit logged. The goal is faster answers without creating another path for risky changes.

How It Works

The Query Console is the place where teams ask questions about infrastructure state. The UI runs a Monaco-based editor for query input and renders results in a sortable, filterable, paginated table backed by @tanstack/react-table.

Behind the editor, ops0 maps queries onto multiple backends instead of forcing one query language across them. Terraform and OpenTofu projects expose state through Oxid, a PostgreSQL-backed state service that turns Terraform state into structured rows that can be filtered. CloudFormation queries hit AWS describe and list APIs. Kubernetes queries hit cluster APIs for events, pods, and workloads. Discovery queries read scanned cloud resources from the database. Resource Graph queries traverse nodes and edges produced by the resource-graph service.

The Kiwi agent sits on top of this layer and translates natural language into the right backend call. A user asks "which production resources are unmanaged by IaC," and Kiwi turns that into a Discovery query joined with IaC project membership, returning a table the user can sort by region, account, or last-seen time. Conversations are stored in kiwiConversations and kiwiMessages so the same question can be re-run, refined, or shared.

Permissions And Audit

Querying infrastructure state needs access control, not only a query box. ops0 enforces this through OpenFGA-backed permission middleware applied at the conversation and resource level. A user querying production may have read access to one project and not another, and the middleware enforces that boundary before any cloud or database call is made.

Every query execution is logged through audit middleware. The audit record captures who ran the query, against which project, with which Kiwi conversation, and when. lastSyncAt and lastSyncedAt fields on project mappings show how fresh the underlying state is so the answer is paired with provenance.

What Teams Run

Useful query patterns inside ops0 fall into a few buckets.

Inventory. List EC2 instances by region and account. List buckets without encryption. List load balancers with public listeners. Find unmanaged resources in a given account.

Change. Show resources changed in the last 24 hours. Show stacks with drift. Show recent failed deployments. Show projects whose policy gates blocked merges this week.

Ownership. Show resources without Owner or CostCenter tags. Show projects without an assigned team. Show clusters without an Environment tag.

Risk. Show stacks with open P1 incidents. Show namespaces with unresolved Trivy criticals. Show resources with public ingress that crossed a Kyverno deny rule.

Cost. Show namespaces above a cost threshold using OpenCost data. Show idle resources by tag. Show projects with month-over-month cost spikes.

Each of these can be run as an ad hoc query, saved as a recurring check, or wired into a workflow that takes action when the result set is non-empty.

Why Read-Only Matters

The Query Console is intentionally read-only by default. Querying production should never be a path to mutate production. Mutation lives in IaC projects, deployments, and workflows where the change is reviewable, policy-checked, and auditable.

That separation is what lets ops0 expose a powerful query surface without turning it into a backdoor. Discovery shows the map, Resource Graph shows the dependencies, the Query Console answers questions about both, and any change still flows through the governed deploy path.

The Bottom Line

Queryable infrastructure is the natural next step after discovery. Once you know what exists, the next question is: can you ask useful questions about it?

ops0 is built around that shift. Infrastructure should not be a pile of dashboards. It should be an operational knowledge base that engineers, security teams, and AI agents can query with confidence.

Example Query Workflow

Question: Which production resources are unmanaged by IaC?
Context: Discovery inventory, IaC project mappings, Resource Graph dependencies
Result: Table of resources with provider, account, region, owner tag, last seen time, and remediation path
Safety: Read-only query, permission checked, audit logged