Free DP-700 practice test: 30 questions with answers

Data pipelines orchestrate copy and transformation activities on schedules with control flow and error handling. Reports present data, shortcuts reference it, and views do not orchestrate loads.

Dataflow Gen2 provides a low-code Power Query experience for transforming data and writing it to Fabric destinations. Printed guides are not a tool, and eventhouses store streaming data.

Eventstreams ingest, route, and transform streaming events in near real time. Stored procedures run on demand, import datasets refresh in batches, and shortcuts do not process streams.

PySpark distributes the read and write and writes the Delta format natively, which scales for large files. Manual retyping, PDF conversion, and single-thread row inserts are slow and error-prone.

Watermark-based incremental loads process only new or changed rows, which reduces time and cost. Full reloads, unfiltered loads, and deleting the source do not meet the requirement.

Dependency conditions such as Succeeded, Failed, or Completed control whether downstream activities run. Colours and comments do not affect execution, and a zero timeout would fail immediately.

A failure dependency path can trigger a notification activity immediately when a step fails. Hoping for manual checks, duplicate runs, and disabled error handling do not provide reliable alerts.

Broadcasting a small table sends a copy to each executor, avoiding a costly shuffle of the large table. Cartesian joins multiply rows, sorting does not reduce shuffle, and row loops are slow.

Compaction combines small files into larger ones, which speeds reads. Adding files, nightly deletion, and disabling statistics do not fix the small-file problem.

A merge keyed on a business identifier makes retries idempotent by updating existing rows instead of duplicating them. Appending retries, deleting without backup, and ignoring duplicates create data quality problems.

OneLake is the single logical data lake for a Fabric tenant, shared by workloads and teams without duplicating data. Local shares, printed catalogues, and email archives do not provide shared, governed storage.

Shortcuts reference external data in place, so workloads can read it without duplicating it. Manual downloads and copies create duplicates, and screenshots do not provide data access.

A lakehouse stores Delta tables in OneLake and exposes them to Spark and a SQL analytics endpoint. KQL databases serve time-series and log analytics, reports visualize data, and eventstreams route events.

A Fabric warehouse supports T-SQL DML, stored procedures, and transactions across tables. Eventstreams process events, dataflows transform data without storing it as a warehouse, and shortcuts reference data.

Delta time travel queries earlier table versions, which supports audits and recovery. Compression, pruning, and browser caching do not provide access to past versions.

The silver layer holds cleansed, conformed, and validated data. Bronze keeps raw data, gold holds business-ready aggregates, and backups are not a medallion layer.

Column-level security restricts access to specific columns for specific users within the SQL endpoint. Renaming, copying for everyone, and public links do not enforce authorized access.

Row-level security filters rows for each user based on a predicate, enforced by the engine. Removable report filters, documentation notes, and duplicated tables do not enforce access.

Sensitivity labels from Microsoft Purview classify items and can carry protections across Fabric content. Paper labels, naming conventions, and assumptions of security do not enforce classification.

Mirroring replicates supported external databases into OneLake in near real time, reducing custom pipelines. Printing, manual exports, and storing passwords in notebooks are inefficient or insecure.

The monitoring hub shows activity history and details for items such as pipelines and notebooks, which supports diagnosis of slow runs. Calendars, static charts, and descriptions do not show run data.

Stage details show which step consumes memory, often due to skew, and tuning memory or partitioning addresses it. Restarting or disabling monitoring hides the cause, and adding cells does not help.

Execution plans and statistics show where time is spent, which guides tuning. Printing, renaming, and deleting history do not reveal performance details.

Scheduling heavy work outside peaks and sizing capacity from metrics reduces throttling. Turning off reports, deleting data, and disabling monitoring either remove function or hide the problem.

Partitioning by date lets the engine skip partitions that do not match the filter, which reduces the data read. One large file, removing the date, and random sorting do not help pruning.

Pre-aggregation stores the results so each load reads a small table instead of recomputing aggregates. More visuals, disabled caching, and repeated exports add work.

Alerts on duration or failure signals notify the team when a run deviates from normal behaviour. Quarterly checks, row-count-only tracking, and user emails react too late or miss the signal.

Salting or repartitioning spreads a skewed key across more tasks, which balances the load. Copies of the same partition, a single executor, and removing the key break the logic or slow the job.

Vacuum removes unreferenced files after the retention window, which reduces storage. Copies and extra versions increase cost, and renaming does nothing for file cleanup.

A retry policy re-attempts transient failures with a set count and interval, which recovers without manual work. Manual reruns, hidden errors, and very short timeouts reduce reliability.