The Cloud Project Junk Drawer
Every AI-assisted task succeeds. The cloud fills with tables, jobs, and permissions nobody owns.
What it is
The Cloud Project Junk Drawer is infrastructure sprawl caused by one-off work that creates persistent resources without an owner, environment boundary, or cleanup plan. Accounts, projects, datasets, tables, jobs, and service accounts exist because they helped one task finish once. Some are empty. Some contain data. Some have permissions nobody is comfortable removing because nobody can prove what they do.
How it happens
Someone gets a narrow task: load this file, test this pipeline, build this report. They know the business problem but have not been given the account structure, data boundaries, or privilege rules. An AI assistant joins the loop with the same missing context and credentials broad enough to create whatever seems useful.
In an illustrative warehouse project, an agent creates
sales_test to validate an import and schedules a refresh.
Someone later connects a dashboard to it because the name looks right.
The original task is complete, but the “test” table now has
a consumer, copied production data, and a job that will keep running.
Deleting it as scratch would break the dashboard. Leaving it alone
keeps an undocumented data path alive.
The refresh job made sense during the experiment. The dashboard turned that experiment into a dependency without anyone deciding to operate it. That transition is where a disposable resource needs an owner, a supported data source, and a place in the deployment process.
Why it’s dangerous
The risk is not just clutter. It is reports built on incomplete tables, duplicate datasets with different answers, unnecessary permissions, and abandoned jobs still moving data. Cleanup becomes scary because the team cannot distinguish trash from load-bearing trash.
AI makes it easier to create the next resource during an urgent task. Without a supplied environment model and enforced boundaries, a plausible name can become an architectural decision. The missing owner and lifecycle may stay invisible until the bill, access review, or broken report arrives.
How to prevent it
Before asking AI to touch cloud or warehouse resources, give it the map: what environments exist, which accounts or subscriptions are in scope, where scratch work belongs, which datasets are authoritative, what naming conventions apply, and what it may never create or modify. If that map does not exist, have AI help draft it first from the current estate and then treat the draft as something to review, not as permission to keep mutating the estate.
A small team does not need a committee for every table. A designated scratch schema, a constrained role, and a recorded owner and expiry may be enough for experiments. Where the platform allows it, deny production reporting identities access to scratch datasets. A dashboard author should have to promote the data source before making a production report depend on it.
The serious team fix
Make the supported path easier than improvising another resource:
-
Promote useful experiments deliberately. When the
sales_testexperiment becomes useful, bring both the table and its refresh job under a maintained deployment, settle ownership, access, and retention, then switch consumers to the supported location. Renaming the table alone does not promote the job. - Permissions that enforce the map. Use read-only discovery roles and constrained write access for experiments. Provide templates or commands that create resources in the right environment with the required ownership and data controls. Review exceptions to that path; routine work should not require an admin to hand-approve every creation.
- Inventory beyond the infrastructure state file. Compare provider inventories of resources, grants, and scheduled jobs with the approved map. Infrastructure-as-code drift checks are useful, but they are not a complete list of everything someone created elsewhere. Terraform’s drift guide explains how it compares managed resources with their recorded state. Check unmanaged resources separately. Inspect scheduled queries, dashboard configuration, access logs, and grants to find consumers; an unused-looking table can still feed a monthly report. Resolve those dependencies before retiring it. An absent owner tag is a reason to investigate, not sufficient evidence for deletion.
AI can move fast inside a structure. Without one, it can make a very helpful mess and call the prompt complete.