Azure ML Data Asset Version Sprawl Sentinel

Every retrain of a model that registers its training data as a new Azure Machine Learning data asset version adds one more entry nobody ever prunes; a data asset can accumulate hundreds of versions with no policy enforcing which ones still matter. Azure ML's own studio shows a version list if someone opens it; it does not compare the count against a limit you declare or notify anyone when it sprawls.

This blueprint was created by Mohit Jeswani.

How it works

1. list_data_versions (io.kestra.plugin.azure.ml.ListDataVersions) lists every registered version of data_name, most recent first. Read-only; nothing in Azure ML is changed. allowFailure: true covers a missing data asset or an auth error without failing the flow outright.
2. evaluate (io.kestra.plugin.core.output.OutputValues) counts the versions and reads the newest one with a jq filter.
3. route (io.kestra.plugin.core.flow.If):
   • compliant: logs the version count, below threshold.
   • alert: posts the count and latest version to Slack.
4. summary logs the count and severity, closing the governance cycle.
5. errors alerts Slack if the flow itself fails, for example an expired service principal secret.

What you get

• A real registered-version count straight from the Azure ML workspace, not an estimate from a dashboard someone has to remember to open.
• The latest version name in the Slack alert, so whoever responds knows the current state without a separate lookup.
• A read-only check with zero risk of registering, deleting, or modifying a real version.

Who it's for

• AI platform and ML ops teams running Azure Machine Learning who want data asset version sprawl caught on a schedule, not discovered when workspace storage costs spike.
• Teams evaluating the Azure plugin who want a worked example of ml.ListDataVersions used as a standing resource quota check, the first blueprint in this repo to use the ml sub-package of the Azure plugin at all.

Why orchestrate this with Kestra

Azure ML lists a data asset's versions on request; it does not keep a schedule, compare the count against a tolerance you declare, or notify a Slack channel when it sprawls. Kestra keeps max_version_count as a flow input, turns the list into a Slack page naming the real count and latest version, and keeps a full execution history of every run.

Prerequisites

• An Azure Machine Learning workspace with a data asset that has at least one registered version.
• An Azure Entra ID service principal with read access to that workspace.
• A Slack incoming webhook URL.

This flow calls the Azure Resource Manager API directly over HTTPS; there is no official local Azure ML emulator, so list_data_versions cannot be exercised against a local Docker container.

Secrets

• AZURE_TENANT_ID / AZURE_CLIENT_ID / AZURE_CLIENT_SECRET / AZURE_SUBSCRIPTION_ID: the Entra ID service principal credentials used by list_data_versions. In Kestra OSS, provide them as the base64-encoded environment variables SECRET_AZURE_TENANT_ID, SECRET_AZURE_CLIENT_ID, SECRET_AZURE_CLIENT_SECRET, and SECRET_AZURE_SUBSCRIPTION_ID.
• SLACK_WEBHOOK_URL: used by alert and the errors block. In Kestra OSS, provide it as the base64-encoded environment variable SECRET_SLACK_WEBHOOK_URL.

Inputs

Input	Default	Purpose
data_name	<your-data-asset-name>	Data asset to audit
max_version_count	20	Registered-version count at or above which the alert fires

Outputs

• {{ outputs.list_data_versions.versions }}: every registered version (version, uri), most recent first.
• {{ outputs.evaluate.values.version_count }} / .latest_version: how many versions exist and the newest version name.
• {{ outputs.evaluate.values.severity }}: OK, VERSION_SPRAWL, or CRITICAL.

Pitfalls

• ListDataVersions throws if data_name does not exist in the workspace at all; a typo in the name surfaces via allowFailure as CRITICAL, not a silently empty version list.
• The task's own output does not expose each version's creation timestamp, only its name and storage URI; this check can enforce a count ceiling but not an age-based retention policy on its own.
• A version count below max_version_count does not mean the versions are all still in use; this is a volume check, not a usage audit.

Quick start

1. Add the four Azure secrets and SLACK_WEBHOOK_URL.
2. Set resource_group_name, workspace_name, and data_name to a real data asset.
3. Run the flow manually and confirm summary logs a count.
4. Lower max_version_count below the real current count to confirm alert fires.
5. Restore a real threshold and enable the weekly trigger.

How to extend

• Loop over several data_name values with io.kestra.plugin.core.flow.Loop to audit every data asset in a workspace in one scheduled run.
• Chain a task that deletes the oldest versions beyond a retention count, gated behind an explicit confirm_prune input, since this plugin has no delete-version task of its own to call directly.
• Add io.kestra.plugin.azure.ml.ListDataVersions results from multiple data assets into one combined sprawl report instead of auditing one asset per run.

Links

• Azure plugin: https://kestra.io/plugins/plugin-azure
• Azure ML data asset versioning reference: https://learn.microsoft.com/en-us/azure/machine-learning/how-to-manage-models-mlflow
• Slack incoming webhooks: https://api.slack.com/messaging/webhooks