Azure ML and ADF Automation

Overview

Use this skill for Azure Machine Learning automation that registers code assets in CI and orchestrates training, scoring, registration, or deployment through Azure Data Factory. The main invariant is that runtime systems must consume the exact Azure ML asset versions that were actually registered, not the versions a pipeline attempted to request. Validate every recommendation against runtime behavior because Azure ML, ADF, storage networking, and SDK dependency behavior can diverge from static API documentation.

Core Invariants

• CI owns Azure ML code asset registration and publishes the actual SDK-returned version.
• ADF receives code versions through an explicit contract, usually a storage pointer blob, instead of discovering AML code versions at runtime.
• The SDK result is the source of truth: requested version, build ID, branch name, or commit-derived strings are not authoritative.
• Private storage requires both correct RBAC and proven data-plane reachability from the executing runtime.
• ADF WebActivity networking must be tested through the intended integration runtime, not just validated as JSON.
• Dependency constraints for Azure ML automation are pinned in CI environments.
• Runtime evidence beats plausible ARM paths, documentation snippets, or successful template compilation.

Azure ML Code Asset Registration

Prefer the Python SDK for registering Azure ML code assets when automation must reliably capture the registered version. Use the Azure CLI only after confirming the target environment's az ml extension supports the needed code commands and returns enough information for downstream automation.