Implement lifecycle management in Fabric

A developer edits a notebook in a Fabric workspace and the change goes live the instant it is saved. Building items that way is the part you already do; what it does not do is record that the edit happened, or carry it to the workspace the finance team actually reports from. Closing those two gaps is what lifecycle management means in Microsoft Fabric, and the objective is really one skill: choosing the right mechanism for a given requirement, and knowing what each one silently leaves behind.

The pages around this one split the domain up. Workspace settings covers the container's own Spark, domain, OneLake, and Airflow configuration; security and governance covers who may read what is inside it. This page covers the items in between: how their definitions are versioned, reviewed, and promoted into production.

The unit that moves is the item definition

A workspace is the collaboration container that holds Fabric items (a notebook, a lakehouse, a pipeline, a warehouse, an eventstream). Every item has a definition, which is the serialized description of what the item is, and separately it may hold data, which is the rows it stores. Fabric lifecycle management moves definitions. It does not move data.

That single rule explains most of the behavior on this page. A deployment copies supported definitions, item relationships, parameters, and data-source metadata, and it deliberately does not copy stored data, item IDs, item URLs, permissions, or workspace settings, so paired items in the target keep the identity they already had (deployment process^[1]). Git behaves the same way. If Git integration recreates an item you deleted, it rebuilds the definition under a new item ID and restores no data, which is why restoring from the workspace recycle bin (original ID plus data) and restoring from Git (new ID, definition only) are different operations that can leave you with two lookalike items (Git integration process^[2]).

Two axes, plus one warehouse-specific path

Microsoft frames the platform as a set of continuous integration and continuous delivery (CI/CD) capabilities layered on the Fabric REST APIs, of which Git integration, deployment pipelines, and the Variable library form the integration and delivery layer (CI/CD in Fabric^[3]). For this exam it helps to see them as two directions of travel:

• Git integration is the vertical axis. It syncs the item definitions of one workspace with one branch of one repository, so work is versioned, reviewable, and revertable.
• Deployment pipelines are the horizontal axis. They promote item definitions from the workspace in one stage, meaning one named position in an ordered release path, to the workspace in the adjacent stage, typically development to test to production. A deployment pipeline is not a Data Factory pipeline: the orchestration item covered on the orchestration page runs activities against data, while a deployment pipeline moves item definitions between workspaces.
• Database projects are the warehouse-specific path. A Fabric Data Warehouse can also be expressed as a SQL project on disk and published into a warehouse, which is how schema changes get compiled, compared, and reviewed before they are applied.

These are complementary, not alternatives. Microsoft's own recommendation is to connect the developer workspace to Git and deploy from that connected workspace with deployment pipelines. Values that have to differ per environment ride alongside both: deployment rules rewrite them on the target item as a deployment lands, and a Variable library holds the per-stage value sets that items reference.

One word collides across pages and is worth pinning down now. On the orchestration page, a parameter is an input fixed for one pipeline run. Here, a parameter is a value stored inside an item definition, which a deployment rule can rewrite as the item lands in a target stage. Same word, two different lifetimes.

Hold onto the split: source control gives you history and review, promotion gives you environments, and neither gives you data. The figure below places both axes on one picture, with the Git branch above the connected development workspace and the stage-to-stage promotion running left to right beneath it.

Connecting, syncing, and disconnecting are Admin-only acts; day-to-day committing and updating are not. Only a workspace Admin can connect a workspace to a repository, disconnect it, or run the sync that establishes the connection; once the connection exists, Members and Contributors with the right permissions do the day-to-day committing and updating (Git integration process^[2]). Getting that split wrong is the most common permissions trap on this objective.

What gets connected to what

Git integration is configured at the workspace level, not per item, and the supported providers are the cloud versions of Azure DevOps, GitHub, and GitHub Enterprise (Git integration overview^[4]). One workspace connects to exactly one branch and one directory at a time. The workspace folder structure is mirrored into the repository, retained up to 10 levels deep.

Only item types on the supported list are versioned. If the workspace or the connected Git directory contains unsupported items, the connection still succeeds and those items are ignored: not saved, not synced, and not deleted. They show in the source control panel with an unsupported status and cannot be committed. Data Engineering items on the supported list include the Environment, Lakehouse, Notebook, Spark Job Definition, GraphQL API, and User Data Functions, among others, and the list also spans Data Factory, Real-Time Intelligence, Data Warehouse, Database, and Power BI item families.

Two item-specific behaviors are worth memorizing because they show up as stems. All new Dataflow Gen2 items are created with CI/CD and Git integration support by default (Dataflow Gen2 with CI/CD^[5]), so the older non-CI/CD creation path is not something you choose your way out of. And an item's schedules travel with it: deploying an item automatically includes its schedules, and Git stores them in a .schedules file inside the item's definition folder (job scheduler^[6], CI/CD for pipelines^[7]). Items that had a schedule configured before CI/CD support arrived show as uncommitted on the first status check, so review that first commit rather than accepting it blindly.

Two permission systems, both of which must say yes

Every Git action is gated twice: once by the Fabric workspace role and once by the role in the repository. The table below is the pairing the exam tests.

Operation	Fabric workspace role	Azure Repos permission
Connect, sync, or disconnect	Admin	Read (none needed to disconnect)
Update from Git	Contributor with write on all items	Read
Commit workspace changes	Contributor with write on all items	Read plus Contribute, and a branch policy that allows the direct commit
Switch branch or check out a new branch	Admin, or Member/Contributor with write on all items when the workspace setting allows it	Read on the target, Create branch to check out a new one
Branch out to another workspace	Admin, Member, or Contributor	Read plus Create branch

The third column is Azure Repos wording. A GitHub fine-grained token expresses the same permissions through Contents access: Read for connecting, syncing, and updating, and Read and write for committing and for creating a branch. The Fabric column is identical either way.

The workspace setting named in that fourth row is Allow users with at least Contributor role to change Git branch. It is off by default, which is why branch switching is an Admin operation until someone turns it on, and even then the Member or Contributor still needs write access to every item in the workspace. Repository write access on its own never substitutes for missing item write access in Fabric.

The initial sync has a direction, and the direction destroys something

When you connect, Fabric makes the two sides match. There are three cases, and only the third asks you anything:

1. The workspace has content and the branch is empty. Content copies to the branch.
2. The branch has content and the workspace is empty. Content copies to the workspace.
3. Both have content. You must choose a direction, and Fabric does not offer a merge. Committing exports all supported workspace content over the current branch content. Updating replaces the workspace content with the branch state.

The asymmetry between those two choices is the point. A Git branch can always be restored to an earlier commit, so overwriting the branch is recoverable. A workspace has no equivalent history, so overwriting the workspace loses that state permanently, and Fabric asks you to confirm before it does. Until you pick a direction you cannot continue working in the workspace. The figure below traces that decision.

Commit, update, and conflict

After the initial sync, three behaviors matter:

• Commit is selective. When several items changed, you choose which ones to commit.
• Update is not selective. Unlike commit and undo, Update from Git always takes the entire connected branch and syncs the workspace to its most recent commit. There is no per-item update.
• A same-item change on both sides is a conflict, and it blocks the update until you resolve it. Resolve it by choosing which version to keep in the source control panel, by resolving it in Git, or by checking out a new branch from the last synced commit, carrying the workspace state onto that branch, and merging back through your normal pull request process (conflict resolution^[8]).

A related trap sits in the folder rules. If the workspace has folders that the connected Git directory does not yet have, the two are considered different and you get an uncommitted-changes status. Commit before you update, because updating first lets the Git folder structure overwrite the workspace structure.

Fabric synchronization is always a replace in one direction. If two divergent states must both survive, Git does the combining and the workspace is updated from the result.

You are the second developer joining a workspace that is already connected to Git, and you need somewhere to work that does not disturb the first developer's live items. Three commands in the Branches tab sound like they might give you that, and only one does. They differ on two questions: which workspace ends up changed, and whether the workspace content changes with it.

Command	Which workspace it affects	Effect on workspace content	Who can run it
Branch out to another workspace	A different, branched workspace (new or reused)	The current workspace is untouched; the branched workspace gets the branch content	Admin, Member, or Contributor
Checkout new branch	The current workspace	Content is unchanged; only the Git connection is repointed	Admin, or Contributor with write on all items when the branch-change setting is on
Switch branch	The current workspace	Every item is overridden with the selected branch's content	Admin, or Contributor with write on all items when the branch-change setting is on

Why branch out is the isolation answer

A workspace is a shared runtime. Everyone with access sees the same live items, and a change one developer saves is immediately visible to the rest. There is no per-user view of a workspace, so a workspace cannot be connected to several branches at once to give each developer their own version of reality. When the requirement says a developer needs to work without disturbing others, the answer is a separate workspace, and Branch out to another workspace is the command that creates one, or reuses an existing branched workspace, connected to a new branch based on the source workspace's last commit (branched workspace^[9]).

Checkout new branch creates a branch from the current workspace's last synced commit and repoints the current workspace at it, without changing what the workspace contains. That is the right move when you cannot commit to the connected branch directly because of a branch policy: check out, commit your workspace state there, then merge through a pull request. It is the wrong move when the requirement was to leave the shared workspace connected where it was.

Switch branch synchronizes the current workspace with a different branch and overrides all its items with that branch's content. It is a replace, not a merge, but uncommitted workspace changes block the switch. Commit first, or branch out instead.

The Related branches list in the same tab is a convenience rather than a fourth operation: it lists branched workspaces and workspaces sharing the same organization, project, repository, and directory, so you can navigate between them without hunting through the workspace list.

The distinction to carry into the exam is that only Branch out produces a second runtime. The other two commands rearrange the connection of the runtime you are already standing in.

Warehouse schema deserves the same review a code change gets, and a database project is how you get it. A database project is a folder of .sql files, one per object, that compiles into a single artifact describing the whole schema; publishing that artifact makes a target warehouse match it. Fabric Git integration already represents a warehouse this way, storing its schema objects as individual SQL files, so the project format and the versioned format are the same format (development and deployment^[10]).

Setting the project up correctly

The setup has three choices that are each a plausible distractor if you get them wrong. Working in Visual Studio Code, install the SQL Database Projects and SQL Server (mssql) extensions plus the .NET SDK, then create the project with:

• Database project type SQL Server Database.
• Target platform Synapse Data Warehouse in Microsoft Fabric. Not Azure SQL Database, not SQL Server.
• SDK-style project, which is the modern project format built on the Microsoft.Build.Sql SDK. Only SDK-style projects are supported for Fabric Data Warehouse (develop warehouse projects^[11]).

You can start from an empty project or from the warehouse you already have. Create Project From Database connects through a warehouse connection profile, whose server name comes from the warehouse's SQL endpoint and takes the form <server unique ID>.datawarehouse.fabric.microsoft.com, and extracts the schema objects into project files. The recommended folder structure is Schema/Object Type, which produces a tree of schemas each holding Functions, Tables, and Views. The extraction pulls object definitions only. It never pulls rows.

Build compiles, publish applies

The two actions are easy to conflate and the exam separates them deliberately.

Build validates every new and modified object definition and compiles them into a .dacpac file (a data-tier application package) under the project's bin folder. Nothing in Fabric changes. Project edits stay local until you publish.

Publish uses DacFx, the Data-Tier Application Framework, to compare the compiled project against the target warehouse, generate the change script that would make the target match, and run it. At the publish prompt you choose an action:

• Generate Script produces the T-SQL for review and applies nothing. This is the answer whenever a stem says a change must be inspected, approved, or reviewed before the target is touched.
• Publish writes the changes to the target warehouse.

Afterwards you can save the options you used into a publish profile (.publish.xml) and reuse it. Keeping one profile per target warehouse is how a single project serves separate development, test, and production warehouses. The figure below follows the whole path from an existing warehouse back into a warehouse.

Two deployment settings that decide whether data survives

Both of these appear in publish options and both are worth memorizing with their recommended values:

Setting	What it does	Recommended use
BlockOnPossibleDataLoss	Stops the deployment when a proposed change risks losing data, such as dropping a populated column or table	Keep True in production; set False only in controlled dev or test environments
DropObjectsNotInSource	Drops objects present in the target but absent from the project	Use for dev or test cleanup; in production it can delete important objects and their data

Read them together and the intent is clear. BlockOnPossibleDataLoss protects you from your own schema change, while DropObjectsNotInSource makes the project authoritative over everything the target contains. Leave the first one set to True. Turn the second one on only where nothing in the target is worth keeping.

Two structural decisions in a Fabric deployment pipeline are permanent, and both are made in the creation dialog: how many stages the pipeline has and what each stage is called. Neither can be changed afterwards. Whether a stage is public can be changed at any time, which is the one structural property that stays editable (deployment process^[1]). A stem describing a two-stage pipeline that now needs a production stage is describing a new pipeline, not a modification.

Getting a workspace into a stage

Content enters a pipeline in one of two ways: you assign an existing workspace to an empty stage, or you deploy into the stage from the neighbouring one. Assignment has a longer checklist in the documentation, and five of its conditions account for most of the distractors (assign a workspace^[12]):

• You are an Admin of the workspace being assigned.
• The workspace resides on a Fabric capacity.
• The workspace is not already assigned to any other deployment pipeline.
• The target stage is vacant. To replace an assigned workspace, unassign the current one first.
• You hold at least Contributor on the workspaces in the adjacent stages.

Unassigning is not free: it discards that stage's deployment history and its configured rules. And a workspace assigned to a pipeline cannot be deleted from workspace settings until it is unassigned.

Pairing is what makes a deploy an update

An item in one stage gets associated with the same item in the adjacent stage, and that association is called pairing. It is the mechanism that decides whether a deployment overwrites or duplicates. When a workspace is assigned to a stage, Fabric attempts to pair items using three criteria in order: item name, item type, and folder location as the tie breaker when a stage holds more than one item of the same name and type. If a single item in each stage matches on name and type, pairing occurs. If duplicates exist and their folders do not match, pairing fails.

From there the deployment outcome follows mechanically:

• Paired item. The target item's content is overwritten while its own ID, URL, and permissions stay unchanged.
• Unpaired item. The deployment performs a clean deploy: it copies the source item into the target and pairs the new copy to its source. A same-named, same-typed item that was created directly in the target is not overwritten just because it looks identical, so you can end up with two lookalike items on separate lines of the pipeline view.
• Renamed item. Renaming does not unpair. Once paired, the association persists, so a later deployment still updates the same target even though the names now differ.

Since folders count as part of an item's name, moving an item between folders in the source shows up as a Different comparison and the paired target item is moved to the matching folder on the next deployment, creating that folder in the target if it does not exist.

Direction, selectivity, and dependencies

Deployments run between adjacent stages only. Forward, you can deploy all supported content or a selected subset (deploy content^[13]). Backward, into the adjacent previous stage, is supported only while that stage is empty. Reaching a non-adjacent stage means running the deployment through the stage in between, never as one hop. A single deployment carries at most 300 items.

Dependencies are resolved by autobinding. When a deployed item depends on another supported Fabric item, the pipeline connects it to the corresponding item in the target stage. If that provider item is neither being deployed nor already present in the target, the deployment fails, which is what the Select related button exists to prevent: it adds the items that provide the dependencies to your selection. Deployments also fail on circular or self-referencing dependencies. The figure below traces both checks in the order the pipeline applies them.

Who can deploy

Pipeline permissions and workspace permissions are granted separately. A pipeline has exactly one permission level, Admin, needed for every pipeline operation including sharing, editing, and deleting. To actually deploy you need to be a pipeline Admin and at least a Contributor in both the source and target workspaces. Being a pipeline Admin alone lets you see and share the pipeline while seeing none of its content.

Before predicting what a deployment will do, settle two questions: are the items paired, and are the required dependencies already in the target. Almost every other behavior in this section follows from those two answers.

A production workspace should not read from the development lakehouse, and a test dataflow should not authenticate with production credentials. Deployment copies definitions faithfully, so without intervention a promoted item keeps pointing wherever its definition said it pointed. Fabric offers three ways to fix that, and they apply at different moments.

The three mechanisms, and when each one runs

Deployment rules run automatically as part of a deployment, changing configuration on the item in the target stage after the copy lands. Rules are configured per stage on the target item, and the supported kinds are data source rules and parameter rules (deployment rules^[14]). Parameter rules used for rebinding must be of type Text. You need to be a pipeline Admin, a Contributor or higher in the target workspace, and the owner of the item you are setting the rule on.

A Variable library is configuration as code that lives in the workspace as its own item and holds per-stage value sets. Items reference a variable instead of hard-coding a lakehouse ID, a connection, or a query fragment, and the release stage decides which value the reference resolves to (Variable library^[15]). Where a deployment rule patches one item at the moment of one deployment, a Variable library centralizes the value so many items across many workspaces resolve it the same way.

Manual configuration in the target is what remains for the things Fabric refuses to copy. Data source credentials are never copied, and the gateway associated with a target item is not automatically mapped to its data source after the first deployment. You configure that mapping on the target item's settings page and confirm a refresh succeeds. Subsequent deployments do not reset it.

The rebinding cases the exam singles out

Most semantic models autobind to the paired item in the target stage. Direct Lake semantic models do not. Direct Lake is the mode in which a semantic model takes a lakehouse or warehouse as its source item, which is exactly why the binding to that source matters here: deploy a lakehouse and its Direct Lake semantic model together and the target-stage model still binds to the lakehouse in the source stage. A datasource rule is the fix, and it is the only fix inside the pipeline; there is no setting that makes Direct Lake autobind. Connections controlled by a parameter also suppress autobinding, so those are rebound by changing the parameter value or by a parameter rule.

Eventstreams have their own version of the problem. After importing or deploying an eventstream whose destination is an eventhouse in Direct Ingestion mode into a different workspace, the connection can need manual reconfiguration (Real-Time Intelligence CI/CD^[16]). Referencing the connection through a Variable library is what reduces that manual work across workspaces.

One more class of item property never travels: semantic model role assignments, refresh schedules for semantic models, data source credentials, query caching settings, and endorsement settings all stay as they were in the target. So does everything at workspace level, including permissions and workspace settings.

Identity and secrets belong to the environment; structure belongs to the definition. Anything environment-shaped is either rewritten by a deployment rule, resolved from a Variable library, or set by hand in the target, and the exam expects you to name which of the three applies.

Everything the portal does, the APIs do, because the whole CI/CD platform is built on the Fabric REST APIs. That is the sentence to hold onto when a stem asks how to make a release run from Azure DevOps or GitHub Actions rather than from a button.

The deployment pipeline REST APIs cover creating, updating, and deleting pipelines, listing stages and their items, managing role assignments, assigning and unassigning workspaces, and deploying stage content (pipeline automation^[17]). Two details on the deploy call matter:

• Deploy Stage Content deploys everything unless you name items. Pass a specific item list for a selective deployment; pass none and all supported items in the stage are deployed.
• Deployment is a long-running operation. When the call returns 202 Accepted, the deployment is still in progress, so automation polls Get Operation State to learn whether it completed, and reads Get Operation Result for the extended outcome, which stays available for 24 hours after completion (long-running operations^[18]). Treating the accepted call as a finished deployment is the classic automation bug this objective tests.

Authentication can be a user principal or a service principal, which is what lets an unattended runner deploy without a signed-in user. Note the current gaps rather than assuming parity with the portal: dataflows are not supported by the Fabric deployment pipeline APIs, and the allowPurgeData, allowTakeOver, and allowSkipTilesWithMissingPrerequisites options exist only in the Power BI pipeline APIs.

Beyond the pipeline APIs, three tools appear in the Fabric CI/CD documentation and are worth recognizing by name and purpose (CI/CD in Fabric^[3]):

Tool	What it is	Typical use
Fabric CLI (fab)	An open-source command-line tool with a filesystem-like interface over Fabric	Scripting Git sync, deployment, and item management inside GitHub Actions or Azure Pipelines
fabric-cicd	A Python library for deploying item definitions from a source-controlled repository	Described by Microsoft as the most widely adopted deployment tool for Fabric CI/CD
Terraform provider for Fabric	Infrastructure as code for Fabric resources	Provisioning workspaces and capacities

Git operations are automatable too: commit, update, and branch operations are exposed through the Fabric REST APIs, and service principal support with the Azure DevOps provider lets a continuous integration job update an integration workspace from Git without a user account.

Automate the release with the pipeline APIs, automate the source-control side with the Git APIs or the Fabric CLI, and poll the operation state rather than trusting the initial response.

The questions on this objective tend to describe a situation and ask for the one operation that satisfies it. Reading them well is mostly a matter of spotting which mechanism the constraint belongs to. This section collects the recurring stems with the reasoning that picks the answer.

Stems about permissions

A Contributor with write access to the repository cannot connect the workspace to Git.

The answer is a workspace Admin performs the connection. Repository rights never substitute for the Fabric role, and connect, disconnect, and the initial sync are Admin-only. The mirror-image stem, where someone holds Admin in Fabric but the commit still fails, points at the repository side: committing needs Read plus Contribute and a branch policy that permits a direct commit.

Contributors must be able to switch branches.

Enable the workspace setting Allow users with at least Contributor role to change Git branch, and make sure the user has write access to every item in the workspace. Partial item access defeats the setting.

Stems about isolation and merging

A developer needs to work without affecting others in the shared workspace.

Branch out to another workspace. Distractors offer Checkout new branch (repoints the shared workspace, no isolation) and connecting a second branch to the same workspace (impossible: one workspace, one branch).

Both the workspace and the branch already have content, and nothing should be lost.

No Fabric operation merges. Commit exports the workspace over the branch; update replaces the workspace. If the stem insists both states survive, the path is to commit or check out a branch carrying the workspace state, then reconcile in Git through a pull request.

Only one item needs to come back from Git.

There is no selective update. Update from Git takes the entire branch at its latest commit. Selective granularity exists for commit and undo only.

Stems about deployment behavior

A production stage must be added to an existing two-stage pipeline.

Not possible. Stage count and names are fixed at creation. Create a new pipeline.

After deploying, the production warehouse has no rows, or the production report cannot be seen by the same users.

Expected. Data, permissions, workspace settings, IDs, and URLs are not copied. Load or refresh the data in the target and grant workspace roles there.

An identical report already exists in test but the deployment created a second copy.

The target item was never paired. Items pair when a workspace is assigned to a stage (by name, type, and folder as tie breaker) or when a clean deploy creates the copy. An item added directly to the target workspace afterwards is not paired to its lookalike.

The deployment fails, reporting a dependency.

The provider item is neither in the target stage nor part of the selection. Use Select related to include it, or deploy the provider first.

The Direct Lake semantic model in production still reads the development lakehouse.

Direct Lake models do not autobind. Configure a datasource rule on the target stage item. Answers proposing that a redeploy, a rename, or a refresh will fix it are wrong.

Stems about database projects

The team must review the T-SQL before any change reaches the warehouse.

Generate Script. Build only validates and produces a dacpac; Publish applies changes immediately.

Deploying to production must never silently drop a populated column.

Keep BlockOnPossibleDataLoss set to True. The companion trap offers DropObjectsNotInSource as a way to protect target-only objects, which is exactly backwards: it deletes them.

A project must be created for an existing Fabric warehouse.

Create Project From Database against the warehouse's SQL endpoint, as an SDK-style project targeting Synapse Data Warehouse in Microsoft Fabric. Legacy non-SDK projects and Azure SQL Database target platforms are the distractors.

The habit that answers most of them

Before choosing, ask three questions in order. Which axis is this, source control or promotion? Is the operation selective or whole-scope? And does the requirement concern a definition, which travels, or an environment property such as data, credentials, identity, or permissions, which does not? Those three sort almost every option list on this objective into one right answer and three wrong ones.