DP-700 Implement and manage an analytics solution

Implement and manage an analytics solution Detailed Explanation

Fast review map for this domain:

Exam signal	First object to inspect	Correct-answer pattern
Same behavior affects several items in one workspace	Workspace settings	Change Spark, OneLake, domain, or Dataflows Gen2 workspace configuration before editing individual artifacts
Team needs reviewed changes and controlled promotion	Git integration, database project, deployment pipeline	Separate source review, schema lifecycle, and stage promotion
User can access an item but should not see all data	Fine-grained security control	Use row, column, object, file, folder, or masking control instead of broad workspace role changes
Process must run automatically with runtime values	Pipeline trigger, parameters, dynamic expressions	Use pipeline orchestration for schedules, event starts, dependency paths, and parameter passing

flowchart LR  
    A[Workspace defaults] --> B[Item configuration]  
    B --> C[Security and governance layer]  
    C --> D[Orchestration runtime]  
    D --> E[Run history and validation evidence]  

Configure Microsoft Fabric workspace settings for Spark, OneLake, Dataflows Gen2, and domains

Exam Radar

• Core Priority: Workspace settings define the default execution and governance envelope before any lakehouse, warehouse, pipeline, notebook, or dataflow runs. DP-700 scenarios often ask which workspace-level control should be changed when every item in the workspace inherits the same Spark runtime, OneLake behavior, domain association, or Dataflows Gen2 behavior.
• High Frequency: Expect scenario questions where a team has a correct notebook or pipeline but receives inconsistent execution, storage, or governance behavior because the workspace defaults were not aligned first.
• Confusion Alert: A common distractor is changing item-level settings when the symptom is caused by a workspace-level default. Another distractor is changing tenant settings when the question limits the scope to one workspace.
• Scenario Logic: If multiple engineering artifacts in the same workspace need the same Spark runtime or storage policy, inspect the workspace setting before editing each artifact. If only one notebook or item is affected, item-level configuration becomes more plausible.
• Version Delta: The current Microsoft study guide lists Spark workspace settings, domain workspace settings, OneLake workspace settings, and Dataflows Gen2 workspace settings under this domain as of April 20, 2026.
• Failure Trigger: Misaligned settings produce repeated Spark session configuration drift, wrong domain classification, unsupported shortcut behavior, or Dataflow Gen2 staging and refresh inconsistency.
• Operational Dependency: Workspace admins or users with sufficient workspace permissions must be able to access workspace settings; tenant-level Fabric settings may also constrain what a workspace can enable.
• How the Exam Asks It: The stem usually gives a repeated behavior across several Fabric items and asks for the lowest-scope configuration change.
• How Distractors Are Designed: Wrong options often use a lakehouse table property, notebook code change, or pipeline activity edit even though the issue begins before item execution.
• Why the Correct Answer Works: The correct answer changes the shared control object that owns the repeated behavior.

Practice Question: A Fabric data engineering team uses several notebooks in one workspace. Each notebook should use the same Spark runtime and capacity-related defaults, but engineers keep editing session settings manually. What should the data engineer configure first?
A. Modify every notebook cell that creates a Spark session.
B. Configure the Spark workspace settings for the Fabric workspace.
C. Create a deployment pipeline and promote the notebooks.
D. Apply a sensitivity label to the lakehouse.
Correct Answer: B.
Explanation: B is correct because the repeated runtime behavior is owned by the workspace Spark settings. A is fragile and item-by-item. C manages lifecycle movement but does not set runtime defaults. D governs classification and protection, not Spark execution. Exam Takeaway: When the symptom repeats across items, choose the shared workspace control; the distractor pattern is an item-level fix for a workspace-level dependency.

Atomic Deconstruction - Operational Level

Fabric workspace settings act as the control-plane starting point for data engineering work. Spark settings determine runtime defaults that affect notebook and Spark job execution. OneLake settings affect how storage and shortcuts behave inside the workspace boundary. Domain settings connect workspace content to enterprise data-domain organization. Dataflows Gen2 settings affect data preparation behavior and refresh handling.

The operational rule is to identify ownership of the behavior. A Spark runtime mismatch is not fixed by changing a SQL warehouse. A domain governance issue is not fixed by optimizing a Delta table. A OneLake shortcut problem is not solved by changing a pipeline retry count. Each setting satisfies a different dependency: execution runtime, storage namespace, governance classification, or data-preparation behavior.

Skipping workspace configuration creates downstream noise. Notebooks may run with unexpected defaults, artifacts may be organized outside the intended domain, and refresh settings may vary by author. The exam rewards the candidate who checks the controlling workspace object before tuning a downstream artifact.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
Fabric workspace	Spark settings	Runtime, environment, capacity behavior supported by Fabric	Workspace default	Workspace admin rights and Fabric tenant enablement	Notebooks run with inconsistent runtime behavior
Fabric workspace	Domain assignment	Available Fabric domains	Unassigned or tenant default	Domain governance configuration	Items are not organized under the expected data domain
OneLake workspace configuration	Storage and shortcut behavior	Supported OneLake options	Workspace inherited behavior	OneLake availability and workspace permissions	Shortcut resolution or storage access errors persist
Dataflows Gen2 workspace setting	Refresh and staging behavior	Supported Dataflows Gen2 options	Service defaults	Data Factory workload availability	Dataflow refresh behavior does not match workspace standards

Step-by-Step Execution Path

1. Open the Fabric portal and navigate to Workspaces > target workspace > Workspace settings. This is first because the scenario symptom applies to the whole workspace.
2. Inspect Spark settings, OneLake settings, domain settings, and Dataflows Gen2 settings. This separates execution, storage, governance, and preparation dependencies before changing individual items.
3. Confirm the user has workspace admin or equivalent permission. A missing permission can make the correct setting invisible and mislead the operator into editing downstream artifacts.
4. Apply the setting that owns the symptom. Use Spark settings for runtime defaults, domain settings for domain association, OneLake settings for storage behavior, and Dataflows Gen2 settings for dataflow behavior.
5. Re-run or refresh one representative item and compare the observed behavior with the expected setting. This validates inheritance without creating broad production churn.

Verification evidence can include official Fabric portal evidence, workspace setting screenshots, item execution status, or supported management API evidence when available for the relevant Fabric version.

Technical Chain

The workspace setting is stored as control-plane metadata. When a notebook, dataflow, pipeline, or lakehouse operation starts, Fabric resolves workspace context before the item operation executes. If the workspace default supplies the runtime or governance property, the item receives that behavior without every artifact restating it. If the default is wrong, each downstream artifact can appear broken even though the item definition is valid. Correcting the workspace metadata changes the dependency that the item resolves at execution or organization time.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Validate workspace-level ownership	Fabric portal > Workspaces > target workspace > Workspace settings	Setting category matches the repeated symptom across items
Confirm Spark default behavior	Fabric portal > Workspace settings > Spark settings, then run representative notebook	Notebook starts with the expected Spark configuration
Confirm domain assignment	Fabric portal > Workspace settings > Domain	Workspace appears under the intended domain context
Confirm Dataflows Gen2 behavior	Fabric portal > workspace Dataflow Gen2 item > refresh history	Refresh uses the expected workspace-supported behavior

Implement lifecycle management with Git integration, database projects, and deployment pipelines

Exam Radar

• Core Priority: Lifecycle management controls how Fabric engineering assets move from development to test and production without uncontrolled manual edits.
• High Frequency: DP-700 scenarios ask whether to use version control, database projects, or deployment pipelines when a team needs repeatable release promotion.
• Confusion Alert: Git integration tracks source changes; deployment pipelines promote Fabric content between stages; database projects support database object development. They are related but not interchangeable.
• Scenario Logic: If the requirement is code history and pull-request review, choose version control. If the requirement is stage promotion, choose deployment pipelines. If the requirement is database schema source management, choose database projects.
• Version Delta: The current guide explicitly includes configuring version control, implementing database projects, and creating deployment pipelines.
• Failure Trigger: Manual production edits, unreviewed schema drift, or promotion from the wrong stage.
• Operational Dependency: Workspace items must be supported by the lifecycle feature, and the user must have permissions in both Fabric and the linked source-control or pipeline stage.
• How the Exam Asks It: The question gives a release-governance objective and asks which Fabric lifecycle control satisfies it.
• How Distractors Are Designed: Distractors often use refresh schedules, sensitivity labels, or workspace roles even though the issue is change movement.
• Why the Correct Answer Works: The correct feature owns the change-control boundary named in the requirement.

Practice Question: A team needs developers to review notebook and pipeline changes before those changes are promoted to a production workspace. What combination best supports this requirement?
A. Workspace viewer permissions and manual item export.
B. Git integration for review plus deployment pipelines for stage promotion.
C. Dynamic data masking and audit logs.
D. A OneLake shortcut from production to development.
Correct Answer: B.
Explanation: B is correct because Git supports reviewable source changes and deployment pipelines promote content across stages. A lacks controlled release movement. C supports security and audit evidence, not lifecycle promotion. D creates storage linkage and can increase risk. Exam Takeaway: Match review to version control and promotion to deployment pipelines; distractors usually solve security or storage instead of release control.

Atomic Deconstruction - Operational Level

Lifecycle management starts by separating authoring, review, and release. Git integration records item definitions and enables review workflows outside the live production workspace. Deployment pipelines provide a Fabric-native promotion path between stages. Database projects let warehouse or SQL database schema work be treated as a source-managed engineering asset rather than an undocumented production edit.

The why-layer is control of state. A production workspace should not be the first place a change exists. A Git branch or database project captures the intended definition. A deployment pipeline moves a tested definition into a higher stage. Without this sequence, production may contain a mixture of manual changes, stale dependencies, and untraceable object versions.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
Git integration	Connected branch and folder	Supported provider and branch path	Not connected	Repository access and workspace permissions	Changes cannot be reviewed or traced
Deployment pipeline	Stage mapping	Development, test, production-style stages	No pipeline	Supported item types and stage workspace access	Wrong artifact version is promoted
Database project	Schema object definition	Tables, views, procedures, security objects supported by project tooling	External to Fabric item until configured	SQL development workflow and source repository	Schema drift or missing dependency appears during deployment
Fabric item	Deployment status	Same, different, missing, unsupported	Uncompared	Pipeline comparison metadata	Promotion skips required dependency or overwrites unexpected changes

Step-by-Step Execution Path

1. Identify the release boundary: source review, schema management, or stage promotion. This prevents choosing a lifecycle feature by product familiarity instead of requirement ownership.
2. Configure Git integration for the development workspace when code review and history are required. Use the Fabric portal path for workspace Git integration and validate provider, branch, and folder selection.
3. Put database object definitions into a database project when the requirement names warehouse or database schema lifecycle. Validate that object dependencies are included before promotion.
4. Create a deployment pipeline and assign workspaces to stages when the requirement is controlled movement from development to test or production.
5. Compare stages before deployment. The comparison is the checkpoint that exposes missing, changed, or unsupported items.
6. Deploy only after dependencies are visible and expected. Use deployment history or item comparison status as evidence.

Supported verification should come from Fabric portal Git status, deployment pipeline comparison, deployment history, source-control review records, and database project build or validation output for the active tooling version.

Technical Chain

A developer changes an item definition in the development workspace. Git integration serializes supported item metadata to a repository branch, where review and history occur. When approved, the Fabric deployment pipeline compares the source stage and target stage. The pipeline then applies supported item changes into the target workspace. If a database object is managed through a project, the schema definition is validated before it becomes target state. Incorrect lifecycle selection breaks the chain: Git alone does not promote stages, and a deployment pipeline alone does not provide branch review semantics.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Validate Git connection	Fabric portal > Workspace settings > Git integration	Repository, branch, and sync status are visible
Validate stage differences	Fabric portal > Deployment pipelines > Compare	Expected changed, new, or missing items are listed
Validate promotion history	Fabric portal > Deployment pipelines > Deployment history	Target stage shows successful deployment for expected items
Validate database project readiness	Supported database project build or validation output	Schema objects compile and dependency errors are absent

Configure security and governance across workspace, item, row, column, object, file, labels, endorsement, and audit logs

Exam Radar

• Core Priority: Security in Fabric is layered. The exam tests whether the candidate chooses the lowest effective control for the protected object and evidence requirement.
• High Frequency: Questions often combine workspace access, item sharing, row-level security, column-level security, object-level security, folder or file permissions, dynamic data masking, sensitivity labels, endorsement, and audit logs.
• Confusion Alert: Workspace role assignment is not the same as row-level security. Sensitivity labels classify and protect data but do not replace access control. Endorsement signals trust but does not grant permission.
• Scenario Logic: Start with the protected boundary. Use workspace access for workspace membership, item access for individual artifacts, row or column controls for query result shaping, labels for classification, endorsement for trust, and audit logs for investigation.
• Version Delta: The current guide includes Fabric audit logs and multiple fine-grained control levels.
• Failure Trigger: Overbroad workspace roles, missing item permission, visible sensitive columns, masked values expected but not applied, or no audit evidence for access investigation.
• Operational Dependency: Microsoft Purview, tenant settings, item support, and identity configuration may affect which governance features are available.
• How the Exam Asks It: The stem names a security outcome and asks for the Fabric feature that enforces or proves it.
• How Distractors Are Designed: Wrong answers frequently use classification for access enforcement or endorsement for data protection.
• Why the Correct Answer Works: The correct answer maps to the enforcement or evidence layer that owns the named behavior.

Practice Question: Analysts can query a warehouse table but must not see full values in a sensitive column. They should still be able to run aggregate reports. Which control is most directly aligned?
A. Dynamic data masking or column-level protection supported by the warehouse scenario.
B. Workspace Admin role removal for every analyst.
C. Endorse the item as certified.
D. Create a deployment pipeline.
Correct Answer: A.
Explanation: A is correct because the requirement targets sensitive column visibility while preserving analytical access. B is overbroad and may remove required access. C signals trust but does not mask values. D controls release movement, not query-time data exposure. Exam Takeaway: Choose query-result controls for visible data shape; the distractor pattern is governance metadata used as if it were enforcement.

Atomic Deconstruction - Operational Level

Fabric security decisions begin with scope. Workspace roles define broad authoring and consumption boundaries. Item-level access grants access to a specific lakehouse, warehouse, semantic model, notebook, pipeline, or other item. Row-level, column-level, object-level, and folder/file-level controls narrow what an authorized user can see or query. Dynamic data masking changes visible values for supported objects without redesigning the table. Sensitivity labels apply classification and protection metadata. Endorsement tells users which items are promoted or certified. Audit logs provide evidence of access and administrative activity.

The dependency is identity-to-object evaluation. A user first needs an identity and a permission path. Then the query or item operation evaluates fine-grained rules. Labels and endorsement add governance signals, while audit logs record activity. If the wrong layer is chosen, the user either receives too much access, no access, or only a label with no enforcement.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
Workspace role	Member capability	Admin, Member, Contributor, Viewer-style roles	No role unless assigned	Microsoft Entra identity and workspace permission	User cannot access workspace or receives excessive authoring rights
Item permission	Artifact access	Read, build, share, edit-style permissions by item	Not shared	Item owner or workspace role	User can access workspace but not target item
Row-level security	Predicate logic	User or group filtered rows	Not applied	Supported engine and identity mapping	User sees rows outside allowed segment
Dynamic data masking	Masking rule	Supported mask formats by data store	Unmasked	Supported warehouse or SQL object feature	Sensitive values appear in query output
Audit log	Activity event	User, operation, item, timestamp	Captured when auditing is enabled and available	Microsoft Purview audit capability and permissions	Investigation lacks authoritative event evidence

Step-by-Step Execution Path

1. Classify the requirement as access, data-shaping, classification, trust, or evidence. This prevents applying labels when the requirement demands enforcement.
2. Check workspace membership and role. If the user cannot reach the workspace, fine-grained controls never execute.
3. Check item permission. If only one artifact is required, item sharing can avoid overbroad workspace role assignment.
4. Apply row, column, object, folder, file, or masking controls when the user should access the item but not all data inside it.
5. Apply sensitivity labels when the question asks for classification, protection metadata, or compliance marking.
6. Use endorsement when the question asks users to identify trusted content.
7. Use audit logs when the question asks who accessed or changed an item.

Evidence should come from Fabric permission dialogs, supported SQL security definitions, item access views, Microsoft Purview sensitivity label state, endorsement badge state, and Microsoft Purview audit search results.

Technical Chain

When a user opens or queries a Fabric item, Fabric evaluates workspace membership and item permission before the engine returns data. If the engine supports row, column, object, masking, folder, or file controls, those rules shape the returned result or accessible object set. Sensitivity labels and endorsement are evaluated as governance metadata and user signals, not as substitutes for permission checks. Audit events are emitted from the service activity path so an investigator can reconstruct who performed the operation and when.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Validate workspace role	Fabric portal > Workspace > Manage access	User or group has the intended role only
Validate item access	Fabric portal > Item > Manage permissions	Target identity has only required item permission
Validate row or column behavior	Run supported query as test identity	Result contains only allowed rows or protected columns
Validate audit evidence	Microsoft Purview audit search for Fabric activity	Event includes user, item, operation, and timestamp

Orchestrate processes with Dataflows Gen2, pipelines, notebooks, schedules, triggers, parameters, and dynamic expressions

Exam Radar

• Core Priority: Orchestration questions test whether the candidate can select the right Fabric execution vehicle and connect activities with parameters, schedules, triggers, and dynamic expressions.
• High Frequency: Expect comparisons between Dataflows Gen2, pipelines, and notebooks for transformation, movement, and code-driven processing.
• Confusion Alert: Dataflows Gen2 is not a general workflow orchestrator. Pipelines coordinate activities. Notebooks run code-heavy Spark or data engineering logic.
• Scenario Logic: Choose Dataflows Gen2 for low-code data preparation, pipelines for orchestration and activity coordination, and notebooks for code-driven Spark transformations or custom logic.
• Version Delta: The current guide explicitly includes schedules, event-based triggers, notebooks, pipelines, parameters, and dynamic expressions.
• Failure Trigger: Hardcoded paths, wrong trigger type, missing parameter binding, or a notebook that runs manually but fails inside a pipeline.
• Operational Dependency: Pipeline activities must pass parameters in the format expected by the target notebook, dataflow, or activity. Trigger identity and schedule state must be enabled.
• How the Exam Asks It: The stem describes an automated data process and asks which artifact or configuration makes it repeatable.
• How Distractors Are Designed: Wrong answers choose a transformation tool when the need is orchestration, or choose a schedule when the requirement is event-based.
• Why the Correct Answer Works: The correct answer owns the process-control requirement rather than only the transformation logic.

Practice Question: A lakehouse load must run every night, pass the processing date into a notebook, and stop if the validation activity fails. Which Fabric object is the best orchestrator?
A. Dataflow Gen2 only.
B. A pipeline with a schedule trigger, notebook activity parameter, and dependency conditions.
C. A sensitivity label on the lakehouse.
D. A OneLake shortcut to the source.
Correct Answer: B.
Explanation: B is correct because the pipeline owns scheduling, parameter passing, and activity dependency flow. A can transform data but does not model the full dependency chain as directly. C is governance metadata. D affects storage reference, not orchestration. Exam Takeaway: When the scenario includes multiple activities and control flow, choose a pipeline; distractors usually focus on one data object instead of the process chain.

Atomic Deconstruction - Operational Level

A Fabric orchestration design has three decisions: execution vehicle, trigger, and runtime parameterization. Dataflows Gen2 handles many low-code ingestion and shaping tasks. Pipelines coordinate activities, dependencies, triggers, and failure paths. Notebooks handle programmable Spark logic, libraries, and custom validation. Parameters remove hardcoded environment and date values; dynamic expressions bind runtime values to activity inputs.

The why-layer is repeatability. A process that depends on manual date edits or manual notebook execution is not operationally stable. A schedule or event trigger starts the process. A pipeline passes parameter values. Dependency conditions prevent downstream writes after validation failure. Without these controls, a technically correct transformation can run at the wrong time, against the wrong partition, or after a failed upstream step.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
Pipeline	Activity graph	Copy, notebook, dataflow, script, validation-style activities	Empty until authored	Data Factory workload and item permissions	Activities run out of order or not at all
Trigger	Schedule or event condition	Time-based or supported event-based trigger	Disabled or not configured	Workspace and trigger permissions	Process requires manual start
Notebook activity	Parameter binding	Name-value parameter map	No runtime value	Notebook parameter handling	Notebook runs with wrong date, path, or environment
Dynamic expression	Runtime value resolution	Supported expression language	Literal value	Activity metadata and parameter scope	Hardcoded or invalid expression breaks run
Dependency condition	Success, failure, completion, skipped paths	Activity outcome states	No explicit branch	Upstream activity output	Invalid data is written after failed validation

Step-by-Step Execution Path

1. Decide whether the primary need is transformation or coordination. If the requirement includes branching, scheduling, or multiple activities, start with a pipeline.
2. Add the ingestion, notebook, dataflow, validation, and write activities in dependency order. This ensures upstream state exists before downstream execution.
3. Define pipeline parameters such as processing date, source path, target environment, or batch identifier.
4. Bind parameters to notebook or activity inputs with dynamic expressions. Validate spelling and scope because a wrong parameter name can produce a runtime failure.
5. Configure success and failure paths. Put quality checks before target writes so invalid data does not become committed output.
6. Configure a schedule or event-based trigger based on the requirement wording. Enable it only after a manual test run succeeds.
7. Inspect pipeline run history and activity outputs after execution.

Use Fabric pipeline run history, activity input/output panes, notebook run status, Dataflow Gen2 refresh history, and trigger state as evidence.

Technical Chain

A trigger creates a pipeline run. The pipeline runtime resolves parameters and dynamic expressions, then schedules activities according to dependency conditions. When the notebook activity starts, it receives runtime values instead of hardcoded constants. Validation output determines whether downstream activities execute. A wrong parameter binding breaks the chain at activity start; a missing dependency condition lets downstream writes run even when upstream validation failed.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Validate trigger state	Fabric portal > Pipeline > Triggers	Trigger is enabled and matches required schedule or event
Validate parameter binding	Fabric portal > Pipeline activity > Settings > Parameters	Parameter names match the called item requirements
Validate dependency path	Fabric portal > Pipeline canvas dependency conditions	Downstream activity runs only on intended status
Validate execution evidence	Fabric portal > Pipeline > Run history > Activity output	Each activity shows expected input, output, and status