Skip to main content

Practice exam · Microsoft

Microsoft Fabric Analytics Engineer Associate (DP-600) practice exam

50
questions
120
minutes
70%
to pass the practice exam
60
questions in the bank

Short answer

The Microsoft Fabric Analytics Engineer Associate (DP-600) practice exam has 50 questions in 120 minutes, with a 70% passing mark, as configured here. The fastest way to know whether you are ready is to sit a full exam on the clock and read your score by domain, not only the total.

Domains covered

  • Prepare and Serve Data
  • Implement and Manage Semantic Models
  • Maintain a Data Analytics Solution

Sample questions, with explanations

Three questions from the bank, open to read.

Question 1 · Prepare and Serve Data

A report developer must join a dimension table that lives in WarehouseA with a fact table that lives in WarehouseB, both in the same Fabric workspace, and return the result with a single SELECT. The two warehouses are separate items. What is the correct way to write this query?

  1. Export both tables to OneLake Parquet files and use OPENROWSET, because warehouses cannot reference each other directly.
  2. Create a Dataflow Gen2 to merge the two warehouses first, since T-SQL cannot span two warehouse items.
  3. Replicate WarehouseB's fact table into WarehouseA using a shortcut, because cross-warehouse joins require all tables in one database.
  4. Run a three-part-name query (database.schema.table) from either Warehouse to reference both items, since cross-warehouse queries are supported within a workspace. ✓ (correct)
Why this is correct

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.

Question 2 · Prepare and Serve Data

A Direct Lake fact table is loaded by streaming many tiny appends throughout the day, producing files with very small row groups (a few thousand rows each). Cold queries are slow because Direct Lake must open and transcode an excessive number of small column segments. The engineer wants the row groups sized so Direct Lake can transcode efficiently. Which target should they aim for when re-optimizing the table?

  1. Compact the table so row groups contain on the order of one million or more rows, reducing the number of column segments Direct Lake must transcode ✓ (correct)
  2. Set the row-group target to the single largest value possible so the entire table forms one row group, eliminating transcoding overhead
  3. Leave row groups tiny but increase the file count, since Direct Lake performance scales with the number of files rather than row-group size
  4. Compact the table so each file contains exactly one row group of about ten thousand rows to maximize parallelism for Direct Lake
Why this is correct

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.

Question 3 · Prepare and Serve Data

A junior engineer writes a DataFrame to a Lakehouse using df.write.format("parquet").save("Tables/sales") in a Fabric Notebook, then is surprised the table does not appear as a managed table in the Lakehouse explorer and cannot be time-traveled or MERGEd into. What went wrong and what is the fix?

  1. The save path should have been Files/sales; any format written under Files is promoted to a managed Delta table by the Lakehouse.
  2. Writing plain Parquet does not create a Delta table; save with format("delta") (or saveAsTable) so the Lakehouse registers a managed Delta table that supports the transaction log, time travel, and MERGE. ✓ (correct)
  3. The Tables folder only accepts CSV; rewrite the data as CSV and the Lakehouse will automatically convert it to Delta on registration.
  4. Parquet files in the Tables folder become Delta automatically after the next OPTIMIZE run, so they just need to wait and run OPTIMIZE.
Why this is correct

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.

Take the full practice exam

  • 50 questions drawn from the bank, with a 120-minute timer
  • Score by domain and a review of every question
  • An AI tutor to talk through each question you miss
  • What you miss feeds your study plan
Start the practice exam

Independent, unofficial practice exam. Microsoft and the exam name are trademarks of their owners; UpSkillScore is not affiliated with them. Format and passing mark are the exam's configuration in UpSkillScore, not an official statement.

Frequently asked questions

How many questions does the Microsoft Fabric Analytics Engineer Associate (DP-600) practice exam have?

It has 50 questions and a 120-minute limit. The passing mark of the practice exam is 70%.

Is this the official Microsoft Fabric Analytics Engineer Associate (DP-600) exam?

No. It is an independent practice exam built to match the structure of the real one. It does not replace the official exam.

Do I need an account to take it?

You can read the structure and sample questions without an account. Taking the full timed exam, scoring by domain and the AI tutor need one.