Maintain the analytics development lifecycle

Objective coverage

• Configure version control for a workspace
• Create and manage a Power BI Desktop project (.pbip)
• Create and configure deployment pipelines
• Perform impact analysis of downstream dependencies from lakehouses, warehouses, dataflows, and semantic models
• Deploy and manage semantic models by using the XMLA endpoint
• Create and update reusable assets, including Power BI template (.pbit) files, Power BI data source (.pbids) files, and shared semantic models

From a local change to a trusted release

A release is more than moving a report between workspaces. An analytics solution contains definitions, dependencies, credentials, data, permissions, and user expectations. Different tools manage different parts of that system. Git records reviewable definitions. Deployment pipelines promote supported items. XMLA tools manage semantic-model metadata and processing. Impact analysis helps identify consumers that require validation. A release succeeds when those pieces agree in the target environment.

Northstar's running example introduces a Net Revenue measure while renaming a staging column. Development uses fabricated records. Test uses an approved representative dataset. Production supports a monthly close process. The team must show that the changed model produces the intended results, that downstream reports still work, and that access remains correct. A green synchronization notification establishes only one step of that evidence.

Configure version control for a workspace

A Fabric workspace is a live authoring surface, while a repository represents supported item definitions in a reviewable history. Connecting the workspace to a branch does not make every portal change an approved release. Commit to Git moves supported definitions from the workspace toward the repository; update from Git applies repository definitions to the workspace. The direction matters because either operation can overwrite assumptions about which state is authoritative. Data, credentials, and unsupported properties require separate handling.

Confirm provider support, repository access, workspace permissions, and the supported item types. Connect a development workspace to the intended branch and folder. Inspect the initial synchronization carefully; do not overwrite valuable content simply to reach a clean status. Make a focused change, inspect the exported diff, validate it, and use the team's pull-request review process. Resolve conflicting workspace and branch changes deliberately. After updating the workspace, check dependent items and environment-specific bindings. Keep secrets outside source control and document the deployment steps that Git cannot carry.

An analyst changes a report title in the workspace while an engineer changes a measure on the branch. The workspace status shows that both sides changed. The team compares the definitions instead of blindly synchronizing. It retains the title improvement and the approved measure, tests them together, and records the merged definition. If a connection still points to the development warehouse after promotion, the repository history may be entirely correct: the missing work is environment binding. The test must query the target data and verify its identity, not merely compare filenames.

A clean Git status means the supported synchronized definitions agree; it does not establish data quality, service credentials, or all runtime configuration. Investigate missing items by checking support and scope before assuming they were deleted. Investigate conflicts by comparing changes from both directions. For recovery, identify the last known good definition and the target environment state before applying it. Reverting a measure does not automatically reverse a data transformation or restore a removed column. In the exam, source review and environment promotion are complementary lifecycle concerns.

Scenario: A workspace update from Git succeeds, but a refreshed report reads development data in Test. Where should the release investigation focus?

Answer: Inspect the target connection and binding configuration, supported deployment rules, and effective credentials. The successful update confirms definition synchronization, not the correctness of the target data source. Validate Test-specific row counts and a known environment marker after correcting the binding.

Recall: Which direction does commit to Git move changes? Why is reverting a repository commit insufficient evidence that production has been rolled back?

Create and manage a Power BI Desktop project (.pbip)

A Power BI Desktop project represents report and semantic-model definitions in a folder structure suitable for source control and collaboration. The small project entry file points to those artifacts; it is not the entire solution. Text-based definitions make changes easier to inspect than a single binary file, but they still need semantic validation. A syntactically valid definition can reference a removed column or change a measure's meaning. Treat local caches and machine-specific state differently from the definitions the team intentionally versions.

Use a supported Power BI Desktop version and confirm any feature settings required by its current project format. Save a project into a deliberate repository folder. Review the generated report and model directories, ignore rules, and any local-only files before committing. Make one small measure or visual change and inspect the diff to learn which artifacts carry it. Reopen the project, refresh or connect using authorized credentials, and validate the report. During collaboration, agree on tool versions and avoid concurrent edits to the same model objects when possible.

Northstar changes Net Revenue from gross amount to gross less returns. The developer saves the project, reviews the measure-definition diff, and commits only the intended model change. A teammate pulls the commit, opens the project, and tests three fabricated transactions: a sale, a return, and a zero-value transaction. The measure should return the agreed result for both a single region and the overall total. If the teammate copied only the .pbip entry file without the model folder, the project is incomplete even though the filename looks correct.

Text files can merge mechanically while introducing semantic conflicts. One branch may rename a measure that another branch adds to a visual. Review dependent references, not only conflict markers. Do not commit credentials, cached private data, or incidental user settings simply because they appear near project definitions. A project file is also different from a template: PBIP supports ongoing source-based authoring, while PBIT packages a reusable starting definition. Check format support when moving between Desktop versions or automated tools; do not assume arbitrary text edits are supported authoring operations.

Scenario: A repository contains only Sales.pbip. A second developer cannot open its semantic model. What is the likely packaging error?

Answer: The entry file references project artifacts that were not included. Commit the intended report and model definition folders with supported ignore rules, then test a clean checkout. Recreate local connection settings through the authorized workflow instead of checking secrets into Git.

Recall: Why are a readable diff and a passing report test both necessary? What distinguishes project definitions from local caches?

Create and configure deployment pipelines

Deployment pipelines organize promotion across stages such as Development, Test, and Production. They help compare and deploy supported artifacts between assigned workspaces. Stage progression is an environment-management mechanism, not a guarantee that all dependencies, data, or access policies have been copied. A deployment can succeed while a model points to the wrong source, lacks valid credentials, or exposes a changed calculation that no reviewer has checked. Define a release's runtime acceptance criteria before pressing Deploy.

Assign authorized workspaces to stages and verify item support. Establish target connection rules and parameters where supported. Compare the selected content and its dependencies, then deploy to Test. Configure target-specific prerequisites such as credentials and gateway mappings through the supported interfaces. Refresh or frame the model as appropriate for its storage mode. Test known measures, report interactions, security personas, and source identity. Promote to Production only after the same checks are satisfied there. Record rollback definitions and any data compatibility constraints.

Development has a Warehouse named SalesDev and Test has SalesTest. A report uses a semantic model with a revenue measure. The deployment plan includes the model and report plus the supported rules that select the Test connection. After promotion, the tester checks a synthetic Test-only row whose value is 17. The report must include that marker in the expected filtered result and must exclude a Development-only marker. This discriminating test detects wrong bindings that a generic nonempty report would miss. The pipeline status alone cannot prove it.

Cross-workspace dependencies and unsupported settings deserve explicit attention. A selected report may depend on a shared model that is intentionally managed by another release. Decide whether it should continue using that shared dependency or bind to a stage counterpart, then verify actual behavior. If a deployment fails, inspect the reported item and prerequisite rather than retrying every item indiscriminately. If it succeeds but results differ, inspect source binding, refresh state, calculation changes, and effective user permissions. Promotion is not equivalent to loading production data or granting every consumer access.

Scenario: Test passes after deploying a model and report, but Production shows old results. Which evidence separates a deployment problem from a refresh problem?

Answer: Compare the deployed model definition and binding with the approved release, then inspect refresh or framing history and source data availability. A current measure definition with stale imported data requires a data-refresh investigation; an old definition requires a deployment investigation. Check both before repeating the release.

Recall: What does a successful deployment establish? Why should a target-specific marker be more informative than a nonempty visual?

Perform impact analysis of downstream dependencies from lakehouses, warehouses, dataflows, and semantic models

Impact analysis helps reveal which downstream artifacts and workspaces may be affected by a change. It supports planning and communication; it does not run every dependent query or prove complete dependency discovery. Lineage establishes relationships between known items. Impact assessment asks which of those relationships matter for the proposed change. Removing a table, renaming a column, changing a refresh schedule, and changing a measure's accounting definition can have different consequences even when they affect the same lineage graph.

Identify the item and exact proposed change. Open its supported lineage or impact-analysis view and inspect direct children and further downstream items where available. For data sources whose view shows direct children, continue analysis from those children. Record the owners and critical consumers, respecting visibility and permissions. Classify the change as compatible, behavior-changing, or breaking. Prepare a migration or compatibility period when necessary, and validate representative dependent reports and transformations in Test. Communication is part of a release plan, but actual notifications should follow the team's authorized process.

Northstar wants to rename CustomerCode to CustomerBusinessKey in a warehouse. The warehouse feeds a dataflow, which supplies a shared semantic model, which supports three reports. Merely checking the model's visual fields misses the dataflow's transformation expression. The release adds a compatible alias first, updates consumers, verifies refreshes and totals, and removes the old name only after ownership and usage are understood. The graph tells the team where to investigate; reading definitions and testing the change determine whether the rename is safe.

Limited visibility is not evidence that no dependencies exist. A developer may see only the items their identity can inspect. External clients, exported data, or dynamically constructed references may also require an owner-maintained inventory. When the graph and observed usage disagree, preserve the uncertainty and investigate rather than declaring the item unused. For the exam, impact analysis is the appropriate starting point before changing a shared artifact; it is distinct from monitoring past failures and from deploying the change itself. Notification alone does not repair a broken dependency.

Scenario: A data source's impact view shows one dataflow, but users report that several reports depend on it. Is the single child proof that only one item needs testing?

Answer: No. Continue downstream analysis from the dataflow and its dependent model, include the report owners, and inspect dependencies outside the visible graph when relevant. Test the transformation and model as well as the final reports before removing the old source contract.

Recall: How does a rename differ from adding an unused nullable column? Why might two users see different amounts of dependency information?

Deploy and manage semantic models by using the XMLA endpoint

The XMLA endpoint exposes supported semantic-model connectivity and management operations to tools that understand tabular models. Read access supports inspection and queries; write operations can change metadata or processing state when the capacity and model permissions allow them. XMLA is not a warehouse SQL endpoint and not a replacement for every Power BI deployment workflow. Its value is precise model management: inspecting partitions, deploying supported metadata changes, and processing selected portions of a model with appropriate tools.

Confirm that the workspace and capacity support the required XMLA operation and that endpoint settings permit the intended read or read/write access. Use an authorized identity with the required model permissions. Connect to the workspace endpoint and inspect the target model before changing it. Export or retain a known good definition, compare the proposed change, and test against a nonproduction model. Decide explicitly whether the operation changes metadata, processes data, or both. Validate queries, partitions, security roles, and downstream reports after the operation.

An imported Sales model contains monthly partitions. A late accounting correction affects one historical month outside the normal incremental refresh window. An authorized operator identifies the affected partition, validates that the source contains the corrected data, and uses a supported XMLA management tool to process the required partition. The operator then compares that month's total and the annual total with the expected adjustment. This is more targeted than reloading every year, but it requires a clear understanding of partition boundaries and processing dependencies.

A metadata deployment can inadvertently replace partition definitions or trigger unwanted processing if the tool's options are misunderstood. Inspect the operation before execution and preserve a recovery path. Do not promise that every model changed through XMLA can subsequently be downloaded and edited through every Desktop workflow; check current tool limitations. If connection succeeds but a write fails, inspect endpoint write configuration and effective model permissions. If processing succeeds but the measure is wrong, examine source boundaries and model logic rather than repeatedly processing the same partition.

Scenario: A tool can query a semantic model through XMLA but cannot deploy a measure change. What two permission layers should be checked?

Answer: Check whether the capacity's XMLA endpoint permits read/write operations and whether the connecting identity has the required write capability on the target model. Test on a nonproduction model and verify the exact target before retrying. Read connectivity alone does not establish write authorization.

Recall: How is processing a partition different from changing a measure definition? Why can replacing partition metadata damage an incremental-refresh design?

Create and update reusable assets, including Power BI template (.pbit) files, Power BI data source (.pbids) files, and shared semantic models

Reusable artifacts support different kinds of reuse. A PBIT template packages report and model definitions as a starting point without packaging the imported dataset itself. A PBIDS file describes a supported data connection that helps a user begin connecting from Desktop; it does not carry a complete model, report, or credential grant. A shared semantic model centralizes relationships, measures, and security so that multiple reports can use the same governed logic. Choose the artifact based on what should remain shared after creation.

For a template, remove accidental sensitive metadata, define useful parameters, export the supported template, and test opening it with new connection inputs. For PBIDS, describe the supported connection and test the authentication and navigator experience with a representative user. For a shared model, establish ownership, Build permissions for authors, consumer security, refresh responsibilities, and a change process. Validate updates against downstream reports. Reusing a file creates another copy of definitions; reusing a shared model keeps consumers attached to an evolving common contract.

Northstar franchises need the same report layout but maintain independent databases. A parameterized template can seed their separate reports, provided each organization supplies its own authorized connection. Corporate reporting needs one centrally defined recognized-revenue calculation, so several corporate reports connect to a shared model instead. A PBIDS file can make choosing an approved warehouse connection easier, but it cannot replace either the template's visuals or the shared model's measures. Updating the original PBIT does not automatically update reports previously created from it.

A template contains definitions, parameters, and potentially sensitive names or expressions even when it contains no imported rows. Review it before distribution. A connection descriptor is not a safe place to distribute passwords. A shared semantic model reduces duplicated logic but creates a dependency that requires compatibility discipline and impact analysis. For exam questions, distinguish a starting template, a connection starting point, an editable source project, and a live shared semantic layer. Similar file extensions do not imply interchangeable responsibilities.

Scenario: Five reports must receive the same approved measure correction without independently editing five models. Which reuse pattern fits?

Answer: Place the measure in a governed shared semantic model and connect the reports to it, with appropriate permissions and impact testing. A template would produce separate copies whose measures could drift. A PBIDS file only helps initiate a connection and does not centralize business calculations.

Recall: Why does a PBIT still need a privacy review? Which reuse approach intentionally creates an independent copy rather than a continuing shared dependency?

Shared Fabric foundations

The following field notes adapt this project’s original DP-700 explanations for the shared Fabric foundation. They provide supporting engineering context for the DP-600 objectives above; they do not add separate measured objectives.

Version control field guide

Think of Git integration as a two-sided synchronization contract. One side is the item definition stored in a particular workspace; the other is a folder in a particular repository branch. Fabric calculates a status for supported items by comparing those sides. Commit to Git writes workspace definitions to the connected branch. Update from Git reads branch definitions into the workspace. A branch change made through a pull request does not alter a workspace until an update occurs, and a portal edit is not durable source history until it is committed.

Before connecting, confirm that the tenant and workspace allow Git integration, the user has the required workspace and repository permissions, the provider is supported, and the target branch and directory are intentional. Connect a development workspace—not production—to the chosen branch and folder. After connection, inspect the source-control status, commit only the intended items, and use a pull request to validate and review the resulting definitions. After merge, update the integration workspace from the shared branch and run item smoke tests. Secrets, credentials, data, and every runtime setting are not automatically captured just because an item definition is versioned.

Use one workspace per developer or feature when simultaneous portal authoring would otherwise collide. A shared development workspace is cheaper and simpler, but it increases coordination and makes unrelated changes appear in the same sync operation. Prefer trunk-based development when small changes can merge frequently; use longer-lived stage branches only when the release mechanism truly depends on them. In either model, protect the integration branch and keep the branch-to-workspace mapping explicit. A workspace is a deployment target, not a substitute for a branch.

Worked scenario. Maya changes a notebook in a feature workspace connected to feature/customer-quality. The source-control pane also shows an unrelated pipeline edit made by another user. Maya commits only the notebook, opens a pull request, and CI validates the definition. After approval and merge into main, the team updates the development workspace from main. They then run the notebook against test data. The correct evidence chain is workspace change → feature commit → pull request and CI → merge → workspace update → runtime test. The successful merge alone does not prove the notebook runs in Fabric.

When synchronization fails, first classify the state: workspace-only change, Git-only change, conflict, unsupported item, missing dependency, or permission failure. Preserve both versions before resolving a conflict. Check the connected branch and folder, repository authorization, workspace role, item support, and whether another operation is still running. After an update, diagnose a broken item as a runtime or dependency problem rather than repeatedly syncing it. A useful mini-lab is to change a harmless notebook comment in a feature branch, observe each status transition, resolve a deliberately created conflict, and record which actions affected Git versus the workspace.

Deployment pipeline field guide

A Fabric deployment pipeline is an environment-promotion mechanism. Stages represent lifecycle environments; assigned workspaces hold the live items; pairing relates corresponding items; comparison shows differences; deployment moves supported definitions forward. Deployment rules and variable values can change supported configuration by stage. None of these constructs is a general secret manager, test runner, or source-control review system.

Create the pipeline, define and order its stages, and assign the correct workspace to each stage. Confirm item support and pairing before the first promotion. Configure stage-specific supported rules or variables, then deploy a small coherent set from development to test. Inspect the comparison, run data, permission, refresh, and dependency checks in test, and obtain release approval. Promote the same reviewed definitions to production, complete any documented post-deployment bindings, and run smoke tests under representative identities. Record the source revision, deployment operation, approver, and verification result.

Deploy a dependency set together when a consumer cannot operate safely without its producer; deploy independently when the contract is backward compatible. Use deployment rules for supported environment differences such as connection or parameter values, and a governed secret store or connection mechanism for credentials. Selective deployment reduces blast radius but can produce an inconsistent dependency graph. Full-stage deployment improves consistency but can promote unrelated work. The correct choice follows tested dependency and release boundaries, not convenience.

Worked scenario. A pipeline invokes a notebook that writes to a lakehouse. All three exist in development, but only the pipeline is selected for test. The deployment succeeds and the first run fails because the paired notebook or lakehouse binding is absent. The repair is to compare the dependency set, promote the compatible items, apply the test connection configuration, and rerun. As a mini-lab, document a Dev/Test/Prod matrix containing workspace, capacity, connection, schedule, and owner; promote a harmless parameter change and verify the resolved value at each stage.

If an item is missing from comparison, verify support, workspace assignment, pairing, and whether it resides in the expected stage. If deployment fails, check permissions, capacity state, item dependencies, and concurrent operations. If deployment succeeds but execution fails, move to runtime checks: credentials, gateways, item IDs, shortcut targets, schedules, and data-plane permissions. Rollback might mean redeploying the previous known-good definition or restoring external state; a pipeline has no universal undo for data mutated by a job.

The exam often describes all three lifecycle mechanisms in one scenario. Name the boundary before choosing: review and history point to Git; declarative SQL schema points to a database project; staged Fabric promotion points to a deployment pipeline. “Deployment succeeded” is control-plane evidence only. The strongest answer also verifies dependencies, configuration, permissions, and behavior in the target environment.

Recall and mini-lab. Explain why Update from Git can change a workspace without creating a new Git commit. Describe one schema change a build can validate but cannot prove safe for existing data. List three post-deployment checks for a notebook-to-lakehouse pipeline. Then sketch a release with one feature branch, one pull request, one test promotion, and one intentional failure; label the evidence produced at each gate.

Release scenario drills

Conflicting workspace and branch changes

An engineer edits a notebook in the Fabric portal while another pull request changes the same notebook definition in Git. The workspace now reports a conflict. First preserve and compare both intentions; do not click update or commit merely to clear the status. Decide the winning or combined definition in an isolated branch/workspace, validate it, and use the normal pull-request gate. Then update the integration workspace from the reviewed branch and run the notebook. The conflict resolution is a content decision; synchronization is only the mechanism that applies it.

If the item runs locally but fails after update, inspect runtime, environment, connections, data permissions, and unsupported properties. Git proves the definition and review history, not all external state. Record both Git commit and Fabric run ID so later investigators can connect source to execution.

Safe schema evolution

A warehouse project changes CustomerName varchar(200) to varchar(80) and renames RegionCode to SalesRegionCode. The project builds. That proves the declarations resolve; it does not prove 200-character existing names fit or that publish recognizes the rename instead of drop/create. Generate the deployment plan against a realistic copy, profile maximum length/nulls, and explicitly represent or stage the rename according to supported project tooling. Reject an unreviewed destructive plan.

For a zero-downtime transition, add the new representation, backfill and validate, deploy compatible readers/writers, then remove the old object in a later release. Keep a rollback or restore path and retain the exact artifact and plan. The exam distinction is state-model validation versus safe data migration.

Successful deployment, failed application

A deployment pipeline reports success when promoting a pipeline and notebook to Test. The first execution cannot open the lakehouse. Compare paired items and dependency bindings, then inspect stage-specific connection/variable values, credentials, target permissions, and the execution identity. Deployment rules can adapt supported values but do not supply secrets or grant access.

Repair the narrow missing configuration, rerun a test input, validate target rows and logs, and then record approval. Do not promote to Production because the control-plane deployment succeeded. The gate should require definition deployment plus target-environment smoke tests, data checks, negative permission tests where relevant, and a rollback plan.

Choosing a release mechanism

A team asks for “version control, database validation, and Dev/Test/Prod.” The answer is not one feature. Connect the development workspace to Git for durable definitions, branches, CI, and pull-request review. Build database projects to validate declarative SQL schema and produce reviewed artifacts. Use deployment pipelines or another selected release route to promote supported Fabric items and environment configuration.

Document unsupported items and post-deployment APIs rather than hiding them. The complete release record contains issue/intent, commit and PR, CI results, database artifact and plan where applicable, Fabric deployment operation, configuration evidence, runtime smoke tests, approver, and source revision.

Sources and provenance

The measured objectives follow the DP-600 blueprint effective July 21, 2026. Product references were retrieved for this edition; the book manifest records the actual retrieval time and SHA-256 of each downloaded HTML response. Examples and scenarios are original teaching material. Shared field guides reuse this project’s original DP-700 writing where the underlying Fabric concepts apply. Microsoft Learn remains authoritative, especially for current feature support and capacity limits.

• Study guide for Exam DP-600: Implementing Analytics Solutions Using Microsoft Fabric
• Introduction to CI/CD in Microsoft Fabric - Microsoft Fabric
• CI/CD workflow options in Fabric - Microsoft Fabric
• Power BI Desktop projects (PBIP) - Power BI
• Impact analysis - Microsoft Fabric
• Semantic model connectivity and management with the XMLA endpoint in Power BI - Microsoft Fabric
• Create and Use Report Templates in Power BI Desktop - Power BI
• Data sources in Power BI Desktop - Power BI
• Introduction to Semantic Models Across Workspaces - Power BI