Open-data engineers need a durable Unity Catalog table for published park schedules that Databricks manages end to end. Which action should they take?

Durable, end-to-end managed park schedules belong in Unity Catalog as managed Delta tables created with CREATE TABLE DDL under the appropriate catalog and schema. Managed tables place data in the catalog-managed storage location so Azure Databricks owns layout, vacuum/optimize eligibility, governance integration, lineage, and drop lifecycle for the open-data publication. That matches the city's need for an official published calendar that consumers can discover with three-level names and that platform teams can govern without chasing anonymous Blob paths.

Notebook-scoped temporary views fail because they disappear when the session ends and never become durable open-data assets. Dropping Parquet into an anonymous Blob and using spark.read without registering a table skips Unity Catalog discovery, privileges, and lineage—consumers cannot rely on a governed name. Classic Hive metastore tables outside Unity Catalog deliberately bypass the governance model the exam and municipal open-data programs require.

Exam caveat: managed tables imply Databricks-controlled storage locations and privileges; do not confuse them with external tables that only register existing paths. Choosing managed is correct when the platform should own lifecycle for published gold-style civic datasets. Operational check: after DDL, verify the table appears under the Unity Catalog park-schedules schema, DESCRIBE EXTENDED shows a managed location, SELECT works for open-data readers, and DROP TABLE removes both metadata and managed data as expected.