A city fraud-detection effort needs the same feature-engineering logic reused across several Azure Machine Learning pipelines. What asset type should they publish?

Publishing a reusable Azure ML pipeline component that encapsulates the municipal feature-engineering step is correct because shared logic across several fraud-detection pipelines should be versioned, typed, and composable. Components package inputs, outputs, and code so city teams reuse one featurizer definition instead of treating a reusable environment that holds pipeline dependencies as the reusable step. That improves consistency of fraud features across departments and simplifies testing when the engineering logic changes.

A reusable Azure ML environment that holds the municipal feature-engineering pipeline dependencies fails maintainability for shared logic: it holds dependencies but leaves the featurizer code uncaptured, so copies drift and bugs must be fixed in many places. A reusable Azure ML dataset that caches the municipal feature-engineering pipeline output prevents composition and creates incompatible feature contracts: it caches pipeline output but exposes no versioned, typed featurizer step for pipelines to call. A reusable Azure ML online endpoint that hosts the municipal feature-engineering pipeline code fails for pipeline reuse: it hosts code for real-time serving but cannot run inside Azure ML pipelines as a reusable featurizer step.

Exam caveat: components are the reusable building blocks of Azure ML pipelines; environments, datasets, and online endpoints are not reusable pipeline steps. When stems ask what to publish for reuse across pipelines, choose a component—not an environment, dataset, or endpoint.

Operational check: package the fraud feature-engineering step as a component with explicit typed inputs/outputs, register a version, reference it from at least two pipelines, and confirm both produce compatible feature schemas for downstream model steps.