Workspace Version Control: 10 practice questions

Question 1 of 10

Which remote repository providers can Fabric Git integration connect to?

1. ASharePoint or OneDrive
2. BAzure DevOps or GitHub
3. CAzure Repos or OneLake
4. DGitLab or Bitbucket

Question 2 of 10

How many repository branches directly affect a connected Fabric workspace at one time?

1. AEvery branch in the repository
2. BTwo branches, primary and secondary
3. COne branch for each workspace item
4. DExactly one selected repository branch

Question 3 of 10

A pull request into the primary branch is completed. What changes the primary Fabric workspace database?

1. AUpdating the primary workspace from source control
2. BOpening the source-control history in the primary workspace
3. CCompleting the pull request without any workspace action
4. DCreating another branch from the merged primary branch

Question 4 of 10

Which release design keeps Git as the origin of every deployment and assigns a primary branch to each stage?

1. AGitflow with Fabric Git API updates for each stage workspace
2. BDeployment pipelines with Git connected only through Dev
3. CPost-deployment scripts executed from Shared Queries
4. DTrunk-based Items API deployment from one Main branch

Question 5 of 10

What does Branch out to new workspace create?

1. AA new repository branch paired with a new Fabric workspace
2. BA new workspace linked to the existing selected branch
3. CA pull request that immediately updates the primary workspace
4. DA new branch without creating another Fabric workspace

Question 6 of 10

Why should a developer avoid manual edits to Fabric's generated SQL project file?

1. AThe project file is excluded from the connected repository entirely.
2. BThe project file can contain object definitions but no metadata.
3. CThe next Fabric commit overwrites those manual project-file edits.
4. DThe next pull request automatically deletes the whole database folder.

Question 7 of 10

In the Fabric-native deployment option, where does Git integration end?

1. AAt the Dev workspace before workspace-to-workspace promotion
2. BAt the Test workspace after Dev deploys through Items APIs
3. CAt every stage because each workspace connects to Main
4. DAt the Prod workspace after each stage pulls its own branch

Question 8 of 10

A regulated team requires Git to remain the single source of truth for Dev, Test, and Prod. Each stage needs its own reviewed primary branch, and no build script alters definitions before upload. Which design fits best?

1. AUse Gitflow and update each stage workspace from its own dedicated branch.
2. BConnect Git to Dev only and promote later stages through deployment pipelines.
3. CUse one Main branch and push transformed definitions through Items APIs.
4. DUse one shared branch and manually copy item definitions between workspaces.

Question 9 of 10

A trunk-based team keeps one Main branch. Before each release, scripts must replace connection and lakehouse identifiers for the target workspace, and Test and Prod should not connect to Git. Which approach should it use?

1. ADeployment pipelines without parameterization or post-deployment updates
2. BBuild scripts plus Fabric Items APIs to push transformed definitions
3. CFabric Git APIs with one primary Gitflow branch for every stage
4. DBranch out to a new workspace for each production release

Question 10 of 10

Two database developers use separate Fabric workspaces and repository branches. A reviewed pull request merges the secondary branch, but the primary database must remain unchanged until the release manager acts. What sequence preserves that control?

1. ADelete the secondary workspace, which applies its objects to the primary database.
2. BMerge the pull request, then update the primary workspace when approved.
3. CUpdate the primary workspace first, then merge the pull request afterward.
4. DMerge the pull request and expect the primary database to update immediately.