Platform teams are now able to continuously identify, block, and record resources that lack an owner tag. The change combines a live inventory query (CloudQuery), an OPA‑based policy enforced by env0, and a persistent audit entry attached to each resource at creation, eliminating the need to chase tribal knowledge when staff turnover occurs.
Querying Resources Without Owner Tags
CloudQuery synchronises asset data from every cloud provider into queryable tables such as aws_ec2_instances, gcp_compute_instances, and azure_compute_virtual_machines. A single SQL statement can surface every instance that is missing an owner tag or label:
SELECT resource_id, 'aws' AS provider, 'ec2_instance' AS resource_type FROM aws_ec2_instances WHERE tags ->> 'owner' IS NULL UNION ALL SELECT resource_id, 'gcp', 'compute_instance' FROM gcp_compute_instances WHERE labels ->> 'owner' IS NULL UNION ALL SELECT resource_id, 'azure', 'virtual_machine' FROM azure_compute_virtual_machines WHERE tags ->> 'owner' IS NULL ORDER BY provider;
Running this query on a schedule produces a short, repeatable list that can be handed to finance or incident responders without manual digging.
Policy Enforcement with OPA
Identifying orphaned resources is only half the solution; preventing new ones is essential. env0 evaluates Open Policy Agent (OPA) rules against every Terraform plan before execution. The following rule rejects any creation that does not include an owner tag:
package env0
# METADATA
# title: require owner tag
# description: A resource can't be created without a declared owner.
deny[format(rego.metadata.rule())] {
resource := input.resource_changes[_]
resource.change.actions[_] == "create"
not resource.change.after.tags.owner
}
format(meta) := meta.description
When the rule triggers, the plan fails outright, ensuring that the missing tag is addressed before any cloud API call is made.
Audit Trail That Outlives Its Creator
Even with tags, the rationale behind a resource can be lost when the original requester departs. env0 records a structured event at creation time, attaching it to the resource for its entire lifecycle. An example entry looks like this:
{
"event": "resource.created",
"resource_id": "i-0a1b2c3d4e5f",
"requested_by": "j.chen@company.com",
"approved_by": "platform-lead@company.com",
"approval_ref": "ENV-4471",
"stated_purpose": "load test environment, Q3 capacity planning",
"timestamp": "2026-08-14T09:12:03Z"
}
This immutable record answers “who, why, and when” without relying on memory or informal channels.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Adopting the three‑step pattern—continuous query, OPA‑driven policy, and creation‑time audit—provides a repeatable guardrail against orphaned spend and knowledge loss. Teams should integrate the SQL query into their monitoring dashboards, embed the OPA rule in all env0‑managed pipelines, and verify that audit entries are retained in a searchable log store. The result is a self‑documenting environment where ownership is always visible, enforceable, and auditable, regardless of personnel changes.
