AI-103 Practice Question 83: Pipeline OIDC vs Secret
Microsoft Azure AI Apps and Agents Developer Associate (AI-103) · Test 9 · question 3 of 10
A platform team is building a GitHub Actions workflow that runs on every merge to main to deploy and update a Foundry resource and its model deployments. Security requires that the repository hold no long-lived secret that grants Azure access, and that nothing in the pipeline need manual rotation.
Which authentication approach satisfies both requirements?
Show answer and explanation
Answer:
With OpenID Connect (OIDC), the GitHub Actions runner presents a short-lived token issued by GitHub, and Azure exchanges it for an access token because of a federated identity credential configured in advance on an Entra application or user-assigned managed identity. Microsoft's own description of this flow is direct: "There are no secrets to manage, no credentials to rotate, and nothing sensitive stored in your repository." The values stored as GitHub secrets (client ID, tenant ID, subscription ID) are identifiers, not credentials; on their own they grant no access.
- A is wrong because a client secret is precisely the stored, expiring credential the security requirement rules out, and it hands the team a recurring rotation chore rather than removing it. - B is wrong because a personal access token ties the pipeline's identity to one person's account rather than a service identity, and it is still a stored secret subject to the same leakage and rotation problems as A. - D is wrong on the mechanics: a managed identity can be used only by the specific Azure resource it's assigned to. A GitHub-hosted runner is an external GitHub-managed VM, not that Azure resource, so it has no way to assume App Service's managed identity at all.
Reference: Authenticate to Azure from GitHub Actions by OpenID Connect