A team is configuring workload identity federation so an "Azure Pipelines" service connection authenticates to Microsoft Entra and deploys to an Azure subscription with no client secret or certificate held anywhere. They are creating a federated credential on the Microsoft Entra application. Which two values must the federated credential be configured with so that only this service connection's pipeline runs can exchange their token for Azure access? Select TWO.
- AA copy of the service principal client secret, pasted into the federated credential so the pipeline presents both the secret and the federated token at sign-in.
- BAn issuer pointing at the Azure DevOps organisation's OpenID Connect token issuer, so Microsoft Entra trusts tokens minted for that organisation. Correct
- CA Contributor role assignment on the resource group, entered directly in the federated credential record so that authorisation travels with the trust definition.
- DA subject identifier that matches the specific service connection, so only tokens issued for that connection's organisation and project satisfy the trust. Correct
Why A is wrong: Workload identity federation exists to eliminate the client secret entirely, so requiring a pasted secret contradicts the secretless goal and is not part of a federated credential at all.
Why B is correct: The issuer names the trusted OpenID Connect provider; setting it to the Azure DevOps organisation issuer lets Microsoft Entra accept the run-time tokens that organisation mints, which is required for the federated exchange.
Why C is wrong: Authorisation is granted by a separate Azure role assignment on the resource, not stored inside the federated credential, so this conflates the trust definition with role-based access control.
Why D is correct: The subject claim scopes the trust to one service connection's identity, so only pipeline runs using that connection present a matching subject and can complete the token exchange, keeping the trust narrow.