Zuletzt überprüft: Mai 2026
Erstellen Sie die AWS-Dienste der DP-100-Prüfung mit reinem Terraform — ein Block nach dem anderen, jeweils abgestimmt auf eine Prüfungsdomäne. Derselbe Code funktioniert auch mit OpenTofu.
Am Ende dieses Labs werden Sie mit einfachem Terraform die Steuerungsebene des Azure Machine Learning-Arbeitsbereichs bereitgestellt haben – den Arbeitsbereich selbst, die drei erforderlichen Abhängigkeiten (Speicherkonto, Key Vault, Application Insights) und einen Azure ML-Computecluster, der im Leerlauf auf null skaliert wird, damit das Lab keine unnötigen Kosten verursacht. Dies ist das DP-100-Referenz-Arbeitsbereichs-Setup; Trainingsaufträge und Modellbereitstellungen werden hieran angeschlossen.
Fügen Sie die Snippets in eine einzige main.tf ein, führen Sie terraform init aus und anschließend terraform apply Schritt für Schritt.
>= 1.5 oder OpenTofu >= 1.6.az login).Steuerungsebene im Leerlauf bei fast 0 $:
Die DP-100-Kostenfalle besteht darin, den min_node_count des Compute-Clusters > 0 zu lassen – selbst ein einziger leerer Knoten verursacht Kosten von über 200 $/Monat. Wir setzen min_node_count = 0 und scale_down_nodes_after_idle_duration = PT15M (Skalierung nach 15 Minuten Inaktivität). Vor der Ausführung überprüfen. Nach Abschluss zerstören.
Standard-Azure-Einstieg. Azure ML-Arbeitsbereiche sind regional – wählen Sie eine Region mit breiter Verfügbarkeit von GPU-SKUs, wenn Sie über dieses Lab hinausgehen (eastus, westus, westeurope sind die sicheren Optionen).
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
}Azure ML-Arbeitsbereiche erfordern drei bereits vorhandene Ressourcen, an die sie angehängt werden: ein Speicherkonto (für Datensätze, Modelle, Logs), einen Key Vault (für Anmeldeinformationen) und eine Application Insights-Instanz (für die Telemetrie von Ausführungen). DP-100 testet dieses Triplett wiederholt – „Warum kann ich den Arbeitsbereich nicht erstellen?“ liegt fast immer daran, dass eine dieser Ressourcen fehlt.
Das Speicherkonto erhält hier die standardmäßigen sicheren Voreinstellungen; der Key Vault verwendet die RBAC-Autorisierung (der moderne Standard).
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
}Der Arbeitsbereich verbindet die drei Abhängigkeiten und erhält eine systemseitig zugewiesene verwaltete Identität, die nachgelagerte Compute-Ziele, Datensätze und Endpunkte zum Lesen aus den Abhängigkeiten verwenden werden. Der DP-100-Bereich Azure-Ressourcen für ML verwalten testet genau diese Form – Arbeitsbereich + Identität + Rollenzuweisungen.
Wir setzen public_network_access_enabled = true, um das Lab einfach zu halten; Produktions-Arbeitsbereiche verwenden typischerweise private Endpunkte (der DP-100-Bereich Entwerfen und Vorbereiten einer Machine-Learning-Lösung testet Private-Link-Varianten).
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
}Trainingsaufträge benötigen Rechenleistung. Azure ML-Computecluster sind verwaltete VM-Pools, die sich basierend auf der Tiefe der Auftragswarteschlange skalieren. min_node_count = 0 ist die obligatorische DP-100-Kostenoptimierungseinstellung für Lab-/Entwicklungs-Arbeitsbereiche – wenn keine Aufträge in der Warteschlange stehen, skaliert der Cluster auf null Knoten und verursacht 0 $ Kosten (nur Metadaten).
Standard_DS3_v2 (4 vCPU, 14 GB RAM, 0,30 $/Stunde) ist der typische Lab-Standard – groß genug, um sklearn- oder kleine PyTorch-Trainingsaufträge auszuführen, klein genug, um günstig zu sein. Produktions-Trainingscluster verwenden GPU-SKUs (Familie Standard_NC6s_v3).
Die Einstellung scale_down_nodes_after_idle_duration = "PT15M" (ISO 8601-Dauer für 15 Minuten) ist die wiederkehrende DP-100-Kostenfrage: Eine zu lange Einstellung lässt teure Knoten laufen; eine zu kurze Einstellung führt zu unnötigem Aufwand. 15 Minuten ist der dokumentierte Azure-Standard.
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 reißt alles ab. Wichtige Hinweise:
purge_soft_delete_on_destroy = true in den Provider-Funktionen bewirkt, dass Key Vault beim Zerstören tatsächlich geleert wird. Die Soft-Delete-Funktion des Arbeitsbereichs ist im Portal konfigurierbar, aber terraform destroy funktioniert unabhängig davon.DP-100 deckt weitere ML-auf-Azure-Bereiche ab, die in diesem Lab nicht behandelt werden können – Compute-Instanzen (Einzelbenutzer-IDE-VMs, sehr teuer im Leerlauf), Online-Endpunkte (verwaltete Echtzeit-Inferenz), Batch-Endpunkte (verwaltete Batch-Inferenz), AutoML-Aufträge, Designer (visueller Pipeline-Editor), MLflow-Tracking-Integration, ParallelRunStep, Modellregister-Beförderungs-Workflows und der gesamte Daten-Asset-/Datenspeicher-Katalog.
Wir konzentrieren uns auf die Steuerungsebene des Arbeitsbereichs, da sie das Substrat ist, an das sich jedes DP-100-Muster anbindet. Endpunkte werden an den Arbeitsbereich angebunden. Aufträge laufen auf dem Computecluster. Modelle werden gegen das MLflow-Tracking des Arbeitsbereichs registriert. Datensätze landen im Speicherkonto.
Für die oben genannten Bereiche sehen Sie die Abschnitte Durchsuchen und Editorial dieser Zertifizierungsseite. Die DP-100-Bereiche ML-Modelle trainieren und ML-Lösungen bereitstellen und operationalisieren lassen sich am besten durch das Ausführen von Aufträgen gegen diesen Arbeitsbereich erlernen – das Lab gibt Ihnen das Substrat; das Python SDK übernimmt das eigentliche Training und die Bereitstellung.