AI-300 Practice Question 22: GitHub Actions OIDC
Microsoft Machine Learning Operations Engineer Associate (AI-300) · Test 3 · question 2 of 10
A GitHub Actions workflow deploys an Azure Machine Learning workspace with Bicep and then submits a pipeline job. Security has banned long-lived secrets from the repository, and requires that the Azure access the workflow obtains be usable only from that one repository. How should the workflow authenticate to Azure?
Show answer and explanation
Answer:
Microsoft's CI/CD guidance for Azure Machine Learning states that "the recommended, more secure option is to sign in by using OpenID Connect". To do it, "you need to configure a federated identity credential on a Microsoft Entra application or a user-assigned managed identity" to "trust tokens issued by GitHub Actions to your GitHub repository", and the workflow declares permissions: id-token: write so the job can request that short-lived token. Nothing durable is stored in the repository, and the trust is bound to the repository itself (option A).
- B is wrong because the same article marks sign-in with a service principal and secret as "less secure and not recommended". A stored client secret is precisely the long-lived credential the policy bans; rotating it shortens the exposure window without removing it, and anyone who extracts it can use it from anywhere. - C is wrong because a refresh token is also a stored long-lived credential, and it represents a *user*, not a workload. It carries that user's full access rather than a repository-scoped one, and it breaks whenever their credentials change. - D is wrong because, although it removes the repository secret, it makes you operate runner VMs and it scopes the identity to the machine. Any workflow scheduled onto that runner inherits the same Azure access, which is the opposite of restricting access to one repository.
Reference: GitHub Actions for CI/CD - Azure Machine Learning