Deployment Pipelines: 10 practice questions

Question 1 of 10

What is the stage order in the Fabric-native deployment pipeline model?

1. AProd, then Test, then Dev
2. BTest, then Prod, then Dev
3. CDev, then Prod, then Test
4. DDev, then Test, then Prod

Question 2 of 10

Which prerequisite applies when configuring Fabric deployment?

1. AA workspace Member role is sufficient without pipeline permission.
2. BA workspace Viewer can configure deployment with feature access.
3. CA Git connection removes the workspace-role requirement.
4. DThe user must be a workspace admin.

Question 3 of 10

What responsibility belongs to a deployment pipeline rather than Git integration?

1. ARecording incremental source changes in a connected repository branch
2. BPromoting approved workspace content from Dev to Test and Prod
3. CCommitting live workspace item definitions into source control
4. DReviewing database object code through a repository pull request

Question 4 of 10

Which deployment-pipeline capabilities help review a proposed promotion and inspect earlier activity?

1. AContent comparison and deployment history
2. BGit updates and dedicated branches for every stage
3. CVariable libraries and per-stage value sets
4. DDeployment rules and dependency autobinding

Question 5 of 10

How should a team treat item dependencies during cross-workspace deployment?

1. AReplace every dependency with a separate Git branch per stage.
2. BAssume no dependency can bind in a different workspace.
3. CVerify each dependency because some autobind and others need parameterization.
4. DAssume every dependency autobinds through its item display name.

Question 6 of 10

What can a Fabric variable library provide to a staged release?

1. AAutomatic conversion of unsupported dependencies into logical IDs
2. BShared variables with different value sets for each stage
3. CA copy of production table data for every Test deployment
4. DA separate repository provider selected for each workspace item

Question 7 of 10

How can a team automate a Fabric deployment pipeline from an existing release workflow?

1. ACall Fabric Items APIs without invoking the deployment pipeline.
2. BChange variable-library values and expect promotion to start automatically.
3. CCall deployment pipeline APIs from Azure Pipelines or GitHub workflows.
4. DCall Fabric Git APIs and treat repository sync as stage promotion.

Question 8 of 10

A team wants Git for reviewed development changes but wants Test and Prod to receive content directly from Fabric workspaces. It also needs in-product change comparison and release history. Which delivery design best fits?

1. ACopy item definitions manually from Dev to each later workspace.
2. BConnect Git through Dev and promote with Fabric deployment pipelines.
3. CConnect every stage to a dedicated Gitflow branch and deploy from Git.
4. DPush transformed definitions from one Main branch with Items APIs.

Question 9 of 10

Approved code has reached Dev. The organization requires automated checks in the next workspace, a manual release decision, and no production promotion before both are complete. Which sequence should the release use?

1. ARun checks against Dev, deploy Test and Prod together, then request approval.
2. BDeploy Dev to Test, run the checks, obtain approval, then deploy Test to Prod.
3. CDeploy Dev to Prod, run checks there, then copy the result back to Test.
4. DApprove the release in Dev, skip Test deployment, then deploy directly to Prod.

Question 10 of 10

A promoted item has one dependency that rebinds through its logical ID and another connection that must differ in each stage. The team wants repeatable releases without rewriting every item. How should it configure the pipeline?

1. AKeep autobinding for the first dependency and parameterize the stage connection.
2. BAssume both dependencies autobind and omit stage-specific configuration.
3. CDisable all binding and hard-code the Dev connection in every stage.
4. DCreate a Git branch for each dependency inside every workspace.