Simulado Microsoft Fabric Analytics Engineer Associate (DP-600)

The three-part-name query is correct: Fabric supports cross-database (cross-warehouse and warehouse-to-SQL-endpoint) queries within the same workspace by referencing items with database.schema.table naming, so a single SELECT can join across WarehouseA and WarehouseB without moving data. Exporting to Parquet and using OPENROWSET is unnecessary work based on the false premise that warehouses cannot reference each other — they can, natively. Creating a Dataflow Gen2 to pre-merge them is also based on the misconception that T-SQL cannot span two warehouses; the cross-database feature exists precisely so you do not need an ETL step. Replicating the table via a shortcut misunderstands cross-warehouse joins: they do not require co-locating tables in one database, and a shortcut points to data rather than satisfying a join requirement the engine already handles natively.

Targeting row groups of roughly one million or more rows is correct: Direct Lake creates column segments aligned to Parquet row groups, and the guidance is for row groups in the low-millions range so the engine transcodes fewer, larger segments and reads efficiently — OPTIMIZE with V-Order produces this layout. Aiming for ~10,000-row row groups is wrong because that is far too small; it perpetuates the excessive-segment problem the question describes and increases transcoding overhead rather than reducing it. Keeping tiny row groups and adding more files is the opposite of the correct approach — many small files and tiny row groups are exactly what hurts Direct Lake; fewer, larger files with larger row groups are preferred. Forcing the entire table into one giant row group is also wrong: extremely oversized row groups undermine columnar segment efficiency and parallelism and exceed practical sizing guidance, so the target is a balanced multi-million-row range, not a single monolithic group.

The correct answer pinpoints the issue: the Lakehouse explorer's Tables area surfaces Delta tables (with a _delta_log transaction log), and writing plain Parquet produces no Delta log, so there is no managed table, no time travel, and no MERGE support; writing in delta format (or saveAsTable) creates the proper Delta table. The 'Tables only accepts CSV' option is wrong because the Tables area is for Delta, not CSV, and there is no automatic CSV-to-Delta conversion on write. The 'Parquet becomes Delta after OPTIMIZE' option is wrong because OPTIMIZE compacts files within an existing Delta table; it does not transform standalone Parquet into a Delta table or generate a transaction log. The 'use Files/sales' option is wrong because the Files area holds unmanaged raw files and does not auto-promote anything to a managed Delta table; managed Delta tables live under Tables and must be written in Delta format.