Lakeflow Connect vs. External Tables in Unity Catalog
Note: This section contains one or more sets of questions with the same scenario and problem. Each question presents a unique solution to the problem. You must determine whether the solution meets the stated goals. More than one solution in the set might solve the problem. It is also possible that none of the solutions in the set solve the problem. After you answer a question in this section, you will NOT be able to return. As a result, these questions do not appear on the Review Screen. You have an Azure Databricks workspace named Workspace1 that contains a lakehouse and is enabled for Unity Catalog. You have a connection to a Microsoft SQL Server database named DB1. You need to expose the schemas and tables of DB1 to meet the following requirements: The schemas and tables can be queried in Databricks. The schemas and tables appear alongside other Unity Catalog objects. The data is NOT copied into Databricks-managed storage. Solution: You create a Lakeflow Connect pipeline and connect it to DB1. Does this meet the goal?
Community Insight
The trap is confusing 'connecting' to a source with 'ingesting' data; Lakeflow Connect replicates data into managed storage, whereas external tables or foreign catalogs keep data at the source.
This question tests the distinction between data ingestion pipelines and external table connections in Azure Databricks Unity Catalog. It establishes that Lakeflow Connect copies data, violating the no-copy requirement.
Learners often select 'Yes' because they associate 'connection' tools with simply exposing schema without realizing that Lakeflow Connect is an ETL/ELT pipeline that physically moves data.
Community Discussion (2 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The solution fails because Lakeflow Connect is designed for data ingestion, which involves reading data from a source (SQL Server) and writing it into Delta tables within Databricks-managed storage. This directly violates the requirement that "data is NOT copied into Databricks-managed storage." To expose schemas and tables without copying, one should use Unity Catalog's Foreign Catalog feature or external tables pointing to the SQL Server connection, allowing query access while keeping data resident in DB1.Why the Other Options Are Wrong
Option A is incorrect because it assumes the tool meets all criteria. However, since the data is replicated, the third requirement is broken. There are no other options to evaluate as this is a binary Yes/No question on a single solution.Community Comment Notes
Community feedback strongly supports the 'No' verdict. One user noted that "A Lakeflow Connect pipeline ingests/replicates data... That means the data is copied into Databricks storage," highlighting the core conflict. Another commenter succinctly pointed out the concept is about "foreign catalog," implying that a pipeline is the wrong architectural choice for virtual access.Exam Strategy
Always distinguish between 'virtual access' (external tables, foreign catalogs) and 'physical replication' (Lakeflow Connect, Data Factory). If the requirement forbids copying data, any pipeline-based solution is likely incorrect.
Frequently Asked Questions
How do I expose SQL Server tables without copying data?
Use Unity Catalog Foreign Catalogs or create external tables using the SQL Server JDBC connection.
What is Lakeflow Connect used for if not external access?
It is used for ingesting and transforming data by moving it into Databricks-managed Delta tables.