Free DP-600 Exam Flashcards

A workspace is the collaboration container and primary security boundary for Fabric items such as lakehouses, warehouses, notebooks, pipelines, and semantic models. Workspace roles set baseline access; narrower item permissions can refine it.

Admin (full control including settings and access), then Member (manage users and content), then Contributor (create and edit content), then Viewer (read-only). Grant the least privileged role that still supports the user's task.

Prefer single-item access when only one asset needs to be shared; it limits exposure. A workspace role grants access to every item in the workspace, so it is broader and riskier for narrow sharing needs.

A domain groups workspaces and content by business area to improve discovery and ownership clarity. It organizes content but does not by itself grant access to data — permissions are still controlled separately.

RLS (row-level security) filters which rows a user sees. CLS (column-level security) hides specific columns. OLS (object-level security) hides entire tables or objects so they do not appear in the model at all.

No. A sensitivity label classifies and can protect data (encryption, handling guidance, downstream inheritance), but it is not an access-control mechanism. Use workspace roles, item permissions, and RLS/CLS/OLS to control who can read data.

It restricts access to specific paths (files or folders) in OneLake. It matters because being able to see a Fabric item does not automatically mean a user should read every underlying file or table behind it.

Workspace role, then item permission, then file/folder security, then row-level (RLS), column-level (CLS), and object-level (OLS) security. Combine the broad and fine layers to enforce least privilege.

Promoted marks content the owner recommends for reuse. Certified is a stronger signal: the content passed a formal organizational review and is treated as an authoritative enterprise source. Endorsement signals trust; it does not grant access.

It maps how items depend on each other across the workspace (sources, models, reports). Review impact analysis before changing a schema or deleting an asset so you do not silently break downstream reports or models.

Endorsement marks content as trusted (Promoted/Certified) for discovery and reuse. A deployment pipeline promotes item definitions through dev → test → production stages. Trust signaling and lifecycle promotion are separate concerns.

PBIP (Power BI Project) saves a report and its semantic model as plain, source-control-friendly files. It enables Git versioning, code review, and CI/CD instead of opaque single-file PBIX binaries.

It connects a workspace to a Git repository so supported items can be versioned, branched, reviewed, committed, and synced. It brings branch-based development discipline before changes reach test or production.

A deployment rule. Deployment rules override stage-specific settings (data source connections, parameters) so a promoted item points to the correct test or production environment instead of the dev source.

The XMLA endpoint allows external tools and scripted/automated processes to read and write semantic model metadata — used for advanced model management, scripted deployment, and partition or refresh automation.

OneLake is Fabric's single, tenant-wide data lake. Every Fabric item stores data in OneLake, giving the tenant one logical lake so data can be reused across items without creating unnecessary copies.

A shortcut is a virtual reference to data in another location (another lakehouse, OneLake, or external storage) without physically copying it. The data stays at the source and inherits source location security and performance characteristics.

Use a shortcut to virtually reference existing data in place with no copy. Use mirroring to continuously replicate a supported operational database into OneLake for analytics. Shortcut = no copy, virtual; mirroring = managed near-real-time replica.

The OneLake catalog helps you discover and govern stored data items (lakehouses, warehouses, semantic models). The Real-Time hub helps you discover and connect to streaming sources and event data. One is for stored data, one for streams.

When Fabric must reach a data source that is not directly cloud-accessible, such as an on-premises database. The gateway provides the secure bridge for those connections; cloud-to-cloud sources usually do not need it.

A lakehouse stores files plus Delta tables and suits open-file, Spark, and notebook-centric analytics. A warehouse is a relational T-SQL analytics store for SQL development and serving curated relational data. Pick by workload, not preference.

Choose an eventhouse for high-volume, time-series telemetry and event/log data queried with KQL. A warehouse handles structured relational analytics with T-SQL. Streaming/observability favors the eventhouse; relational reporting favors the warehouse.

It lets you query lakehouse Delta tables with T-SQL for read-oriented exploration and reporting. It is read-only over lakehouse tables — to write with T-SQL (INSERT/UPDATE/stored procedures over managed tables) you use a warehouse.

The Files area holds raw or semi-structured files (landing/bronze data). The Tables area exposes managed Delta tables for query and analytics. Promote cleaned data from Files into Tables for reliable downstream consumption.

A Delta table pairs data files with a transaction log, giving ACID-style reliability, schema enforcement, time travel, and consistent reads. Loose files lack the transaction log, so concurrent reads/writes can be inconsistent.

Use Dataflow Gen2 (Power Query, low-code) for visual cleansing, shaping, and loading. Use a notebook when transformations need code (PySpark/Scala), complex logic, or fine-grained Spark control. Code-heavy work needs the notebook.

A Dataflow Gen2 transforms and loads data. A pipeline orchestrates activities (copy, dataflow, notebook, stored procedure) with dependencies and scheduling. A dataflow shapes data; a pipeline coordinates the overall workflow.

Power Query applies applied steps sequentially. Changing or inserting an early step (a filter, type change, or rename) can ripple into later joins, filters, and the destination mapping, so edits must respect step dependencies.

A full load reloads the whole dataset: simple but wastes time/capacity when little changed. An incremental load moves only new or changed rows since the last run: efficient, but it requires a reliable change indicator (watermark, timestamp, or CDC).

Append stacks rows from compatible tables (more rows, same columns). Merge joins tables on a key to bring columns from another table (more columns). Need more rows → append; need more columns → merge.

A star schema separates a central fact table (measures/events) from surrounding dimension tables (descriptive context). It simplifies relationships, improves query and filter performance, and avoids ambiguous paths common in snowflaked or normalized designs.

The grain is what one fact row represents (for example, one order line per day). Defining it prevents double counting and keeps measures consistent across every dimension you slice by.

A business (natural) key comes from the source system. A surrogate key is a model-generated identifier that stays stable, enables slowly changing dimension history, and decouples the model from source-key changes or reuse.

Schema drift is an unexpected change in source columns or data types. If unhandled, it causes silent data-quality issues or hidden refresh failures, so transformations should detect and react to expected changes intentionally.

Late-arriving data reaches the pipeline after its related records or reporting window were already processed. A resilient design loads it safely and updates the affected tables rather than silently dropping it, keeping totals accurate.

Use T-SQL for relational warehouse/lakehouse table queries, KQL for high-volume telemetry and log data in an eventhouse/KQL database, and DAX for calculations and measures inside a semantic model. Match the language to the asset.

Both aggregate rows into groups. SQL uses GROUP BY with aggregate functions over relational tables; KQL uses the summarize operator over telemetry/log data. Same intent, different language for a different store.

The Visual Query Editor builds queries graphically (select, filter, join, aggregate) without writing SQL, generating the underlying query for you. It suits quick exploration and users who prefer a no-code path over hand-written T-SQL.

CALCULATE evaluates an expression in a modified filter context — the core function for measure logic. EVALUATE returns a table result from a DAX query. CALCULATE shapes filter context; EVALUATE returns a queryable table.

Import copies data into the model's in-memory (VertiPaq) cache and refreshes on a schedule. DirectQuery sends live queries to the source at report time. Direct Lake reads OneLake Delta/Parquet files directly — near-import speed with high freshness and no scheduled import.

Fallback is when a Direct Lake model temporarily switches to DirectQuery against the SQL endpoint for a query it cannot serve from OneLake directly (for example, unsupported features or limits). Performance then behaves like DirectQuery for those queries.

Framing is the operation that updates which OneLake data files a Direct Lake model points to. Until reframing occurs, the model may serve the previously framed version, so framing controls how current Direct Lake results are.

A composite model mixes storage modes (for example, Import plus DirectQuery, or a Direct Lake source plus an imported table) in one semantic model. Use it to combine fast cached data with live or supplemental sources in a single model.

A bridge table resolves a many-to-many relationship between two dimensions or between a fact and a dimension by sitting between them, restoring clean one-to-many filter paths and avoiding ambiguous or incorrect filtering.

A calculation group applies reusable measure variants (such as time-intelligence or formatting) across many measures without duplicating them. A field parameter lets a user switch which dimension or measure a visual uses. One reuses measure logic; the other switches fields.

A calculated column is computed and stored per row at refresh, increasing model size. A measure is computed at query time in the current filter context. Prefer measures for aggregations; use calculated columns only when a stored per-row value is required (for example, to slice or relate by).

Context transition is when row context is converted into an equivalent filter context — triggered by CALCULATE (and implicitly by measures referenced inside an iterator). It is essential for correct per-row measure aggregation and a common source of subtle DAX bugs.

A VAR stores a sub-expression once so it is evaluated a single time and reused, improving readability and performance. It also locks the value at its evaluation context, avoiding accidental recomputation under shifting filter context.

Incremental refresh partitions data by date so only recent partitions refresh while historical partitions stay cached. It shortens refresh time and reduces source load for large models instead of reloading all history every refresh.

VertiPaq compresses columns; high-cardinality columns compress poorly, inflating model size and slowing queries. A star schema moves descriptive, repeating attributes into dimensions and keeps the fact narrow, reducing cardinality pressure and improving compression and speed.