This is a very valid concern. My preference would be to separate **application/workload lifecycle** from **persistent data lifecycle**.

I would use DABs primarily for resources such as Jobs, Lakeflow pipelines, notebooks, dashboards, and other application-level resources. For production catalogs, schemas, external locations, and long-lived volumes containing business data, I would generally manage them through a separate infrastructure/IaC layer.

`lifecycle.prevent_destroy: true` provides an important safeguard for bundle-managed schemas and volumes, but I would not rely on that as the only production protection.

A simple rule I would follow is:

**If the resource should survive even when the application is removed, the application bundle probably should not own its lifecycle.**

For dev/test, having the bundle own schemas or temporary managed volumes can be very useful because the environment is intentionally disposable.

For production, I would prefer:

Platform/IaC → Catalogs, Schemas, External Locations, Persistent Volumes
DAB → Code, Jobs, Pipelines, Application Resources

For critical landing/raw data, I would also lean toward external volumes so the underlying cloud storage is not deleted when UC metadata is removed.

Curious if others are following a similar separation between platform infrastructure and DAB-managed application resources.

I think this makes sense. Quick follow-up question. For Platform/IaC, what do you use/recommend? And would you have this in the same repository as the DAB-based logic, or separate repository?

Be cautious about managing production schemas/volumes through DABs. Keep the critical data lifecycle separate from bundle destroy, and test the destroy behavior in a non-prod workspace first.

Good point managed schemas/volumes need extra caution with bundle destroy. I’d avoid managing production data resources directly through DABs, or use safeguards to prevent accidental deletion.