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.
Amit Sharma