A county finance team needs Azure Databricks analysts to query live tables in an existing SQL Server permitting database without copying every table into the lakehouse first. Which Unity Catalog approach should they implement?

Lakehouse Federation foreign catalogs are the Unity Catalog pattern for live query access to external systems such as SQL Server without first copying every municipal table into managed lakehouse storage. For the county permitting database, administrators define a connection to SQL Server and register a foreign catalog so Databricks analysts can discover and query remote permitting tables under Unity Catalog governance while the operational system of record stays in place. That preserves a single source of truth for permit status, fees, and inspections and still lets finance teams join federated rows with lakehouse dimensions when needed.

Nightly CSV export into unmanaged Hive tables fails the requirement because it is a batch copy, not live query, and it leaves objects outside Unity Catalog governance. Mounting SQL Server data files as DBFS folders and registering classic Hive metastore tables misunderstands the architecture: SQL Server tables are not ADLS file mounts, and classic Hive bypasses Unity Catalog. Duplicating the entire permitting database into a serverless SQL warehouse as temporary views also copies data, creates drift risk against City Hall's live system, and temporary views are session-scoped—not a durable federation pattern.

Exam caveat: federation queries remote engines and can incur latency, pushdown limits, and connection credential management; it is not a substitute for curated silver/gold Delta when the county needs heavy transforms or offline analytics. Operational check: confirm the SQL Server connection succeeds, the foreign catalog lists expected permitting schemas, SELECT grants are limited to the finance analyst group, and a sample join against a lakehouse calendar table returns current permit rows without a prior COPY INTO.