Study guide
4.3 Automate Resource Provisioning with GitHub Actions
Microsoft AI-300: Operationalizing Machine Learning and Generative AI Solutions Exam
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 Skills Measured, Format, and How This Guide Is Organized 1.3 Candidate Profile, Azure ML v2, Foundry, and DevOps Tooling
2 Chapter 2: Azure Machine Learning Workspaces, Datastores, Compute, and IAM
2.1 Create and Manage Azure Machine Learning Workspaces 2.2 Create and Manage Datastores 2.3 Create and Manage Compute Targets 2.4 Configure Identity and Access Management for Workspaces
3 Chapter 3: Azure Machine Learning Data Assets, Environments, Components, and Registries
3.1 Create and Manage Data Assets 3.2 Create and Manage Environments 3.3 Create and Manage Components 3.4 Share Assets Across Workspaces with Registries
4 Chapter 4: Infrastructure as Code, GitHub, and Network Isolation for Azure ML
4.1 GitHub Integration and Git Source Control for Machine Learning Projects 4.2 Deploy Workspaces and Resources with Bicep and Azure CLI 4.3 Automate Resource Provisioning with GitHub Actions 4.4 Restrict Network Access to Machine Learning Workspaces
5 Chapter 5: MLflow Tracking, AutoML, Training Jobs, and Hyperparameter Sweeps
5.1 Configure Experiment Tracking with MLflow 5.2 Use Automated Machine Learning to Explore Optimal Models 5.3 Notebooks, Command Jobs, and Training Scripts 5.4 Automate Hyperparameter Tuning
6 Chapter 6: Distributed Training, Training Pipelines, and Job Comparison
6.1 Manage Distributed Training for Large and Deep Learning Models 6.2 Implement Training Pipelines 6.3 Compare Model Performance Across Jobs
7 Chapter 7: Model Registration, Responsible AI, and Lifecycle Management
7.1 Register MLflow Models and Package Feature Retrieval Specs 7.2 Evaluate Models with Responsible AI Principles 7.3 Manage Model Lifecycle and Archiving
8 Chapter 8: Online Endpoints, Batch Endpoints, Rollout, and Rollback
8.1 Deploy Models to Managed Online Endpoints 8.2 Deploy Models to Batch Endpoints 8.3 Test, Troubleshoot, Progressive Rollout, and Safe Rollback
9 Chapter 9: Data Drift, Production Metrics, Retraining, and Alerts
9.1 Detect and Analyze Data Drift 9.2 Monitor Production Metrics and Trigger Retraining or Alerts
10 Chapter 10: Microsoft Foundry Resources, IAM, Networking, and IaC
10.1 Create and Configure Foundry Resources and Project Environments 10.2 Managed Identities and RBAC for Foundry 10.3 Foundry Network Security and Private Networking 10.4 Deploy Foundry Infrastructure with Bicep and Azure CLI
11 Chapter 11: Deploying and Managing Foundation Models
11.1 Serverless API Endpoints and Managed Compute for Foundation Models 11.2 Select Foundation Models for Specific Use Cases 11.3 Model Versioning and Production Deployment Strategies 11.4 Provisioned Throughput Units for High-Volume Workloads
12 Chapter 12: Prompt Design, Variants, and Git Version Control
12.1 Design and Develop Prompts 12.2 Create Prompt Variants and Compare Performance 12.3 Version Control for Prompts with Git
13 Chapter 13: Evaluation Datasets, Quality Metrics, Safety, and Automated Workflows
13.1 Test Datasets and Data Mapping for Evaluation 13.2 Groundedness, Relevance, Coherence, and Fluency 13.3 Risk and Safety Evaluations 13.4 Built-in and Custom Automated Evaluation Workflows
14 Chapter 14: Continuous Monitoring, Performance, Cost, Tracing, and Logging
14.1 Continuous Monitoring in Microsoft Foundry 14.2 Latency, Throughput, Token Use, and Cost Metrics 14.3 Logging, Distributed Tracing, and Production Debugging
15 Chapter 15: Retrieval Tuning, Embeddings, Hybrid Search, and RAG Evaluation
15.1 Tune Similarity Thresholds, Chunk Sizes, and Retrieval Strategies 15.2 Select and Fine-Tune Embedding Models 15.3 Hybrid Search: Semantic and Keyword Retrieval 15.4 RAG Relevance Metrics and A/B Testing
16 Chapter 16: Fine-Tuning Methods, Synthetic Data, and Promotion to Production
16.1 Advanced Fine-Tuning Methods (LoRA, QLoRA, Full) 16.2 Create and Manage Synthetic Data for Fine-Tuning 16.3 Monitor, Optimize, and Promote Fine-Tuned Models
4.3 Automate Resource Provisioning with GitHub Actions
Key Takeaways Explain This Topic AI
Microsoft’s recommended GitHub Actions authentication to Azure is OpenID Connect (OIDC) federated credentials on a Microsoft Entra application (service principal without a secret) or a user-assigned managed identity — not a long-lived client secret in GitHub secrets.
The workflow job needs permissions.id-token: write, then azure/login@v2 with client-id, tenant-id, and subscription-id (AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_SUBSCRIPTION_ID). Do not pass creds: ${{ secrets.AZURE_CREDENTIALS }} for new work.
az ad sp create-for-rbac --json-auth is deprecated as the happy path. It still emits a client secret that you would store as AZURE_CREDENTIALS; use it only for legacy pipelines and plan to migrate.
After login, install CLI v2 (az extension add -n ml) and deploy with az deployment group create (Bicep) and/or az ml workspace create / az ml compute create. Path-filter workflows so infra changes do not train models.
Scope the identity with least-privilege Azure RBAC (resource-group Contributor or a custom role, not subscription Owner). Use GitHub Environments with required reviewers so production Bicep cannot apply from a feature branch without approval.
Last updated: August 2026
Automate Resource Provisioning with GitHub Actions
Quick Answer: Authenticate GitHub Actions to Azure with OpenID Connect (OIDC) federated credentials on a user-assigned managed identity or Microsoft Entra app — not a client secret. Grant the job id-token: write , run azure/login@v2 , then az deployment group create (Bicep) and az ml CLI v2. Use GitHub Environments as approval gates and least-privilege RBAC on the identity.
Domain 1’s third IaC bullet is automate resource provisioning by using GitHub Actions workflows . Section 4.1 was clone-and-commit. Section 4.2 was the template. This section is the pipeline that applies the template so humans are not running az deployment group create from a laptop with Owner rights.
Microsoft’s Azure Machine Learning GitHub Actions article (updated 2026) and the OIDC connect-from-Azure article agree: OIDC is the recommended, more secure option . The MLOps v2 demo still shows a service-principal JSON secret because the sample predates the push; the same page now warns that --json-auth is deprecated and tells you to follow the OIDC article for new work.
OIDC instead of a client secret
GitHub Actions can mint a short-lived OIDC id-token for the workflow. Azure federated identity credentials trust that token when the issuer , subject , and audience match. No password is stored in GitHub.
Option 1 — Microsoft Entra application (service principal without a secret)
Register an app; note Application (client) ID , Directory (tenant) ID , subscription ID.
Assign Azure RBAC at the resource group (or narrower) that owns the workspace.
Add a federated credential that trusts GitHub: organization, repository, and a subject such as repo:contoso/claims:environment:prod or repo:contoso/claims:ref:refs/heads/main .
Option 2 — User-assigned managed identity
Create the identity in Azure.
Assign RBAC to that identity.
Configure the federated credential on the user-assigned managed identity (same GitHub subject matching).
Copy three values into GitHub Actions secrets (or environment secrets ):
- GitHub secret Source
- AZURE_CLIENT_ID App or managed identity client ID
- AZURE_TENANT_ID Directory (tenant) ID
- AZURE_SUBSCRIPTION_ID Subscription ID
These are identifiers , not passwords. Still prefer environment secrets on public repositories so a fork pull request cannot read them. GitHub Environments can require reviewers: the job cannot start — and cannot read those secrets — until a human approves.
The legacy path stores the entire az ad sp create-for-rbac --json-auth blob as AZURE_CREDENTIALS and logs in with creds: ${{ secrets.AZURE_CREDENTIALS }} . That blob contains clientSecret . It works and Microsoft still documents it, but it is less secure and the CLI flag is deprecated . Exam answers that pick “paste the client secret into GitHub” as the recommended design are wrong.
- Workflow anatomy for provisioning
- A provisioning workflow lives in .github/workflows/deploy-infra.yml . Core pieces: name: deploy-aml-infra
on:
workflow_dispatch:
push:
branches: [main]
paths:
- infra/**
- .github/workflows/deploy-infra.yml
permissions:
- id-token: write
- contents: read
jobs:
deploy:
- runs-on: ubuntu-latest
- environment: prod
steps:
- uses: actions/checkout@v4
- uses: azure/login@v2
with:
- client-id: ${{ secrets.AZURE_CLIENT_ID }}
- tenant-id: ${{ secrets.AZURE_TENANT_ID }}
- subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- name: Deploy Bicep
- run: |
- az deployment group create \
- -resource-group rg-claims-prod \
- -template-file infra/main.bicep \
- -parameters infra/prod.bicepparam
- name: Azure ML CLI
- run: |
- az extension add -n ml -y
- az ml workspace update -f infra/workspace.yml --resource-group rg-claims-prod
- az ml compute create -f infra/cpu-cluster.yml --resource-group rg-claims-prod --workspace-name mlw-claims-prod
Required pieces the exam will poke:
permissions.id-token: write — without it, azure/login@v2 cannot request the OIDC token. contents: read is enough to checkout. Do not grant contents: write unless a later job must push a tag.
actions/checkout@v4 — the runner needs infra/ .
azure/login@v2 with the three IDs, not creds: .
Bicep deploy then az ml for workspace-shaped leftovers (compute YAML, image_build_compute ).
Path filters — infra/** so a documentation-only commit does not redeploy prod. Training workflows (Microsoft’s NYC taxi sample) similarly filter cli/jobs/pipelines/... and are a different workflow from provisioning.
Microsoft’s sample training workflow also runs bash setup.sh (sets GROUP , LOCATION , WORKSPACE ) and az ml job create against pipeline.yml . That is model CI , not landing-zone provisioning. You can keep both workflows in one repo; do not conflate them on the exam.
Audience for public Azure is api://AzureADTokenExchange (the login action default). Azure US Government uses a different environment and audience — only if the question names that cloud.
Least privilege and promotion gates
The identity GitHub federates to should not be subscription Owner . Prefer:
Scope: one resource group per environment ( rg-claims-dev , rg-claims-prod ).
Role: Contributor on that group is a common demo; production often uses a custom role that can create Microsoft.MachineLearningServices/* , storage, Key Vault, network private endpoints, and ACR, but cannot attach new subscriptions or assign Owner.
Separate identities for dev and prod federated subjects so a leaked dev workflow cannot apply prod Bicep.
GitHub Environment prod : required reviewers, deployment branches limited to main , environment secrets for the prod client ID.
Federated credential subjects are the other half of least privilege. A credential for repo:contoso/claims:ref:refs/heads/main will not mint Azure tokens for a feature branch. A credential for environment:prod requires the job to declare environment: prod (and therefore the approval gate).
If the workflow creates private endpoints in a managed virtual network, the identity also needs the Machine Learning private-endpoint connection actions ( Microsoft.MachineLearningServices/workspaces/privateEndpointConnections/read and write ) described in section 4.4.
What not to put in the workflow
Do not echo secrets. az debug logs can leak tokens if you turn on too much verbosity.
Do not check in setup.sh with prod workspace names only — parameterize like Bicep.
Do not use continue-on-error: true on the login or deploy step in production (the azureml-examples training sample does it on setup for lab convenience).
Do not grant the GitHub App or PAT used for clone (section 4.1) the same rights as the Azure identity. They are different planes.
Exam scenario
An MLOps engineer stores AZURE_CREDENTIALS from az ad sp create-for-rbac --role Owner --scopes /subscriptions/<id> --json-auth . Any contributor who can change a workflow on any branch can create resources in the subscription. A contractor forks the public repo and dumps the secret. The fix: delete the client secret, create a user-assigned managed identity with Contributor on rg-claims-prod only , add a federated credential for repo:contoso/claims:environment:prod , put the three IDs in environment secrets , set id-token: write , and require two reviewers on the prod GitHub Environment.
Common trap
Do not choose “GitHub Actions cannot deploy Azure Machine Learning; you must use Azure DevOps” — Microsoft documents GitHub Actions as a first-class path. The sibling trap is omitting id-token: write , which fails OIDC login with a token-permission error. A third trap is treating the NYC taxi training workflow as sufficient infrastructure provisioning — it assumes the workspace already exists.