An organization needs to federate a GitHub Actions CI/CD pipeline identity with Microsoft Entra ID so the pipeline can deploy Azure OpenAI models without storing any Azure credentials in GitHub secrets. Which Entra ID feature enables this credential-free federation?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal — b is correct because Workload Identity Federation allows external identity providers (like GitHub Actions) to exchange their own issued tokens for Microsoft Entra ID access tokens without requiring stored secrets. The configuration involves: (1) creating a federated credential on an Entra ID app registration that trusts GitHub Actions OIDC tokens from a specific repository and branch, and (2) assigning the app registration the necessary Azure RBAC roles.
Full explanation below image
Full Explanation
B is correct because Workload Identity Federation allows external identity providers (like GitHub Actions) to exchange their own issued tokens for Microsoft Entra ID access tokens without requiring stored secrets. The configuration involves: (1) creating a federated credential on an Entra ID app registration that trusts GitHub Actions OIDC tokens from a specific repository and branch, and (2) assigning the app registration the necessary Azure RBAC roles. GitHub Actions workflows then use the OIDC token issued by GitHub to request an Entra ID token, enabling Azure CLI or SDK authentication with no secrets in GitHub. A is wrong because Application Proxy provides remote access to on-premises web apps through Entra ID; it is not a federation mechanism for CI/CD pipelines. C is wrong because PIM eligible assignments manage role activation for users; they do not provide credential-free federation for external identity providers. D is wrong because B2B invite is for inviting human external users as guest accounts, not for federating CI/CD pipeline identities.