Which authentication should Azure DevOps use for Fabric deployment pipeline API?
Answer
Correct answer: A — use a Microsoft Entra service principal (app registration) to authenticate Azure DevOps API calls that run deployPipeline1 in Fabric.
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?
Community Insight
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.
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.
Community Discussion (17 comments)
gpasini
👍 1
Selected: 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
jfranzen
👍 2
Selected: 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.
asitp9
👍 1
Selected: A
A is correct
VenkataPhaniPavanKumar
👍 6
Selected: 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.
smanzana
👍 1
Selected: A
A is correct
a85becd
👍 2
Selected: 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.
DarioReymago
👍 1
I don't understand this. I use Services Principal for some tools that connect to warehouse
hebertorosillo
👍 3
Selected: 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
henryphchan
👍 3
Selected: 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.
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
prabhjot
👍 2
Selected: A
to interact with azure services and devops to implement automation, service principal is most commonly used
h2o_molecule
👍 2
Selected: 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.
robertlavigne
👍 3
Selected: 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.
viskas
👍 3
Selected: 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.
Meir
👍 4
Selected: A
See https://learn.microsoft.com/en-us/answers/questions/2074603/run-pipeline-via-azure-function-by-rest-api
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.
mixonfreddy
👍 2
Selected: D
Use of service principal is discouraged
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
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
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.