Microsoft AI-300: Design and implement an MLOps infrastructure Practice Questions

After OIDC-based Azure login with 'azure/login', the ML CLI extension must be installed ('az extension add --name ml') before any 'az ml' commands can be executed on the runner. These two steps together enable all subsequent Azure ML CLI operations. Installing the Python SDK ('pip install azureml-sdk') is unnecessary when using the Azure CLI v2 approach; the SDK is for Python-based scripts. 'az ml job create' is a valid action step, but it is the training submission command, not a prerequisite step for interacting with AML — and the question asks for essential enabling steps. A self-hosted runner inside the managed VNet is only required when the workspace has public network access disabled; it is not universally essential for this scenario.

An Azure Machine Learning registry is the purpose-built feature for sharing assets such as models, components, environments, and datasets across multiple workspaces, even across different subscriptions. A shared blob storage datastore can share raw data files but cannot natively share versioned ML assets like components and environments with their metadata. A 'hub' workspace is a concept in Azure AI Foundry, not a native AML feature for cross-workspace asset sharing of this kind. Azure DevOps Artifacts is a package feed for code libraries (e.g., Python packages), not for Azure ML assets like registered components or environments.

Storage Blob Data Reader is correct because it grants read-only access to blob data, satisfying the principle of least privilege for a workspace that only needs to read data. Storage Blob Data Contributor is incorrect because it also grants write and delete permissions, which exceed the minimum required. Storage Account Contributor grants control-plane management rights over the storage account but does not grant data-plane blob access. Reader grants read access to Azure Resource Manager metadata only, not to the actual blob data content.

Three actions are required: (1) The workspace's system-assigned managed identity needs 'AcrPull' on the ACR so the workspace can build and pull the image during environment materialization. (2) The ACR must be linked/attached to the workspace so AML knows to use it for image operations. (3) If the workspace uses a managed VNet, an outbound private endpoint rule must permit traffic to the ACR; otherwise image pulls are blocked. Enabling the ACR admin user and using credential-based auth is a less secure pattern and is not the recommended approach when using managed identity. Assigning AcrPull to the compute cluster identity alone is insufficient because the workspace identity handles the environment build process. Rebuilding to use public images avoids the problem rather than solving it and is not an architectural fix.

To disable SSH access on an AmlCompute cluster via Bicep, the 'remoteLoginPortPublicAccess' property must be set to 'Disabled'. To deploy the cluster in a specific subnet, the 'subnet.id' property must be set to the full resource ID of the desired subnet. These are both documented properties of the AmlCompute compute configuration. Setting 'enableNodePublicIp' to 'false' (option D) controls whether cluster nodes get public IP addresses and is a separate (though related) network setting; it does not place the cluster in a subnet on its own. Setting 'sshKeyData' to an empty string (option E) does not disable SSH access — SSH is controlled by the 'remoteLoginPortPublicAccess' property. 'isolatedNetwork' (option A) is not a valid property in the AmlCompute Bicep specification; it is a fabricated field.