9 real DP-600 sample questions, each with a worked explanation and a rationale for every option, right and wrong. No account, no card. This is the reasoning the DP-600 tests: knowing why the tempting answer is wrong, not just spotting the right one.
The real DP-600 is Typically 40 to 60 questions questions in 100 minutes, pass mark 700 / 1000. For a domain-by-domain breakdown and a study plan, read the DP-600 study guide. The full bank has 272 questions.
lock_openFree samplePrepare Datamedium
An analytics engineer must ingest data from a SQL Server instance that runs on a server inside the company data centre, with no public endpoint, into a "Lakehouse" using "Dataflows Gen2". The "Microsoft Fabric" service in the cloud cannot reach the server directly. Which component must be installed and configured so that the connection can reach the on-premises database?
- AAn on-premises data gateway installed on a machine inside the company network, registered to the tenant and bound to the connection.check_circle Correct
- BA cloud connection defined in the "Microsoft Fabric" portal, which routes the query to the private server using the engineer's stored organisational account credentials.
- CA virtual network data gateway provisioned in the tenant, which peers with the on-premises subnet and forwards each query to the local SQL Server instance.
- DA personal gateway in standard mode shared across the workspace, which lets every workspace member reuse one connection to the local SQL Server instance.
Source data from a private on-premises database into Fabric by installing and binding an on-premises data gateway to the connection. The on-premises data gateway is the relay that sits inside the corporate network and tunnels query and result traffic between the cloud Fabric service and a source that has no public endpoint, which is why it is mandatory for on-premises ingestion.
Why A is correct: The on-premises data gateway runs inside the private network and relays queries between the cloud service and the local server, which is exactly the bridge a non-public source requires.
Why B is wrong: A cloud connection only reaches sources that already have a public or service endpoint, so it cannot by itself bridge into a private on-premises network that the service cannot see.
Why C is wrong: A virtual network data gateway reaches sources inside an Azure virtual network, not a physical on-premises data centre, so it does not bridge to a server with no cloud presence.
Why D is wrong: The personal mode gateway is single-user and cannot be shared across a workspace, so it is the wrong gateway type for a team ingestion pipeline.
lock_openFree samplePrepare Datamedium
An analytics engineer needs a "Dataflows Gen2" connection to read from an Azure SQL Database that has its public network access disabled and is reachable only through a private endpoint inside an Azure virtual network. No data centre or physical server is involved. Which connectivity option meets the requirement with the least operational overhead?
- ARe-enable public network access on the Azure SQL Database so a standard cloud connection can reach it directly without provisioning any gateway at all.
- BProvision a virtual network data gateway for the tenant, associate it with the virtual network, and bind the connection to that gateway.check_circle Correct
- CInstall an on-premises data gateway on a virtual machine inside the same Azure virtual network and bind the connection to that gateway.
- DUse a shareable cloud connection with the firewall exception list set to allow the published Fabric service tag so the private endpoint is bypassed.
Reach an Azure source restricted to a virtual network from Fabric by using a managed virtual network data gateway rather than a host-based gateway. The virtual network data gateway is provisioned and patched by Microsoft and injects into a customer virtual network, so it reaches private-endpoint sources without the engineer running and maintaining a gateway machine, minimising operational overhead.
Why A is wrong: Re-opening public access weakens the security posture the private endpoint was created to enforce, so it solves connectivity by undoing the requirement rather than respecting it.
Why B is correct: The virtual network data gateway is a Microsoft-managed gateway that connects into an Azure virtual network, reaching a private-endpoint source without you maintaining any host, which is the lowest-overhead fit.
Why C is wrong: An on-premises data gateway on a virtual machine would work but means patching and running a host yourself, which is more operational overhead than the managed option for a network-bound Azure source.
Why D is wrong: A cloud connection cannot route into a virtual network whose public access is disabled, and a service tag firewall rule does not apply when no public endpoint exists.
lock_openFree samplePrepare Datamedium
Several analytics engineers each build "Dataflows Gen2" items that read from the same Azure Data Lake Storage account. The data platform team wants one set of credentials governed centrally, so that individual authors do not each enter and store their own credentials for that storage account. How should the connection be set up to meet this goal?
- AHave each engineer create a personal cloud connection to the storage account and document the shared credential so everyone types the same secret manually.
- BStore the storage account key in a workspace parameter and reference that parameter inside each dataflow query so the credential travels with the item.
- CCreate one shareable cloud connection to the storage account, set its credentials once, and grant the engineers permission to use that shared connection.check_circle Correct
- DBind every dataflow to an on-premises data gateway and let the gateway hold one credential that all the cloud storage queries pass through centrally.
Govern one credential for a shared cloud source by creating a single shareable connection and granting users permission to use it. A shareable cloud connection stores the credential once at the connection level and is shared by permission, so multiple authors source the same data without each holding a copy of the secret, which centralises credential management.
Why A is wrong: Personal connections per author scatter copies of the same secret and create no central control point, so the credential cannot be governed or rotated in one place.
Why B is wrong: A parameter is not a credential store and embedding a key in item logic exposes the secret in the query, which is poor governance rather than a managed connection.
Why C is correct: A single shareable connection holds the credential centrally and is granted to users, so every author binds to it without re-entering secrets, which is exactly the central governance the team wants.
Why D is wrong: An on-premises data gateway is for private network sources, not a public cloud storage account, so routing cloud traffic through it adds an unnecessary component.
lock_openFree sampleMaintain a Data Analytics Solutionmedium
An analytics engineer joins a "Microsoft Fabric" workspace and must be able to create and edit reports, semantic models, and a "Lakehouse", and to publish content into the workspace. The team lead wants this person to have the lowest workspace role that still allows authoring all those items, without the ability to add or remove other users or change workspace settings. Which workspace role should be assigned?
- AAssign the Contributor role, which lets the engineer create, edit, and publish workspace items while withholding the ability to manage workspace access and settings.check_circle Correct
- BAssign the Viewer role, which lets the engineer open and consume the workspace items and refresh any semantic models that back the published reports.
- CAssign the Member role, which lets the engineer author all items and additionally share the workspace and add other users with lower roles.
- DAssign the Admin role, which grants full authoring plus control over workspace settings, user roles, and deletion of the entire workspace.
Contributor is the lowest Fabric workspace role that allows authoring all item types while withholding workspace access and settings management. Fabric workspace roles are cumulative: Viewer reads only, Contributor adds full create and edit rights for items, Member adds sharing and user management, and Admin adds workspace governance, so Contributor is the correct least-privilege authoring tier.
Why A is correct: Contributor is the lowest role that grants full authoring of items yet excludes adding users and changing settings, matching the least-privilege authoring requirement exactly.
Why B is wrong: Viewer is read-only and cannot create or edit items, so it cannot satisfy a requirement to author reports, semantic models, and a Lakehouse.
Why C is wrong: Member does grant authoring, but it also lets the user add others and reshare, exceeding the stated limit of no access management, so it is not the lowest sufficient role.
Why D is wrong: Admin gives the broadest control including settings and user management, far more than authoring needs, so it breaks the least-privilege constraint the lead set.
lock_openFree sampleMaintain a Data Analytics Solutionmedium
A single Power BI report in a "Microsoft Fabric" workspace must be made available to one external auditor who needs to view only that report and nothing else in the workspace. The auditor should not appear in the workspace role list and should not gain access to other reports, the "Lakehouse", or the semantic models stored alongside it. What is the most appropriate way to grant this access?
- AAdd the auditor to the workspace with the Viewer role so the read scope is limited to viewing rather than editing any of the contained items.
- BShare the individual report with the auditor using item-level sharing, granting read access to just that report without adding the auditor to any workspace role.check_circle Correct
- CCreate a OneLake data access role on the underlying "Lakehouse" and map the auditor to it so the report data is reachable through that role.
- DPublish the workspace as an app and add the auditor to the app audience so the single report is delivered through the packaged app instead.
Use item-level sharing to grant access to a single Fabric item without adding the recipient to a broad workspace role. Item-level sharing issues per-item permissions that bypass workspace role membership, which is the mechanism that lets a single report be exposed to a recipient while every other workspace item stays hidden from them.
Why A is wrong: Viewer is scoped to the whole workspace, so the auditor would see every report and item there, breaking the requirement to expose only one report.
Why B is correct: Item-level sharing grants access to a single item without workspace membership, so the auditor sees only that report and never appears in the workspace role list.
Why C is wrong: OneLake data access roles govern table and folder access in a Lakehouse, not visibility of a Power BI report, so they cannot scope report viewing.
Why D is wrong: An app can scope content, but building and maintaining an app for one external viewer is heavier than directly sharing the one report the requirement names.
lock_openFree sampleMaintain a Data Analytics Solutionmedium
A "Lakehouse" in a "Microsoft Fabric" workspace stores several folders of files, and a group of data scientists who already hold the Viewer workspace role must be allowed to read only one specific folder of those files through OneLake, while remaining blocked from the other folders. Which approach grants that folder-scoped read access most directly?
- APromote the data scientists to the Contributor workspace role so their elevated role lets them reach the single folder they need inside the Lakehouse.
- BApply row-level security filters on the semantic model built over the Lakehouse so the data scientists only see rows sourced from the permitted folder.
- CCreate a OneLake data access role on the Lakehouse that grants read permission scoped to the specific folder and assign the data scientists to that role.check_circle Correct
- DUse item-level sharing to share the whole Lakehouse with the data scientists, relying on the share dialog to limit them to the one folder.
OneLake data access roles enforce folder and table scoped read permissions inside a Lakehouse independently of broad workspace roles. OneLake data access roles attach permissions to specific paths within a Lakehouse, so assigning a role scoped to one folder lets those users read that folder while the absence of permission on other folders keeps them blocked.
Why A is wrong: Contributor raises rights across the whole workspace and all Lakehouse data, which over-grants access and still does not scope reading to one folder.
Why B is wrong: Row-level security restricts rows returned by a semantic model, not direct OneLake file access to a folder, so it does not control reading the files themselves.
Why C is correct: OneLake data access roles define read permissions scoped to chosen folders or tables, so a role over just that folder grants exactly the targeted file access required.
Why D is wrong: Sharing the Lakehouse item grants access to the item broadly and the share dialog does not carve out individual folders, so it cannot enforce folder-level scoping.
lock_openFree sampleImplement and Manage Semantic Modelshard
An enterprise "semantic model" must report over billions of Delta rows held in a "Lakehouse" in "OneLake". The team needs near real-time freshness without scheduled refreshes, in-memory query speed for reports, and no duplication of the data into the model. Which storage mode should they choose for these tables?
- AImport mode, because it loads the Delta tables into the model for fast in-memory queries and refreshes them on a schedule so reports stay close to the source data.
- BDirectQuery mode, because it queries the Delta tables in place for near real-time freshness and answers report queries from memory without copying any data into the model.
- CDual storage mode, because it both imports the Delta tables for in-memory speed and queries them live for freshness while avoiding any copy of the data into the model.
- D"Direct Lake" mode, because it reads the Delta tables directly from "OneLake" with in-memory speed and reflects source changes without copying data or running scheduled refreshes.check_circle Correct
Choose Direct Lake when an enterprise model needs in-memory speed and near real-time freshness over OneLake Delta data without copying or scheduled refresh. Direct Lake reads Parquet-backed Delta tables straight from OneLake and pages the columns into memory at query time, so it gives import-grade performance while reflecting source updates without a scheduled refresh and without duplicating the data into the model.
Why A is wrong: Import mode copies the Delta tables into the model and depends on scheduled refresh, which both duplicates the data and breaks the near real-time requirement, so it does not fit.
Why B is wrong: DirectQuery avoids duplication and stays fresh, but it sends each query to the source rather than serving results from memory, so it cannot deliver the in-memory query speed required.
Why C is wrong: Dual mode lets a table behave as import or DirectQuery per query, but its import side still caches a copy of the data, so it does not avoid duplication the way the requirement demands.
Why D is correct: "Direct Lake" loads Delta data from OneLake into memory on demand and tracks source changes, delivering import-like speed with near real-time freshness and no data duplication, which meets every stated need.
lock_openFree sampleImplement and Manage Semantic Modelshard
A "semantic model" imports a large historical sales fact table that changes only with a nightly batch load. The same model must also expose a small inventory table whose rows are updated continuously in a source database, and reports must show the latest inventory value at query time. The team wants to keep import speed on sales while showing live inventory in one model. How should the model be configured?
- ABuild a composite model that keeps the sales table in import mode and sets the inventory table to DirectQuery mode, so sales stays fast while inventory is read live at query time.check_circle Correct
- BSet both the sales table and the inventory table to import mode, then schedule frequent refreshes so the imported inventory rows stay close enough to the live source values for reporting.
- CSet both the sales table and the inventory table to DirectQuery mode, so every report query reaches the source and the historical sales aggregates always reflect live data alongside inventory.
- DBuild a composite model that keeps the sales table in import mode and sets the inventory table to dual mode, so inventory is cached in memory yet still shown live whenever a report runs.
Use a composite model with import for slow-changing facts and DirectQuery for a live table when one model must mix cached speed and query-time freshness. Composite models let each table carry its own storage mode, so importing the nightly sales fact preserves in-memory aggregation speed while setting the volatile inventory table to DirectQuery sends its reads to the source at query time, returning the current value without forcing the whole model live.
Why A is correct: A composite model mixes storage modes per table, so import preserves sales performance while DirectQuery on the small inventory table returns the latest source value at query time, meeting both needs.
Why B is wrong: Frequent refresh narrows the gap but still serves cached inventory between runs, so reports cannot show the latest value at query time, which the requirement demands.
Why C is wrong: Making the slow-changing sales fact DirectQuery sacrifices the import speed the team wants and pushes heavy aggregation to the source, which is unnecessary for nightly batch data.
Why D is wrong: Dual mode can answer from its import cache, so it does not guarantee the latest inventory value at query time; it suits dimensions shared across import and DirectQuery facts, not live readings.
lock_openFree sampleImplement and Manage Semantic Modelshard
A composite model has a large product dimension that joins both to an import-mode sales fact and to a DirectQuery-mode returns fact. The team wants report visuals over the import fact to stay fully in memory, while visuals that join the dimension to the DirectQuery fact resolve their join at the source. Which storage mode should be set on the product dimension table?
- AImport storage mode, so the dimension is held in memory and is also pushed to the source to resolve joins with the DirectQuery returns fact whenever those visuals run.
- BDual storage mode, so the dimension is cached in memory for visuals over the import fact yet behaves as DirectQuery when joined to the DirectQuery returns fact at the source.check_circle Correct
- CDirectQuery storage mode, so every visual over the dimension queries the source, ensuring the import sales fact and the returns fact both resolve their joins consistently in one place.
- DNo storage mode is needed on the dimension because composite models automatically promote any shared dimension to dual, so visuals over both facts resolve their joins optimally.
Set a dimension shared by import and DirectQuery facts to dual mode so it serves cached joins in memory and source joins at the source. Dual storage mode lets a shared dimension behave as import when joined to an import fact and as DirectQuery when joined to a DirectQuery fact, which lets each join resolve in the same store and avoids the expensive limited relationship a pure import dimension would force on the DirectQuery side.
Why A is wrong: An import dimension cannot resolve its join inside the source, so a DirectQuery fact must perform a limited cross-store join, which is slower than a same-store join from a dual dimension.
Why B is correct: Dual mode lets a table act as import or DirectQuery depending on the query, so the dimension serves import visuals from memory and joins to the DirectQuery fact at the source, avoiding slow cross-store joins.
Why C is wrong: Forcing the dimension to DirectQuery sends import-fact visuals to the source too, abandoning the in-memory speed the team wants for that part of the model.
Why D is wrong: Storage mode is set explicitly per table and is not auto-promoted, so leaving the dimension at its default can force cross-store joins rather than the optimal behaviour dual provides.
Examworthy is not affiliated with or endorsed by Microsoft. All questions are original, blueprint-aligned practice material. We never reproduce live exam items. DP-600 and related marks belong to their respective owners.
