Task 1.2: Implement lifecycle management in Fabric

• AShe's granted Create branch permission on the Azure DevOps repo

  Incorrect

  Connecting needs only Read on the repo; the block here is her workspace role.

• BA workspace Admin makes the connection; after that, she can commit and update

  Correct

  Connecting a workspace to a Git repo is limited to workspace Admins; Members and Contributors work in it once it's connected.

• CShe's given the Contributor role in the workspace instead of Member

  Incorrect

  Contributor grants less than Member; connecting a workspace to Git needs the Admin role.

• DShe creates a personal access token and saves it in the workspace settings for everyone

  Incorrect

  Git connections are per user, and a token doesn't change who may connect the workspace.

Only a workspace Admin can connect, sync or disconnect a workspace and a Git repo. Once it's connected, Members and Contributors with write permission on the items can commit and update, limited by their own Git permissions. Each user who works in the workspace configures their own Git account connection.

• AUpdate the workspace from the branch

  Incorrect

  Updating overwrites the workspace with the old branch content, which is the opposite of the goal.

• BCommit the workspace's current items to the branch

  Correct

  Committing exports all supported workspace content to Git and overwrites what's in the branch.

• CSwitch the workspace to a new empty branch, then update the workspace items

  Incorrect

  Updating from an empty branch has nothing to bring in; it doesn't save the workspace items either.

• DDisconnect, delete the branch folder, then update the workspace from Git

  Incorrect

  Updating from an emptied folder copies nothing, and the workspace items still aren't committed.

When both the workspace and the branch have content at connection time, you must pick the sync direction. Committing exports the workspace and overwrites the branch; updating overwrites the workspace, which Fabric asks you to confirm because a branch can be restored to an earlier commit but a workspace can't.

• ABranch out to a new workspace and feature branch, then open a pull request

  Correct

  Branch out is open to Contributors with Create branch permission; the PR then goes through main's policy.

• BSwitch the team workspace to a new feature branch and commit there

  Incorrect

  Switching the connected branch is restricted to workspace Admins by default.

• CUpdate the workspace from Git first, then retry the same commit straight to main

  Incorrect

  Updating doesn't change the branch policy; direct commits to main stay blocked.

• DDisconnect the workspace and reconnect it to a feature branch

  Incorrect

  Disconnecting and reconnecting a workspace is an Admin-only operation.

Committing from Fabric needs Contribute permission and a branch policy that allows direct commits. Branching out creates a new branch from the connected one and connects a new or existing workspace to it; Admins, Members and Contributors can do it with Read and Create branch permissions in the repo. Changes then return to main through the provider's pull request process.

• AThey're committed as JSON stubs that can't be updated back

  Incorrect

  Nothing is written to Git for unsupported items.

• BThe connection fails until the unsupported items are removed

  Incorrect

  A workspace with unsupported items can still be connected.

• CThey're deleted from the workspace on the first update from Git

  Incorrect

  Unsupported items aren't deleted; they're left as they are.

• DThey stay in the workspace and are left out of commits and updates

  Correct

  Unsupported items are ignored by Git integration; they aren't committed, synced or deleted.

If a workspace or Git folder contains item types that Git integration doesn't support, it can still be connected. The unsupported items are ignored: they aren't saved or synced and they aren't deleted, and they appear in the source control panel without the option to commit or update them.

• AA data source rule for each notebook, defined in the Test stage

  Incorrect

  Data source rules don't exist for notebooks, and rules belong to the target stage.

• BA parameter rule for each notebook, defined in the Production stage

  Incorrect

  Parameter rules apply to semantic models and dataflows Gen1, not notebooks.

• CA default lakehouse rule for each notebook, defined in the Production stage

  Correct

  Default lakehouse rules apply to notebooks and set the lakehouse they use in the target stage.

• DA %%configure cell in each notebook that names LH_Gold as the default lakehouse

  Incorrect

  A %%configure cell changes the notebooks' code, which the requirement rules out.

Deployment pipelines support data source, parameter and default lakehouse rules, depending on the item type; notebooks support only the default lakehouse rule. Rules are created in the target stage by the item's owner and take effect on the next deployment into that stage.

• AAn .ipynb file with the code cells and their last output

  Incorrect

  Fabric uses source files instead of a standard .ipynb file.

• BA binary export of the notebook that only Fabric can read

  Incorrect

  The source format is plain text designed for readable Git diffs.

• CA notebook-content.py source file with its cells but no output

  Correct

  Fabric stores notebooks as source files, and cell output isn't synced to Git.

• DOnly the notebook's metadata, with the code kept in the workspace

  Incorrect

  Code and markdown cells are stored in the source file.

When you commit a notebook, Fabric stores it as source files; a PySpark notebook becomes notebook-content.py. The file keeps notebook metadata (such as the default lakehouse and attached environment), markdown cells and code cells, but not cell output.

• AThe team makes the Azure DevOps project public

  Incorrect

  Project visibility doesn't lift the cross-region restriction.

• BThe repo is connected with a service principal instead of a user account

  Incorrect

  The identity used for the connection doesn't lift the region restriction.

• CThe team grants Create branch permission on the repo

  Incorrect

  Connecting needs Read; the region mismatch is the problem.

• DA tenant admin enables cross-geo export for Git integration

  Correct

  Cross-geo export is required when the workspace and the Azure repo are in different regions.

Git integration must be enabled by an administrator, and when the workspace and an Azure repo are in two different regions, the tenant admin must also enable cross-geo export. The restriction doesn't apply to GitHub.

• AThe Test NB_Clean is overwritten since the names match

  Incorrect

  Overwriting happens only for paired items.

• BThe deployment fails until the Test notebook is renamed and paired

  Incorrect

  The deployment succeeds and creates a new, paired copy.

• CTest ends up with a second NB_Clean, paired with Dev's

  Correct

  Unpaired items aren't overwritten even with the same name and type; a clean deploy creates a copy.

• DThe two notebooks are merged cell by cell

  Incorrect

  Deployments copy items; they never merge content.

Pairing associates an item in one stage with the same item in the adjacent stage. If items aren't paired, even with the same name and type, deploying doesn't overwrite the target item: it's a clean deploy that creates a copy in the target stage and pairs it with the source.

• AOpen and view the variable library item

  Correct

  Viewers can view the variable library item.

• BView and edit variable values

  Incorrect

  Editing needs the Contributor role or higher.

• CView, edit and reshare the variable library

  Incorrect

  Resharing needs the Member or Admin role.

• DEdit only the variables that they created

  Incorrect

  There's no permission management at the variable level.

Variable library permissions align with workspace roles: Viewers can view the item, Contributors can view, add, edit and delete it, and Members and Admins can also reshare it. Permissions apply to the whole item; there's no permission management per variable.