topic Re: Declarative Automation Bundle - How to handle Managed resources? in Data Engineering

Declarative Automation Bundle - How to handle Managed resources?

ChristianRRL — Mon, 24 Aug 2026 20:39:05 GMT

Hi there,

I'm making a new repo from scratch to make it as DAB-compatible as possible. I was considering using DAB for the creation/management of resources such as schemas and volumes.. however, a concern crossed my mind. If these resources are MANAGED, then if someone were to run the command:

databricks bundle destroy

This would be a huge risk if this automatically deletes all of the underlying data.

I'm curious to ask, based on this community what is the suggested practice for using (or not using) DABs for schemas/volumes? Below is a possible example of our volume data being MANAGED:

Re: Declarative Automation Bundle - How to handle Managed resources?

amitsharma1707 — Mon, 24 Aug 2026 22:04:06 GMT

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.

Re: Declarative Automation Bundle - How to handle Managed resources?

cartergray70543 — Tue, 25 Aug 2026 04:48:38 GMT

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.

Re: Declarative Automation Bundle - How to handle Managed resources?

ChristianRRL — Tue, 25 Aug 2026 20:18:33 GMT

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?

Re: Declarative Automation Bundle - How to handle Managed resources?

mancy34 — Wed, 26 Aug 2026 07:24:15 GMT

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.