# A Six-Hour Scan Misses What the Audit Log Already Caught > Cloud inventory has a blind spot nobody notices, because you cannot see what it never recorded. Source: https://zop.dev/resources/blogs/event-driven-discovery-from-cloud-audit-logs Published: 2026-07-17 · Author: riya-mittal · Tags: aws, gcp, azure, cloudgovernance, database --- Cloud inventory has a [blind spot](https://zop.dev/resources/blogs/gcp-databricks-cost-governance) nobody notices, because you [cannot see](https://zop.dev/resources/blogs/azure-ai-ml-cost-governance) what it never recorded. If your inventory refreshes on a periodic full scan, every resource created and destroyed between two scans leaves no trace. It ran, it billed, and it was gone before the next sweep counted it. That gap is where short-lived resources hide. A CI runner, a test VM, a load balancer an automation job spins up and tears down an hour later. Each one existed, consumed, and vanished inside the scan interval. The inventory, and everything built on top of it, behaved as if it never happened. ZopNight now reads your cloud's own audit trail to close that gap, so the resources that lived and died between scans finally show up. ## The scan interval is a blind spot, not just a schedule A full inventory scan is expensive, so it runs on an interval: every six hours. Between sweeps the inventory is a snapshot frozen at the last run. Anything whose entire life fits inside that window is invisible. It is not present at one scan, not present at the next, and nothing records the hours in between. This matters because inventory is not the end of the line. [Cost attribution](https://zop.dev/resources/blogs/smart-tags-derived-cost-attribution) reads from it. Security posture reads from it. Automation reads from it. A resource that never appears in inventory cannot be tagged, cannot be attributed to a team, and cannot be caught by a policy. It is not a small resource that got rounded off. It is a resource that, as far as every downstream system knows, never ran. Architecture diagram ## The audit log already recorded what the scan slept through Every cloud writes a lifecycle event for every resource action. AWS CloudTrail, GCP Audit Logs, and Azure Activity Log record create, delete, and status changes, timestamped, whether or not a scan happened to be running at the time. The record of what happened between your scans already exists. Nothing was reading it. ZopNight's discovery now does. A daily activity-sync reads the audit-log lookback window and applies lifecycle deltas, create, delete, status, and liveness, for every resource type across AWS, GCP, and Azure. The six-hour full scan stays the source of truth for current state. The audit stream fills in what moved between scans. Because each sync replays the day's create-and-delete pairs, a resource that appeared and disappeared on the same day is captured from the log rather than lost to the interval. Architecture diagram ## What changes for everything built on inventory The scan tells you what exists right now. The audit stream tells you what happened. Together they turn inventory from a periodic photograph into a running account of the fleet, including the parts that used to fall through the interval. | | Scan-only inventory | With audit-log discovery | |---|---|---| | Resource born and gone between scans | Never recorded | Captured from the audit log | | Lifecycle events (create, delete, status) | Inferred from snapshot diffs | Read directly from the trail | | Source of current state | The periodic scan | The periodic scan, unchanged | | Untagged transient resources | Invisible | Surfaced for attribution | ## When it helps, and when a periodic scan is enough If your resources are long-lived, standing databases, permanent clusters, reserved capacity, a periodic scan already sees them, and audit-driven deltas add little. The scan interval only hides things that live and die inside it, and long-lived infrastructure never does. The value shows up when your environment churns. Automation that creates and destroys, CI that spins up infrastructure per job, teams that experiment and clean up. There, the scan window is exactly where your most transient and least tagged resources live, and reading the audit trail is what makes them countable. One honest note on cadence. The sync runs on a daily cycle today, so it catches the day's lifecycle events rather than reflecting them the instant they happen. Tightening that toward the moment of the event is a dial to turn, not a system to rebuild. The [blind spot](https://zop.dev/resources/blogs/zopnight-claude-mcp-policy-aware-governance) is closed. How fast it closes is the next decision.