A managed table is one where Unity Catalog chooses the storage location and controls the file lifecycle; an external table is one you register against a cloud path you own. Databricks recommends managed tables for almost everything, and the difference the exam tests is what happens when you DROP one.
Last updated September 2026.
Create a managed table unless another system owns the files or the data must live at a fixed path. Dropping a managed table deletes its data files (after a short retention window that allows an undrop); dropping an external table removes only the catalog entry and leaves the files where they were. Managed tables also get the automatic optimizations Databricks reserves for storage it controls.
With a managed table you write CREATE TABLE finance.gold.sales (...) or CREATE TABLE ... AS SELECT with no LOCATION clause, and Unity Catalog puts the files in the managed storage configured for the schema, catalog or metastore. Databricks documents why this is the recommendation: managed tables and volumes let you take full advantage of Unity Catalog governance and performance features, including auto compaction, auto optimize, faster metadata reads and intelligent file size optimization.
Because the catalog owns the lifecycle, the security story is simple too: nobody can read the files around the table's grants, and when the table is dropped the data goes with it. For a customer dataset that a compliance team expects to disappear on deletion, that is the property you want.
An external table is created with LOCATION 's3://bucket/path/' (or the equivalent on Azure or GCP) against an external location an administrator has already registered. The data stays where it is. Databricks lists the cases: data that other systems write or read directly, data that must remain at a known path, and migrations where the files already exist. The table gives you governance over an asset you do not fully own.
Two rules travel with it. Never register the same external table in more than one metastore, because two catalogs writing the same files corrupts both. And treat VACUUM with care: it deletes files no longer referenced by the current version, so any other tool reading that path, and any old version you wanted to time travel to, loses them.
| Managed table | External table | |
|---|---|---|
| Who picks the location | Unity Catalog, in managed storage | You, with a LOCATION clause |
| DROP TABLE | Deletes the data files (undrop possible for a short window) | Removes the metadata only; files stay at the path |
| Automatic optimizations | Yes: compaction, file sizing, faster metadata | Not all of them |
| Other systems reading the files | Not by design | Yes, that is often the point |
| Databricks guidance | Recommended default | When the path or another owner requires it |
Sourced from the Databricks documentation page on managed versus external tables and volumes, and the Unity Catalog best practices page.
DESCRIBE EXTENDED table_name reports Type: MANAGED or Type: EXTERNAL and, for external tables, the location. In Catalog Explorer the Details tab shows the same. Check before you drop anything you did not create: an external table that "looks like a scratch copy" may be the registered view of a bucket a nightly job depends on.
Exam tip: If a scenario says a table was dropped and a downstream job reading the same cloud path kept working, it was external. If it says the files must be deleted when the table is, or asks for automatic optimization, the answer is managed. If it asks which to create with no special constraint, managed is the recommendation.
The distractors are usually the two beliefs that the retention window makes managed data readable by other jobs after a drop (it does not; the files are not addressable outside the table) and that external tables cannot be optimized (they can; they just miss some of the automatic features).
A managed table stores its data in storage Unity Catalog controls, so the catalog manages the file location and lifecycle. An external table is registered against a cloud storage path you specify, and the files remain yours to manage.
Unity Catalog deletes the underlying data files, after a short retention window during which the table can be undropped. Dropping an external table removes only the catalog metadata and leaves the files in place.
Databricks recommends managed tables because they get the full set of Unity Catalog governance and performance features, including automatic compaction and file sizing. Use an external table only when another system owns the data or it must stay at a fixed path.
Not in place. Create a managed table from the external one with CREATE TABLE AS SELECT or a deep clone, repoint consumers to it, then drop the external table, which leaves the original files untouched.
Managed versus external tables is a trade-off chapter in the Data Analyst Associate course, with the DROP behaviour, the decision signals and the questions the exam builds around them.
Open the chapter →