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.