Databricks Certified Data Engineer - Associate
Get started today
Ultimate access to all questions.
Ultimate access to all questions.
A data engineer attempted to drop a table named orders in Databricks by executing the query DROP TABLE orders. Subsequently, the query SHOW TABLES confirmed the table's absence from the listing. However, the data files associated with the table remained in DBFS. The engineer's goal was to delete both the metadata and the data for this table. What is the most plausible explanation for this outcome?
Explanation:
The persistence of data files in DBFS after dropping the table with DROP TABLE orders suggests that the table was an external table. Here's why:
Managed vs. External Tables: Managed tables in Databricks have both their metadata and underlying data files in DBFS deleted upon dropping. External tables, however, only have their metadata removed from the registry (e.g., Databricks Catalog), leaving the data files untouched in DBFS.
DROP TABLE Behavior: By default, the DROP TABLE command removes only the metadata for the table, not the data. This behavior affects both managed and external tables differently regarding the data files. In this case, since the data files remain, the table was likely an external table.