What's changed: Added per-section figures (cert-figure-retrofit). New AI-300 Chapter 1 (Domain 1 "MLOps infrastructure": workspace/datastores/compute targets/IAM; asset management = data assets/environments/components/registries; IaC and automation = Bicep-Azure CLI/GitHub Actions/workload identity federation/network restriction/Git)
1.3IaC and automation for Machine Learning
Understand secure GitHub–Machine Learning integration, deploying workspaces/resources with Bicep and Azure CLI, automating provisioning with GitHub Actions workflows, restricting network access to workspaces, and Git source control—as the automation foundation of MLOps.
MLOps runs infrastructure and pipelines reproducibly through code and automation, not manual steps. AI-300 covers the basics of IaC (Infrastructure as Code) and CI/CD.
1.3.1Bicep/Azure CLI and GitHub Actions
Deploy resources like workspaces and compute as code with Bicep (declarative IaC) and the Azure CLI. Then use GitHub Actions workflows to automate provisioning, training, and deployment triggered by code pushes. Connect GitHub and Machine Learning via workload identity federation (secretless, secure) as the recommended approach. This makes environment setup reproducible and auditable.
1.3.2Network restriction and Git source control
Restrict workspace access with private networking (private endpoints / managed virtual networks) to limit public exposure. Keep project code (training scripts, pipeline definitions, IaC) under Git source control for history, review, and rollback. The MLOps mindset: "codify both infrastructure and ML pipelines, manage them in Git, and automate with Actions."
| Goal | Means | Key point |
|---|---|---|
| Deploy resources as code | Bicep / Azure CLI | Declarative, reproducible |
| Automate provisioning/training | GitHub Actions workflows | Triggered by pushes |
| Secure GitHub integration | Workload identity federation | Secretless |
| Limit public exposure | Private endpoints / managed VNet | Restrict network access |
| Manage code changes | Git source control | History/review/rollback |
Watch the mix-ups: (1) Bicep/CLI (IaC = deploy resources) vs GitHub Actions (CI/CD = automate workflows) are complementary. (2) Prefer workload identity federation (secretless) for GitHub integration—don’t store long-lived secrets in GitHub. (3) Workspace network restriction and RBAC (authorization) are separate layers.
Map requirement → means: "deploy a workspace reproducibly as code" = Bicep/Azure CLI; "automate training/deploy on push" = GitHub Actions; "reach Azure from GitHub without secrets" = workload identity federation; "don’t expose the workspace publicly" = private endpoints; "change history and review of scripts" = Git.
1.3.3Section summary
- Codify resources with IaC (Bicep/Azure CLI); automate provisioning/training/deploy with GitHub Actions
- GitHub integration via workload identity federation (secretless); protect workspaces with private networking
- Manage infra and ML pipelines in Git (history/review/rollback)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which deploys Azure resources (workspaces, etc.) reproducibly as declarative code?
Q2. Which automates provisioning, training, and deployment triggered by code pushes?
Q3. Which is the recommended way to connect GitHub to Azure securely without long-lived secrets?
Q4. How do you restrict network access so an AML workspace is not publicly exposed?
Q5. Which enables history, review, and rollback of training scripts, pipeline definitions, and IaC?
Q6. Which correctly describes the relationship between IaC (Bicep/CLI) and GitHub Actions?