ExamFinch.com My Study

Study guide

3.3 Create and Manage Components

Practice this exam

Microsoft AI-300: Operationalizing Machine Learning and Generative AI Solutions Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Skills Measured, Format, and How This Guide Is Organized 1.3 Candidate Profile, Azure ML v2, Foundry, and DevOps Tooling

2 Chapter 2: Azure Machine Learning Workspaces, Datastores, Compute, and IAM

2.1 Create and Manage Azure Machine Learning Workspaces 2.2 Create and Manage Datastores 2.3 Create and Manage Compute Targets 2.4 Configure Identity and Access Management for Workspaces

3 Chapter 3: Azure Machine Learning Data Assets, Environments, Components, and Registries

3.1 Create and Manage Data Assets 3.2 Create and Manage Environments 3.3 Create and Manage Components 3.4 Share Assets Across Workspaces with Registries

4 Chapter 4: Infrastructure as Code, GitHub, and Network Isolation for Azure ML

4.1 GitHub Integration and Git Source Control for Machine Learning Projects 4.2 Deploy Workspaces and Resources with Bicep and Azure CLI 4.3 Automate Resource Provisioning with GitHub Actions 4.4 Restrict Network Access to Machine Learning Workspaces

5 Chapter 5: MLflow Tracking, AutoML, Training Jobs, and Hyperparameter Sweeps

5.1 Configure Experiment Tracking with MLflow 5.2 Use Automated Machine Learning to Explore Optimal Models 5.3 Notebooks, Command Jobs, and Training Scripts 5.4 Automate Hyperparameter Tuning

6 Chapter 6: Distributed Training, Training Pipelines, and Job Comparison

6.1 Manage Distributed Training for Large and Deep Learning Models 6.2 Implement Training Pipelines 6.3 Compare Model Performance Across Jobs

7 Chapter 7: Model Registration, Responsible AI, and Lifecycle Management

7.1 Register MLflow Models and Package Feature Retrieval Specs 7.2 Evaluate Models with Responsible AI Principles 7.3 Manage Model Lifecycle and Archiving

8 Chapter 8: Online Endpoints, Batch Endpoints, Rollout, and Rollback

8.1 Deploy Models to Managed Online Endpoints 8.2 Deploy Models to Batch Endpoints 8.3 Test, Troubleshoot, Progressive Rollout, and Safe Rollback

9 Chapter 9: Data Drift, Production Metrics, Retraining, and Alerts

9.1 Detect and Analyze Data Drift 9.2 Monitor Production Metrics and Trigger Retraining or Alerts

10 Chapter 10: Microsoft Foundry Resources, IAM, Networking, and IaC

10.1 Create and Configure Foundry Resources and Project Environments 10.2 Managed Identities and RBAC for Foundry 10.3 Foundry Network Security and Private Networking 10.4 Deploy Foundry Infrastructure with Bicep and Azure CLI

11 Chapter 11: Deploying and Managing Foundation Models

11.1 Serverless API Endpoints and Managed Compute for Foundation Models 11.2 Select Foundation Models for Specific Use Cases 11.3 Model Versioning and Production Deployment Strategies 11.4 Provisioned Throughput Units for High-Volume Workloads

12 Chapter 12: Prompt Design, Variants, and Git Version Control

12.1 Design and Develop Prompts 12.2 Create Prompt Variants and Compare Performance 12.3 Version Control for Prompts with Git

13 Chapter 13: Evaluation Datasets, Quality Metrics, Safety, and Automated Workflows

13.1 Test Datasets and Data Mapping for Evaluation 13.2 Groundedness, Relevance, Coherence, and Fluency 13.3 Risk and Safety Evaluations 13.4 Built-in and Custom Automated Evaluation Workflows

14 Chapter 14: Continuous Monitoring, Performance, Cost, Tracing, and Logging

14.1 Continuous Monitoring in Microsoft Foundry 14.2 Latency, Throughput, Token Use, and Cost Metrics 14.3 Logging, Distributed Tracing, and Production Debugging

15 Chapter 15: Retrieval Tuning, Embeddings, Hybrid Search, and RAG Evaluation

15.1 Tune Similarity Thresholds, Chunk Sizes, and Retrieval Strategies 15.2 Select and Fine-Tune Embedding Models 15.3 Hybrid Search: Semantic and Keyword Retrieval 15.4 RAG Relevance Metrics and A/B Testing

16 Chapter 16: Fine-Tuning Methods, Synthetic Data, and Promotion to Production

16.1 Advanced Fine-Tuning Methods (LoRA, QLoRA, Full) 16.2 Create and Manage Synthetic Data for Fine-Tuning 16.3 Monitor, Optimize, and Promote Fine-Tuned Models

3.3 Create and Manage Components

Key Takeaways Explain This Topic AI

A component is a versioned, self-contained pipeline step with metadata, a typed input/output interface, and a body (command + code + environment). It is analogous to a function and is the building block of Azure Machine Learning pipelines.

A command component YAML requires name (lowercase, digits, underscore, max 255), type: command, command, and environment. Typical additional keys are code, inputs, outputs, version, display_name, and is_deterministic.

Typed inputs include number, integer, boolean, string, uri_file, uri_folder, mltable, and mlflow_model. Outputs are uri_file, uri_folder, mltable, or mlflow_model. Reference them in command as ${{inputs.x}} and ${{outputs.y}}; wrap optional inputs in $[[...]].

Register with az ml component create -f train.yml so pipelines can call azureml:<component>:<version> or azureml:<component>@latest instead of copy-pasting job YAML. Only description and display_name update in place; logic changes get a new version.

Pipeline components nest other named components. In a registry, nested component and environment references must already exist as named assets in that registry. Components beat one-off command jobs because they are shareable, unit-testable, and version-pinned across workspaces.

Last updated: August 2026

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:

Metadata — name , display_name , version , type , description , tags .

Interface — named inputs and outputs with types, defaults, min / max , enum , optional .

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

  • Direction Allowed types How the command refers to them
  • Input number , integer , boolean , string , uri_file , uri_folder , mltable , mlflow_model ${{inputs.<name>}}
  • Output uri_file , uri_folder , mltable , mlflow_model ${{outputs.<name>}}

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.