02 · IaC, réseau et Git : industrialiser un workspace Azure Machine Learning

Version : 1.1 · Date : 2026-10-21 · Domaine 1 de l'examen : Design and implement an MLOps infrastructure (15 à 20 %)

En une phrase : le workspace et ses ressources se déclarent en Bicep (ou Terraform), son contenu (compute, environments, jobs) en YAML az ml, le tout dans Git ; GitHub Actions s'y connecte sans secret par OIDC, et le réseau se ferme en sortie avec le managed virtual network et en entrée avec un private endpoint.

Ce que l'examen demande#

Bloc Implement IaC for Machine Learning, repris du guide d'étude AI-300 :

Ce chapitre ne redit pas les bases que tu as déjà : workload identity federation (SC-500 01, § 7.3), IaC sécurisée et pipelines sans secret (SC-500 03, § 9), private endpoints et DNS (SC-500 06, § 7), CI en push et CD en pull (AKS 05, § 2.1). Le workspace lui-même, ses datastores, ses compute targets et ses registries sont au chapitre 01.

1. Les bases : deux couches à déclarer#

Un projet MLOps se décrit à deux niveaux, qu'on enchaîne dans le même pipeline :

À retenir : les commandes az ml envoient leurs données opérationnelles à Azure Resource Manager. Si le workspace n'a plus d'accès public, la machine qui lance az ml doit passer par le réseau privé (Private Link) ou le workspace doit garder public_network_access: Enabled.

2. Deploy workspaces and resources : Bicep et Azure CLI#

2.1 Ce que référence un workspace#

Le paramètre systemDatastoresAuthMode: identity fait accéder le workspace à son storage avec sa managed identity plutôt qu'avec la clé partagée : c'est la configuration à viser si le storage a allowSharedKeyAccess à false.

2.2 Le workspace en Bicep#

Exemple construit sur les propriétés documentées de la ressource (API 2025-06-01, celle qu'utilise le provider azurerm 5.x ; la référence Bicep liste aussi 2025-09-01) et sur le format des règles sortantes de la référence workspaces/managedNetworks/outboundRules :

// main.bicep : workspace Azure Machine Learning fermé (sortie approuvée seulement, pas d'accès public)
param location string = resourceGroup().location
param workspaceName string = 'mlw-demo-prd'
param storageAccountId string        // ressources associées créées par d'autres modules
param keyVaultId string
param applicationInsightsId string

resource workspace 'Microsoft.MachineLearningServices/workspaces@2025-06-01' = {
  name: workspaceName
  location: location
  sku: { name: 'Basic', tier: 'Basic' }
  identity: { type: 'SystemAssigned' }
  properties: {
    friendlyName: workspaceName
    storageAccount: storageAccountId
    keyVault: keyVaultId
    applicationInsights: applicationInsightsId
    systemDatastoresAuthMode: 'Identity'      // AccessKey | Identity | UserDelegationSAS : accès au storage sans clé
    publicNetworkAccess: 'Disabled'           // entrée : private endpoint uniquement
    managedNetwork: {
      isolationMode: 'AllowOnlyApprovedOutbound'   // Disabled | AllowInternetOutbound | AllowOnlyApprovedOutbound
      outboundRules: {                             // map nom → règle ; FQDN seulement en AllowOnlyApprovedOutbound
        pypi: {
          type: 'FQDN'                             // FQDN | PrivateEndpoint | ServiceTag
          destination: 'pypi.org'
          category: 'UserDefined'
        }
      }
    }
  }
}

az deployment group create --resource-group rg-ml-prd --template-file main.bicep \
  --parameters storageAccountId=... keyVaultId=... applicationInsightsId=...

Microsoft publie des modèles complets dans les Azure Quickstart Templates (machine-learning-workspace-vnet, aifoundry-networking-aoao), cités par la référence Bicep de la ressource.

2.3 Le même en CLI v2 (YAML)#

az extension add -n ml                           # CLI v2
az ml workspace create -g rg-ml-prd --file workspace.yml

# workspace.yml
$schema: https://azuremlschemas.azureedge.net/latest/workspace.schema.json
name: mlw-demo-prd
location: westeurope
public_network_access: Disabled
image_build_compute: cpu-cluster          # l'ACR privé ne construit plus les images
managed_network:
  isolation_mode: allow_only_approved_outbound
  outbound_rules:
  - name: pypi
    type: fqdn
    destination: 'pypi.org'

Puis la couche workspace, toujours en YAML versionné :

az ml compute create -n cpu-cluster --type AmlCompute --min-instances 0 --max-instances 10
az ml environment create --file environment.yml
az ml job create --file pipeline.yml

2.4 Et en Terraform#

Les arguments ci-dessous sont vérifiés dans le registre (azurerm 5.10.0) :

resource "azurerm_machine_learning_workspace" "ml" {
  name                          = "mlw-demo-prd"
  location                      = azurerm_resource_group.ml.location
  resource_group_name           = azurerm_resource_group.ml.name
  application_insights_id       = azurerm_application_insights.ml.id   # Required
  key_vault_id                  = azurerm_key_vault.ml.id              # Required
  storage_account_id            = azurerm_storage_account.ml.id        # Required
  public_network_access_enabled = false
  storage_account_access_type   = "Identity"                           # défaut : AccessKey

  identity {
    type = "SystemAssigned"
  }

  managed_network {
    isolation_mode = "AllowOnlyApprovedOutbound"
  }
}

resource "azurerm_machine_learning_workspace_network_outbound_rule_fqdn" "pypi" {
  name             = "pypi"
  workspace_id     = azurerm_machine_learning_workspace.ml.id
  destination_fqdn = "pypi.org"
}

Deux pièges du registre : container_registry_id exige un ACR avec admin_enabled = true, et public_network_access_enabled vaut true par défaut. Les règles sortantes ont chacune leur ressource (…_outbound_rule_fqdn, …_private_endpoint, …_service_tag).

3. Restrict network access au workspace#

3.1 Deux sens, deux mécanismes#

3.2 Le managed virtual network#

Le workspace crée un VNet géré par Microsoft, dans lequel tournent ses computes managés. On choisit un isolation mode :

Ce qu'il faut savoir sur les règles :

• Règles requises automatiques : des private endpoints vers le workspace et ses ressources associées (storage, Key Vault, ACR). En allow internet outbound, seulement pour les ressources dont l'accès public est coupé ; en allow only approved outbound, toujours.
• FQDN : seulement en allow only approved outbound, ports 80 et 443 uniquement. La première règle FQDN déploie un Azure Firewall managé et facturé (Standard par défaut, Basic possible avec firewall_sku: basic ; Premium non pris en charge, donc pas de filtrage par URL). Un FQDN ne permet pas d'atteindre un storage account : il faut un private endpoint.
• Service tags requis pour fonctionner : AzureMachineLearning, AzureActiveDirectory, BatchNodeManagement.<region>, AzureResourceManager, AzureFrontDoor.FirstParty, MicrosoftContainerRegistry, AzureMonitor, VirtualNetwork.
• Exfiltration : la protection est automatique en allow only approved outbound, mais chaque règle ajoutée (vers un FQDN par exemple) est une sortie que Microsoft ne garantit plus.
• Approbation des private endpoints : depuis le 30/04/2025, la managed identity du workspace doit pouvoir approuver les connexions sur les ressources cibles ; Microsoft recommande le rôle Azure AI Enterprise Network Connection Approver.

Le provisionnement du réseau est différé : il se fait à la création du premier compute (environ 30 minutes, plus environ 10 minutes pour la première règle FQDN). Pour éviter les timeouts, on le lance à l'avance :

az ml workspace create -n mlw-demo-prd -g rg-ml-prd --managed-network AllowInternetOutbound --provision-network-now
az ml workspace provision-network -g rg-ml-prd -n mlw-demo-prd          # ajouter --include-spark pour serverless Spark
az ml workspace outbound-rule list --workspace-name mlw-demo-prd --resource-group rg-ml-prd

Une online deployment exige que le réseau soit déjà provisionné (manuellement ou par un compute instance). Pour serverless Spark, le provisionnement manuel avec --include-spark est obligatoire.

Limites à connaître :

• on ne désactive plus l'isolation une fois activée, et on ne repasse pas d'allow only approved à allow internet ;
• pas de Kubernetes attaché ni de VM attachée dans un managed VNet, et pas de compute dans ton propre VNet ;
• compute cluster dans la même région que le workspace ;
• pas de scope locks sur les ressources Azure Machine Learning et leur groupe de ressources (opérations internes bloquées) ;
• une ressource ne peut pas avoir à la fois un private endpoint et un service endpoint ;
• activer le managed VNet sur un workspace existant impose de supprimer et recréer compute instances, compute clusters et managed online endpoints ;
• le managed VNet est supprimé avec le workspace.

3.3 L'accès entrant#

• publicNetworkAccess : Disabled, ou Enabled from selected IP addresses (règles network_acls). Retirer le private endpoint ne rend pas le workspace public : c'est ce paramètre qui décide.
• Private endpoint : sous-ressource amlworkspace, zones DNS privatelink.api.azureml.ms et privatelink.notebooks.azure.net. Les managed online endpoints partagent le private endpoint du workspace.
• Le studio s'exécute en partie dans le navigateur et parle directement au default storage : le réseau client a besoin de ses propres private endpoints (blob, file) vers ce storage. Si l'accès public du storage est coupé, donner le rôle Reader à la managed identity du workspace sur ces private endpoints.
• Batch endpoints : pas de public_network_access propre et pas de selected IPs ; ils deviennent privés quand le workspace passe en Private Link, et restent privés si l'on rouvre ensuite l'accès public du workspace.

az network private-endpoint create --name pe-mlw-prd --vnet-name vnet-spoke-ml --subnet snet-pe \
  --private-connection-resource-id "/subscriptions/<sub>/resourceGroups/rg-ml-prd/providers/Microsoft.MachineLearningServices/workspaces/mlw-demo-prd" \
  --group-id amlworkspace --connection-name workspace -l westeurope

az ml workspace update -g rg-ml-prd -n mlw-demo-prd --public-network-access Enabled --network-acls "16.17.18.0/24"

Avec un DNS d'entreprise, transférer sous condition vers 168.63.129.16 les zones api.azureml.ms, notebooks.azure.net, instances.ml.azure.ms, aznbcontent.net et inference.ml.azure.com.

3.4 Quel mode choisir#

flowchart TD
    A["Les données d'entraînement sont-elles sensibles ?"] -->|Non, accès public assumé| D["Disabled"]
    A -->|Oui| B["Les jobs doivent-ils télécharger des paquets ou des modèles publics librement ?"]
    B -->|Oui, et le risque est accepté| I["Allow internet outbound + private endpoints vers les ressources Azure"]
    B -->|Non, sortie contrôlée exigée| C["Allow only approved outbound"]
    C --> E["Paquets : règles FQDN (Azure Firewall facturé) ou dépôt privé de paquets"]
    C --> F["Ressources Azure : règles private endpoint"]

4. Configure GitHub integration avec Azure Machine Learning#

« GitHub integration » couvre deux besoins distincts : l'accès de la CI à Azure, et l'accès des data scientists au dépôt depuis le workspace (voir section 6).

4.1 La CI : OpenID Connect plutôt qu'un secret#

La méthode recommandée par Microsoft est OIDC : un federated credential sur une app registration ou une user-assigned managed identity fait confiance aux jetons émis par GitHub Actions pour ton dépôt. Le service principal avec un secret (AZURE_CREDENTIALS) fonctionne encore, mais Microsoft le juge moins sûr.

sequenceDiagram
    participant W as Workflow GitHub Actions
    participant G as GitHub OIDC provider
    participant E as Microsoft Entra ID
    participant A as Azure Machine Learning
    W->>G: demande un jeton OIDC (permission id-token write)
    G-->>W: jeton signé, subject repo:org/repo:environment:prod
    W->>E: azure/login avec client-id, tenant-id, subscription-id
    E->>E: compare issuer, subject et audience au federated credential
    E-->>W: jeton d'accès Azure
    W->>A: az ml job create --file pipeline.yml

Étapes :

1. Créer l'identité (app registration ou user-assigned managed identity) et lui donner le rôle utile (section 4.2).
2. Ajouter un federated credential « GitHub Actions » pour l'organisation, le dépôt et le type d'entité (branche, environment, pull request, tag) : le subject doit correspondre exactement.
3. Créer les secrets AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_SUBSCRIPTION_ID (aucun mot de passe). Sur un dépôt public, préférer les environment secrets : un job n'y accède qu'après approbation des reviewers de l'environnement.
4. Dans le workflow : permissions: id-token: write, puis azure/login@v2.

4.2 Les rôles de l'identité de CI#

Le détail du contrôle d'accès du workspace (rôles, custom roles, identités des computes) est au chapitre 01.

5. Automate resource provisioning avec GitHub Actions#

5.1 Un workflow en deux jobs#

Workflow construit à partir de l'exemple officiel (azure/login@v2 en OIDC) : un job d'infrastructure, puis un job ML, chacun lié à un environment GitHub.

# .github/workflows/mlops-prd.yml
name: mlops-prd
on:
  push:
    branches: [main]
permissions:
  id-token: write          # obligatoire pour OIDC
  contents: read
jobs:
  infra:
    runs-on: ubuntu-latest
    environment: prod      # approbation par les required reviewers
    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 workspace (Bicep)
      run: az deployment group create -g rg-ml-prd --template-file infra/main.bicep --parameters @infra/prd.parameters.json
  train:
    needs: infra
    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: Submit training pipeline
      run: |
        az extension add -n ml
        az ml job create --file ml/pipeline.yml -g rg-ml-prd -w mlw-demo-prd

Si le workspace n'a plus d'accès public, un runner hébergé par GitHub ne l'atteint plus (conséquence directe de public_network_access: Disabled, pas une page dédiée) : il faut un runner auto-hébergé dans le réseau privé, ou garder une entrée publique limitée par network_acls (Enabled from selected IP addresses, az ml workspace update --network-acls).

5.2 L'équivalent Azure DevOps#

• Service connection Azure Resource Manager, avec l'identité par défaut, workload identity federation (pas de secret). Elle peut être limitée à la portée Machine Learning Workspace.
• Étapes AzureCLI@2 qui lancent az ml job create.
• L'extension Machine Learning (pas l'ancienne « classic ») fournit la tâche AzureML Job Wait dans un server job (pool: server), sans coût d'agent, qui attend au plus deux jours et un seul job. Microsoft signale un problème connu sur la notification RunTerminated : en cas de timeout, interroger az ml job show --query status depuis un agent.

5.3 Promouvoir entre environnements#

• Un workspace et une identité par environnement (dev, test, prod), chacun dans son groupe de ressources, avec ses propres données et son propre compute.
• Le registry porte les assets partagés (models, environments, components, data) : on publie une fois depuis dev, avec la lignée vers le job, le code et les données, puis on déploie dans test et prod.

az ml model share --name churn-model --version 3 --registry-name reg-ml-shared \
  --share-with-name churn-model --share-with-version 3

• GitHub environments : dev sans approbation, test avec tests automatiques, prod avec required reviewers.
• Microsoft propose un accélérateur MLOps (Set up MLOps with GitHub) qui déploie l'infrastructure en Terraform par GitHub Actions (tf-gha-deploy-infra.yml), puis les pipelines d'entraînement et de scoring.

6. Manage source control avec Git#

6.1 Travailler avec Git depuis le workspace#

• Azure Machine Learning n'impose aucun serveur Git : GitHub, Azure Repos, GitLab, Bitbucket conviennent.
• On clone depuis le terminal d'un compute instance :
  • dans le partage du workspace ~/cloudfiles/code : conservé si on recrée le compute instance ;
  • ou sur le disque local du compute instance : plus rapide, mais perdu si on le supprime ;
  • de préférence dans son dossier utilisateur, pour ne pas travailler sur la branche d'un collègue.
• Authentification SSH : ssh-keygen -t ed25519 dans /home/azureuser/.ssh, clé publique ajoutée au fournisseur Git ; la clé n'est accessible qu'au propriétaire du compute instance. Ou HTTPS avec un personal access token.

6.2 La traçabilité automatique#

Quand on soumet un job depuis un dépôt Git local (CLI ou SDK), et si la commande git est disponible, le job enregistre :

az ml job show --name <job> -g rg-ml-prd -w mlw-demo-prd --query "{GitCommit:properties.\"azureml.git.commit\"}"

Pas de git dans l'environnement, ou fichiers hors du dossier cloné : aucune information Git n'est enregistrée.

6.3 Ce qu'on met dans le dépôt#

Une PR vers main déclenche les tests et l'entraînement de validation ; la fusion déclenche la promotion. Un job tracé avec azureml.git.dirty = True ne devrait pas produire un modèle de production.

7. Labs conseillés#

À faire dans un abonnement de test, puis supprimer le groupe de ressources. Coût principal : compute (arrêter les compute instances), Azure Firewall managé dès la première règle FQDN.

1. Workspace en Bicep : déployer main.bicep (section 2.2) avec isolationMode: AllowInternetOutbound ; lancer az ml workspace provision-network ; lister les règles avec az ml workspace outbound-rule list. Attendu : les règles requises existent (private endpoints vers les ressources associées dont l'accès public est coupé).
2. Durcir la sortie : passer en allow only approved outbound, ajouter une règle FQDN pypi.org, créer un compute instance et faire pip install d'un paquet présent sur PyPI puis d'un dépôt non autorisé. Attendu : le premier passe, le second échoue ; un Azure Firewall apparaît dans la facturation. Constater qu'on ne peut plus revenir en arrière.
3. Entrée privée : couper l'accès public, créer le private endpoint amlworkspace et les deux zones DNS, ouvrir le studio depuis une VM du VNet (Bastion) puis depuis ton poste. Attendu : seul l'accès depuis le VNet fonctionne ; tester ensuite Enabled from selected IP addresses avec ton IP.
4. GitHub Actions en OIDC : user-assigned managed identity, federated credential sur l'environment prod, rôle AzureML Data Scientist, workflow de la section 5.1 réduit au job train. Attendu : le job tourne sans aucun secret ; il échoue si le workflow vise un autre environment que celui du subject.
5. Traçabilité Git : cloner le dépôt sur un compute instance, soumettre un job avec un fichier modifié non commité, puis après commit. Attendu : azureml.git.dirty passe de True à False, le commit apparaît dans les propriétés.

8. Pièges d'examen#

9. Scénarios d'entraînement#

1. Une équipe veut empêcher toute fuite de données depuis les jobs d'entraînement, tout en installant des paquets depuis pypi.org. Que configurer ?

Allow only approved outbound sur le managed VNet, avec une règle FQDN pypi.org (et les FQDN nécessaires) ; prévoir le coût de l'Azure Firewall managé. Variante sans firewall : un dépôt privé de paquets joint par private endpoint.

2. Le workspace est en allow internet outbound. La sécurité demande maintenant une sortie approuvée, puis, un mois plus tard, l'équipe veut revenir en arrière. Est-ce possible ?

Le durcissement oui ; le retour non : on ne repasse pas d'allow only approved outbound à allow internet outbound. Le signaler avant la bascule.

3. Après activation du managed VNet, le premier compute instance met plus de 30 minutes à se créer et finit en timeout. Que faire ?

Provisionner le réseau à l'avance : az ml workspace provision-network (ou --provision-network-now à la création), attendre la fin, puis créer le compute.

4. Les data scientists ouvrent le studio par le private endpoint du workspace, mais l'onglet de données reste vide et les notebooks ne s'ouvrent pas. Cause probable ?

Le navigateur n'atteint pas le default storage : ajouter des private endpoints blob et file vers ce storage dans le réseau client (et le rôle Reader pour l'identité du workspace sur ces private endpoints si l'accès public du storage est coupé).

5. Le pipeline GitHub Actions utilise un service principal avec un secret qui expire tous les six mois. Comment le remplacer ?

Une user-assigned managed identity (ou app registration) avec federated credential GitHub, permissions: id-token: write, azure/login@v2 avec client-id, tenant-id, subscription-id ; supprimer le secret.

6. L'identité de CI doit soumettre des pipelines et enregistrer des modèles, mais pas créer de compute ni modifier le workspace. Quel rôle ?

AzureML Data Scientist sur le workspace.

7. Après le passage du Container Registry en privé, la création d'environments échoue. Quelle correction ?

Définir un compute de build : az ml workspace update --image-build-compute <cluster> (ou image_build_compute dans le YAML), et autoriser ce compute à joindre les dépôts de paquets.

8. Le RSSI veut prouver quel code a produit le modèle en production. Que vérifier ?

Les propriétés du job d'entraînement : mlflow.source.git.commit, branch, repoURL, et azureml.git.dirty = False ; le modèle publié dans le registry garde le lien vers ce job.

9. On veut ajouter un cluster AKS attaché comme cible d'inférence à un workspace en managed VNet. Réponse ?

Non pris en charge : Kubernetes attaché et VM attachées ne fonctionnent pas dans un managed VNet ; utiliser des managed online endpoints, ou un workspace sans managed VNet avec ton propre VNet.

10. Le workspace a publicNetworkAccess: Disabled. Le pipeline lancé sur un runner hébergé par GitHub échoue sur az ml job create. Pourquoi, et quelles options ?

az ml parle au workspace, inaccessible depuis Internet. Options : runner auto-hébergé dans le réseau privé, ou ouvrir l'entrée à des IP précises (Enabled from selected IP addresses), selon la politique de sécurité.

10. Pour aller plus loin#

• Modèles Microsoft : Azure Quickstart Templates machine-learning-workspace-vnet et aifoundry-networking-aoao ; le second sert aussi au chapitre 05 (Foundry en réseau privé).
• Azure Policy : la définition intégrée Azure Machine Learning Computes should be in a virtual network (Audit) et la conformité réseau générale (SC-500 03).
• Encryption : clés gérées par le client (encryption dans Terraform, avec purge protection sur le Key Vault), au chapitre 01.
• Serverless Spark : règle private endpoint vers le storage avec spark_enabled: true, puis provisionnement avec --include-spark ; en sortie approuvée, les dépendances conda des sessions Spark ne s'installent pas (wheel autonome dans un storage privé).

11. Fiche à retenir#

• Deux couches : Bicep / Terraform pour le workspace et ses associated resources, az ml + YAML pour son contenu.
• Associated resources : storage account (pas Premium), Key Vault (trusted services si pare-feu), Application Insights, ACR.
• systemDatastoresAuthMode: identity = accès au storage par la managed identity, sans clé.
• Managed VNet : Disabled, Allow internet outbound (règles PE), Allow only approved outbound (PE, service tag, FQDN). Bascule à sens unique, pas de désactivation.
• FQDN = Azure Firewall managé facturé, ports 80/443, Standard ou Basic (pas Premium) ; pas pour un storage account.
• Réseau provisionné au 1er compute (~30 min) ou par az ml workspace provision-network ; obligatoire avant une online deployment.
• Pas de Kubernetes ni de VM attachés en managed VNet ; pas de scope lock.
• Entrée : publicNetworkAccess (Disabled ou selected IPs) + private endpoint amlworkspace + zones privatelink.api.azureml.ms et privatelink.notebooks.azure.net.
• Studio : private endpoints blob et file vers le default storage côté client.
• ACR privé → image_build_compute.
• CI : OIDC (federated credential, id-token: write, azure/login@v2), secrets AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_SUBSCRIPTION_ID.
• Rôles CI : AzureML Data Scientist (pas de compute), AzureML Compute Operator, AzureML Registry User, Contributor pour la Bicep.
• Git : clone sur compute instance (~/cloudfiles/code persistant), propriétés mlflow.source.git.* et azureml.git.dirty sur chaque job.
• Promotion : un workspace par environnement, assets partagés par registry, GitHub environments avec approbation.

Références#

Lues le 21/10/2026 :

• Study guide for Exam AI-300
• Workspace managed virtual network isolation
• Configure a private endpoint for an Azure Machine Learning workspace
• How to use your workspace with a custom DNS server
• Azure Private Endpoint private DNS zone values
• Network isolation with managed online endpoints
• Manage Azure Machine Learning workspaces by using Azure CLI
• Disable shared key access for the workspace storage account
• Microsoft.MachineLearningServices workspaces (référence Bicep)
• Use GitHub Actions with Azure Machine Learning
• Set up MLOps with GitHub
• Use Azure Pipelines with Azure Machine Learning
• Connect to Azure with an Azure Resource Manager service connection
• Manage access to Azure Machine Learning workspaces
• Azure built-in roles for AI + machine learning
• Git integration for Azure Machine Learning
• Machine learning registries for MLOps
• Share models, components, and environments across workspaces with registries
• Terraform azurerm_machine_learning_workspace (azurerm 5.10.0)