Dernière révision : mai 2026
Configurez les services AWS figurant à l'examen DP-100 avec Terraform simple — un bloc à la fois, chacun étant lié à un domaine de l'examen. Le même code fonctionne sur OpenTofu.
À la fin de ce laboratoire, vous aurez provisionné, avec Terraform simple, le plan de contrôle de l'espace de travail Azure Machine Learning — l'espace de travail lui-même, les trois dépendances requises (Compte de stockage, Key Vault, Application Insights), et un cluster de calcul Azure ML mis à l'échelle à zéro en mode inactif afin que le laboratoire ne coûte pas cher. C'est la configuration de l'espace de travail de référence DP-100 ; les tâches d'entraînement et les déploiements de modèles s'y connectent.
Déposez les extraits dans un seul fichier main.tf, exécutez terraform init, puis terraform apply étape par étape.
>= 1.5 ou OpenTofu >= 1.6.az login).Le plan de contrôle est inactif à près de 0 $:
Le piège de coût du DP-100 est de laisser le min_node_count > 0 du cluster de calcul — même un nœud inactif coûte plus de 200 $/mois. Nous avons défini min_node_count = 0 et scale_down_nodes_after_idle_duration = PT15M (mise à l'échelle à la baisse 15 minutes après l'inactivité). Vérifiez avant d'exécuter. Détruisez une fois terminé.
Ouverture Azure standard. Les espaces de travail Azure ML sont régionaux — choisissez une région avec une large disponibilité de SKU GPU si vous allez au-delà du laboratoire (eastus, westus, westeurope sont les choix sûrs).
terraform {
required_version = ">= 1.5"
required_providers {
azurerm = { source = "hashicorp/azurerm", version = "~> 4.0" }
random = { source = "hashicorp/random", version = "~> 3.6" }
}
}
provider "azurerm" {
features {
key_vault {
purge_soft_delete_on_destroy = true
}
}
}
resource "random_id" "suffix" {
byte_length = 3
}
data "azurerm_client_config" "current" {}
locals {
tags = {
Project = "certlabpro-dp-100"
ManagedBy = "terraform"
}
}
resource "azurerm_resource_group" "main" {
name = "certlabpro-dp-100-rg"
location = "eastus"
tags = local.tags
}Les espaces de travail Azure ML nécessitent trois ressources préexistantes auxquelles se connecter : un compte de stockage (pour les jeux de données, les modèles, les journaux), un Key Vault (pour les informations d'identification) et une instance Application Insights (pour la télémétrie des exécutions). Le DP-100 teste ce triplet à plusieurs reprises — "pourquoi ne puis-je pas créer l'espace de travail ?" manque presque toujours l'une de ces ressources.
Le compte de stockage ici reçoit les valeurs par défaut sécurisées standard ; le Key Vault utilise l'autorisation RBAC (la valeur par défaut moderne).
resource "azurerm_storage_account" "ml" {
name = "dp100ml${random_id.suffix.hex}"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
account_tier = "Standard"
account_replication_type = "LRS"
account_kind = "StorageV2"
https_traffic_only_enabled = true
min_tls_version = "TLS1_2"
allow_nested_items_to_be_public = false
tags = local.tags
}
resource "azurerm_key_vault" "ml" {
name = "kv-dp100-${random_id.suffix.hex}"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
tenant_id = data.azurerm_client_config.current.tenant_id
sku_name = "standard"
enable_rbac_authorization = true
soft_delete_retention_days = 7
tags = local.tags
}
resource "azurerm_application_insights" "ml" {
name = "appi-dp100-${random_id.suffix.hex}"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
application_type = "web"
tags = local.tags
}L'espace de travail lie les trois dépendances et obtient une identité gérée attribuée par le système que les cibles de calcul, les jeux de données et les points de terminaison en aval utiliseront pour lire les dépendances. Le domaine Gérer les ressources Azure pour le ML du DP-100 teste cette forme exacte — espace de travail + identité + attributions de rôles.
Nous avons défini public_network_access_enabled = true pour simplifier le laboratoire ; les espaces de travail de production utilisent généralement des points de terminaison privés (le domaine Concevoir et préparer une solution d'apprentissage automatique du DP-100 teste les variantes de liaison privée).
resource "azurerm_machine_learning_workspace" "main" {
name = "mlw-dp100-${random_id.suffix.hex}"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
application_insights_id = azurerm_application_insights.ml.id
key_vault_id = azurerm_key_vault.ml.id
storage_account_id = azurerm_storage_account.ml.id
public_network_access_enabled = true
identity {
type = "SystemAssigned"
}
tags = local.tags
}Les tâches d'entraînement nécessitent du calcul. Les clusters de calcul Azure ML sont des pools de VM gérés qui s'adaptent en fonction de la profondeur de la file d'attente des tâches. min_node_count = 0 est le paramètre obligatoire d'optimisation des coûts du DP-100 pour les espaces de travail de laboratoire/développement — lorsqu'aucune tâche n'est en file d'attente, le cluster se met à l'échelle à zéro nœud et ne facture 0 $ (juste les métadonnées).
Standard_DS3_v2 (4 vCPU, 14 Go de RAM, 0,30 $/heure) est le défaut typique des laboratoires — suffisamment grand pour exécuter des tâches d'entraînement sklearn ou de petits PyTorch, suffisamment petit pour être bon marché. Les clusters d'entraînement de production utilisent des SKU GPU (famille Standard_NC6s_v3).
Le scale_down_nodes_after_idle_duration = "PT15M" (durée ISO 8601 pour 15 minutes) est la question de coût récurrente du DP-100 : le définir trop long laisse des nœuds coûteux en cours d'exécution ; trop court provoque des à-coups. 15 minutes est le défaut Azure documenté.
resource "azurerm_machine_learning_compute_cluster" "main" {
name = "cpu-cluster"
location = azurerm_resource_group.main.location
vm_priority = "Dedicated"
vm_size = "Standard_DS3_v2"
machine_learning_workspace_id = azurerm_machine_learning_workspace.main.id
scale_settings {
min_node_count = 0
max_node_count = 2
scale_down_nodes_after_idle_duration = "PT15M"
}
identity {
type = "SystemAssigned"
}
tags = local.tags
}terraform destroy supprime tout. Points clés :
purge_soft_delete_on_destroy = true dans les fonctionnalités du fournisseur permet à la destruction du Key Vault de purger réellement. La suppression logicielle de l'espace de travail est configurable dans le portail mais terraform destroy fonctionne de toute façon.Le DP-100 couvre davantage de surfaces ML-sur-Azure que ce laboratoire ne peut contenir — Instances de calcul (VM IDE mono-utilisateur, très coûteuses en mode inactif), Points de terminaison en ligne (inférence gérée en temps réel), Points de terminaison par lots (inférence par lots gérée), tâches AutoML, Designer (éditeur de pipeline visuel), intégration du suivi MLflow, ParallelRunStep, workflows de promotion de registre de modèles, et l'ensemble du catalogue d'actifs de données/magasins de données.
Nous nous en tenons au plan de contrôle de l'espace de travail car c'est le substrat auquel chaque modèle DP-100 se connecte. Les points de terminaison se connectent à l'espace de travail. Les tâches s'exécutent sur le cluster de calcul. Les modèles s'enregistrent via le suivi MLflow de l'espace de travail. Les jeux de données sont stockés dans le compte de stockage.
Pour les surfaces ci-dessus, consultez les sections Parcourir et Editorial de cette page de certification. Les domaines Entraîner des modèles ML et Déployer et opérationnaliser des solutions ML du DP-100 s'apprennent mieux en exécutant des tâches sur cet espace de travail — le laboratoire vous donne le substrat ; le SDK Python effectue l'entraînement et le déploiement réels.