A municipal architecture board wants gold citizen-service metrics fully lifecycle-managed by Azure Databricks under Unity Catalog. Which table choice should they standardize on?
Select an answer to reveal the explanation.
Short Explanation
Managed tables are the city's "we own the filing cabinet" choice—Databricks places and governs the gold citizen-service files. External CSVs and notebook-only frames leave the cabinet keys on someone else's desk.
Full Explanation
Gold citizen-service metrics that must be fully lifecycle-managed by Azure Databricks should be managed Unity Catalog tables. Managed tables store data in catalog-managed locations so Databricks controls physical layout, integrates tightly with UC privileges and lineage, and owns drop/retention operations for the municipal architecture board's curated gold layer. That is the standardized choice when the city wants the platform—not an external CSV folder owner—to own the filing cabinet for published service metrics.
Keeping gold as external tables over mutable CSV folders with no Delta log leaves lifecycle and consistency outside Databricks and undermines gold-quality expectations. Unregistered Spark DataFrames inside notebooks are ephemeral and undiscoverable for citywide consumers. Classic Hive metastore tables that Unity Catalog cannot govern fail the board's Unity Catalog mandate and recreate legacy metastore silos.
Exam caveat: prefer managed for curated gold; prefer external when you must leave files in a pre-existing ADLS path you do not want Databricks to relocate. Gold usually also implies Delta, expectations around quality tests, and tighter MODIFY grants than bronze. Operational check: create the gold metrics as managed Delta under the citizen-services catalog/schema, confirm managed location in DESCRIBE, restrict MODIFY to the metrics engineering group, and grant SELECT to approved BI identities only.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.