3.3 Create and Manage Components

Create and Manage Components

Quick Answer: A component is a reusable Azure Machine Learning pipeline step: name, typed inputs/outputs, code, environment, and command. Author command component YAML (type: command), register with az ml component create, and reference azureml:<name>:<version> from pipeline jobs. Version the component instead of copying train.py into every team’s repo.

Domain 1’s “create and manage components” bullet is the MLOps answer to “we have twelve slightly different training scripts.” A pipeline is the whole workflow (prep → train → evaluate). A component is one step in that workflow with a function-like contract.

Anatomy of a component

Microsoft describes three parts:

1. Metadata — name, display_name, version, type, description, tags.
2. Interface — named inputs and outputs with types, defaults, min/max, enum, optional.
3. Body — command (the shell line), code (directory uploaded as a snapshot), environment (curated or custom).

That split is why components scale across teams. The consumer only needs the interface: “this step takes a uri_folder of images and an integer epochs, and emits an mlflow_model.” They do not need to know whether the body is Python or R, as long as a shell command can launch it.

Command component YAML (CLI/SDK v2)

Schema: https://azuremlschemas.azureedge.net/latest/commandComponent.schema.json.

$schema: https://azuremlschemas.azureedge.net/latest/commandComponent.schema.json
name: train_linear_regression_model
display_name: TrainLinearRegressionModel
version: "1"
type: command
inputs:
  training_data:
    type: uri_folder
  test_split_ratio:
    type: number
    min: 0
    max: 1
    default: 0.2
outputs:
  model_output:
    type: mlflow_model
  test_data:
    type: uri_folder
code: ./train_src
environment: azureml://registries/azureml/environments/sklearn-1.5/labels/latest
command: >-
  python train.py
  --training_data ${{inputs.training_data}}
  --test_data ${{outputs.test_data}}
  --model_output ${{outputs.model_output}}
  --test_split_ratio ${{inputs.test_split_ratio}}

Register: az ml component create --file train.yml. SDK v2: load_component(path=...) then ml_client.components.create_or_update. Studio lists versions under Assets > Components.

name is required, must start with a lowercase letter, and may contain lowercase letters, digits, and underscore, max 255 characters. display_name can be any Studio-friendly string and need not be unique. If you omit version, the service autogenerates one — production catalogs should still set versions explicitly (1.0.0 or a date).

environment is required. Reference a workspace environment with azureml:<name>:<version>, a curated environment with the azureml://registries/azureml/environment/... URI, or an inline environment object without name/version (unregistered). A missing environment version fails component create, not later at a mysterious import error.

is_deterministic defaults to true (reuse previous results when inputs match — “reuse by default”). Set it false when the step hits a live URL or an external store that can change under the same input values; otherwise pipelines will skip a step that looks unchanged and serve stale data.

Inputs, outputs, and the three-place edit

Literal inputs (string/number/integer/boolean) become runtime parameters (learning rate, epoch count). Object inputs render as connection dots on the pipeline graph and carry data or models between steps. Adding an input is three edits: YAML inputs, YAML command, and argparse (or equivalent) in source. Forgetting the third is how “I added epochs in YAML” still trains with the default.

Optional inputs (optional: true) must appear inside $[[...]] so the generated command can drop the flag. Example: $[[--max_epocs ${{inputs.max_epocs}}]]. Putting a required input in $[[]] or an optional one only in ${{}} is a schema error. Do not use \ for line breaks in command; use YAML >-. Reserved names you must not use for inputs/outputs include path, ld_library_path, user, logname, home, pwd, and shell.

distribution (MPI, PyTorch, TensorFlow) and resources.instance_count belong on components that wrap distributed training; Chapter 6 covers the job-level story. Know that the component YAML can carry those blocks so the step is reusable on multi-node clusters.

Pipeline jobs versus pipeline components

A pipeline job YAML (type: pipeline) lists child jobs, each of which can set type: command and component: ./train.yml or component: azureml:train_linear_regression_model:1. Data wiring uses ${{parent.jobs.step_a.outputs.cleaned}} and ${{parent.inputs.raw}}.

A pipeline component packages several child components into one reusable super-step (prep+train+eval as a single catalog item). Nested references in a registry must already be named assets in that registry — you cannot point a registry pipeline component at an anonymous local YAML or a workspace-only environment. Create the inner environment and command components in the registry first, then the outer pipeline component.

Supported child job types inside a pipeline (current v2) include command and sweep (hyperparameter search). Designer can drag registered components; AI-300 still expects you to read YAML.

Why components beat copy-pasted jobs

Copy-pasted az ml job create YAML looks faster on day one and fails MLOps on day thirty:

• Interface — without typed inputs/outputs, teams pass folders by tribal knowledge and break graphs when someone renames a path.
• Share and reuse — a registered component is discoverable in the workspace (and, in 3.4, in a registry across subscriptions). One team’s evaluation logic becomes another team’s standard step.
• Version control — producers publish train_linear_regression_model:2 with a bug fix; consumers stay on :1 until they opt in. Reproducibility survives “helpful” edits.
• Unit testing — a component is a bounded command you can run locally with sample folders before it ever touches a cluster.
• Reuse by default — deterministic steps skip when inputs are unchanged, saving cluster hours — the north-star cousin of “don’t recompute gold features.”

Manage with az ml component list/show/update/archive/restore. update is limited (description, display_name), matching environments: behavior changes are new versions.

Exam scenario

Three product squads each copied train.py into their pipeline repos. Squad A added class-weight logic; squads B and C did not. A responsible-AI review found production models trained without those weights. The MLOps engineer extracts training into command component train_claims_classifier with inputs training_data (uri_folder), class_weight (string, enum), and output model_output (mlflow_model), registers version 1, and points every pipeline at azureml:train_claims_classifier:1. A later fairness fix ships as version 2; regulated pipelines stay on 1 until sign-off.

Common trap

Do not treat an unregistered component: ./train.yml path in a single pipeline file as a governed asset. It is convenient, but it is not versioned in the workspace catalog and cannot be shared to a registry until you az ml component create. Sibling traps: optional flags without $[[]]; is_deterministic: true on a step that downloads “today’s” blob from a stable URL; and reserved input names that collide with the container environment.