Which authentication should Azure DevOps use for Fabric deployment pipeline API?

DP-700 By islever Editorial Last updated

Implement lifecycle management in Fabric Configure security and governance

Short answer

A Use a Microsoft Entra service principal (app registration) to authenticate Azure DevOps API calls that run deployPipeline1 in Fabric.

Question

You have a Fabric workspace named Workspace1.
You plan to integrate Workspace1 with Azure DevOps.
You will use a Fabric deployment pipeline named deployPipeline1 to deploy items from Workspace1 to higher environment workspaces as part of a medallion architecture. You will run deployPipeline1 by using an API call from an Azure DevOps pipeline.
You need to configure API authentication between Azure DevOps and Fabric.
Which type of authentication should you use?
  1. service principal Correct Answer
  2. Microsoft Entra username and password
  3. managed private endpoint
  4. workspace identity

Key Takeaways

This item tests which Microsoft Entra identity should authenticate an Azure DevOps-to-Fabric deployment pipeline API call; the trap is confusing a Fabric workspace identity or private endpoint with a CI/CD service principal.

Azure DevOps automation that invokes a Fabric deployment pipeline API needs a non-interactive identity with Fabric permissions. This page establishes that a service principal (A) is the correct authentication type for deployPipeline1, not a workspace identity or username/password.

Common mistake: Picking workspace identity (D) because it is Fabric-specific; it is an outbound identity for the workspace, not an inbound API credential for Azure DevOps.

Expert Analysis

Why the Answer Is Correct

A service principal is the non-interactive Microsoft Entra identity intended for automated tools such as an Azure DevOps pipeline calling Fabric REST APIs. In this scenario, Azure DevOps needs credentials that can be stored as a service connection or secret and used to invoke the deployment pipeline operation for deployPipeline1 without a signed-in user. Service principals support role assignments and scoped permissions in Fabric, so access to Workspace1 and the target stage workspaces can be governed and rotated. This matches Microsoft's CI/CD guidance and the Fabric API quickstart, which directs app integrations to create an app registration/service principal. Therefore option A is the authentication type the question is asking for.

Why the Other Options Are Wrong

Microsoft Entra username and password (B) is interactive user authentication; it is brittle in automation, conflicts with MFA/conditional access, and is not the recommended way to authenticate an Azure DevOps pipeline. A managed private endpoint (C) is a networking control for private connectivity, not an identity or token-acquisition mechanism, so it cannot authenticate the API call. Workspace identity (D) is a Fabric-managed identity used by the workspace to access Azure resources outbound; it is not the credential that an external Azure DevOps pipeline presents to Fabric. The REST deployment-pipeline documentation's identity-support table can raise the user-auth distractor, but for the question's automation requirement the service principal is the secure supported choice.

Community Comment Notes

VenkataPhaniPavanKumar and henryphchan both describe a service principal as the secure, non-interactive identity for Azure DevOps-to-Fabric automation, and jfranzen points to the Fabric API quickstart's app-registration step. hebertorosillo and robertlavigne highlight the REST deploy-stage-content identity table and the note that service principals/managed identities are limited to Power BI items for that operation; that is a valid item-support caveat, but it does not make username/password the right exam answer for CI/CD authentication. Other commenters such as viskas separate workspace identity as an in-Fabric access feature rather than an external API credential. The consensus of the useful comments is service principal, while the API-doc comment is best treated as a reminder to verify the specific deployment-pipeline operation's supported identities and item types.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

For CI/CD authentication questions, eliminate options that are networking constructs or interactive user credentials; look for a non-interactive Microsoft Entra app identity. Then verify the specific Fabric API operation supports that identity for the item types you deploy.

Frequently Asked Questions

Why is a workspace identity not used for Azure DevOps to Fabric API calls?

Workspace identity is a Fabric-managed identity for workspace outbound access to resources; it is not a credential an external Azure DevOps pipeline uses to call Fabric APIs.

Does service principal authentication work with the Fabric deployment pipeline API?

Yes for supported item types and operations, but check the current Fabric REST identity-support table because some deployment-pipeline operations limit service principals to Power BI items.

More DP-700 FAQ →

Discussion 16 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 16

  1. VenkataPhaniPavanKumar 👍 6 Answered A
    A service principal is the recommended authentication method when automating deployments and integrations between Azure DevOps and Microsoft Fabric. It provides a secure, scalable, and manageable way to authenticate API calls—especially from CI/CD systems like Azure DevOps pipelines—without requiring user credentials.
  2. Meir 👍 4 Answered A
    See https://learn.microsoft.com/en-us/answers/questions/2074603/run-pipeline-via-azure-function-by-rest-api
  3. robertlavigne 👍 3 Answered B
    https://learn.microsoft.com/en-us/rest/api/fabric/core/deployment-pipelines/deploy-stage-content?tabs=HTTP The above documentation shows that the deploy pipeline API can only use a service principal to deploy PowerBI content. Since we are deploying content related to a medallion architecture we will need to use user based authentication. Workspace ID is for fabric to reach out to other things which isn't what we want. And a managed private-endpoint is not relevant.
  4. viskas 👍 3 Answered A
    To configure API authentication between Azure DevOps and Fabric, a service principal is the recommended approach. Workspace identity: Workspace identities are a feature within Fabric itself. They are used to control access to resources within the Fabric workspace. While relevant for managing access within Fabric, they don't directly facilitate authentication with external services like Azure DevOps.
  5. hebertorosillo 👍 3 Answered B
    Microsoft Entra supported identities This API supports the Microsoft identities listed in this section. Identity Support User Yes Service principal and Managed identities Only Power BI Items are supported . ref https://learn.microsoft.com/en-us/rest/api/fabric/core/deployment-pipelines/deploy-stage-content?tabs=HTTP
Show 11 more comments
  1. henryphchan 👍 3 Answered A
    A service principal is an identity created for use with applications, hosted services, and automated tools to access Azure resources. It provides a secure, non-interactive way for Azure DevOps pipelines to authenticate and interact with Fabric APIs without needing user credentials.
  2. h2o_molecule 👍 2 Answered A
    Here's a brief overview of the options: Service principal: Provides a secure and scalable method for authenticating and authorizing access between Azure DevOps and other services. Ideal for automation and integration scenarios. Microsoft Entra username and password: Less secure and not recommended for automated processes. Managed private endpoint: Used for secure, private connectivity between services, but not specifically for authentication in this context. Workspace identity: Not typically used for cross-service API authentication in Azure DevOps integration scenarios.
  3. jfranzen 👍 2 Answered A
    The relevant documentation I found to support Service Principals is this: https://learn.microsoft.com/en-us/rest/api/fabric/articles/get-started/fabric-api-quickstart Specifically calling out integrating with the API by creating a Service Principal (App Registration) in the Entra tenant.
  4. a85becd 👍 2 Answered A
    Announcing Service Principal support for Fabric APIs: https://blog.fabric.microsoft.com/en-au/blog/announcing-service-principal-support-for-fabric-apis/#:~:text=Service%20principal%20is%20a%20security,integrate%20them%20with%20other%20services.
  5. GHill1982 👍 2
    Agree. Workspace identity is primarily designed for connecting Fabric items to storage accounts and is not the most suitable option for API authentication between Azure DevOps and Fabric.
  6. prabhjot 👍 2 Answered A
    to interact with azure services and devops to implement automation, service principal is most commonly used
  7. mixonfreddy 👍 2 Answered D
    Use of service principal is discouraged
  8. gpasini 👍 1 Answered A
    This is a common DP-600/DP-700 style question: whenever an Azure DevOps pipeline or another external automation tool needs to call Fabric REST APIs (including deployment pipeline APIs), the expected answer is usually Service Principal rather than a user account or managed identity. https://learn.microsoft.com/en-us/fabric/cicd/git-integration/automate-git-integration-with-service-principal
  9. shmmini 👍 1
    Service principal is only supported for Power BI Items deployment. In this question no details is given so assume warehouses and laekhouses are there as well. So the right qnswer is User
  10. DarioReymago 👍 1
    I don't understand this. I use Services Principal for some tools that connect to warehouse
  11. asitp9 👍 1 Answered A
    A is correct

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

A 500-million-row fact table exceeds the F32 Direct Lake guardrail, so increase the capacity to F64

S-grade

Shortcut caching supports only S3/GCS shortcuts and excludes files larger than 1 GB

S-grade

Updating warehouse tables requires at least the Contributor workspace role because Write is not shareable to a Viewer

S-grade

Run T-SQL in a KQL database only by prefixing the query with a -- comment line

S-grade

← Back to DP-700 Study Guide