A water utility keeps training datasets in an Azure Blob container and wants Azure Machine Learning jobs to read that data in place. What should the MLOps engineer register?

Registering a datastore in the Azure ML workspace that points jobs at the municipal Blob container is correct because datastores are the governed linkage between training/scoring jobs and existing cloud storage. The water utility already keeps training datasets in Blob; a datastore lets Azure ML resolve paths with workspace authentication (keys, SAS, or preferably identity-based access) so jobs read data in place instead of inventing a second ungoverned copy. That preserves one source of truth for meter and quality history while enabling reproducible job configuration.

An Azure ML data asset in the workspace that defines jobs against workspace Blob storage fails because it versions data for consumption against workspace default storage rather than registering the existing municipal container, so jobs still lack the governed in-place path to the utility's datasets and the datastore linkage is skipped. A managed identity credential in the Azure ML workspace that authorizes jobs for Blob reads fails because identity is only authentication and does not register a storage location; without a datastore pointing at the municipal Blob container, jobs have no reusable, centrally managed path to read that container in place. An Azure ML compute cluster in the workspace that caches the municipal Blob container fails because a compute cluster is execution infrastructure, not a registered data reference; caching copies data to compute rather than providing the governed, authenticated datastore path jobs need for in-place reads.

Exam caveat: a datastore references storage; a data asset versions a specific path or dataset for jobs to pin. When the stem asks how jobs should read an existing Blob container in place, the datastore is the registration step; mistaking it for provisioning a compute cluster to cache data or for saving a managed identity credential alone misses the required storage registration.

Operational check: after registration, run a small job that lists or reads a known Blob path through the datastore, confirm authentication uses the intended identity after any key rotation, and ensure the container remains private with no anonymous access.