Mlops Infrastructure practice questions

SAS Token

Why it fails: SAS tokens are used for storage access, not for managing Kubernetes compute clusters.

Managed Identity

Why it fails: While supported in some contexts, a Service Principal is the explicit requirement for attaching external compute targets.

Azure Active Directory B2C

Why it fails: B2C is for consumer-facing identity, not infrastructure service management.

Use a smaller Docker container

Why it fails: Container size does not impact the underlying VM disk allocation.

Increase the OS disk size of the VM

Why it fails: This is generally not configurable by the end-user in the ML training job context.

Change the experiment name

Why it fails: Experiment names do not affect disk capacity.

Data labeling

Why it fails: Labeling is for data preparation, not model approval.

Compute targets

Why it fails: Compute targets are for execution, not approval workflows.

Auto-scaling

Why it fails: Auto-scaling is for infrastructure load, not model governance.

Shared Key

Why it fails: Shared Key grants full account-level access via a static credential, so a leaked key compromises every container and table; it cannot be scoped or audited per identity. It is tempting because it is the default connection method for quick scripts, and would suit a throwaway demo account where no Microsoft Entra ID credential exists.

Public Access

Why it fails: Public access exposes the storage account to anonymous internet traffic, bypassing workspace identity and network controls entirely. It is tempting because it removes private-endpoint configuration effort, but the secure method is a managed private endpoint or workspace managed identity with RBAC.

Account SAS

Why it fails: An account SAS is still a bearer secret signed with the account key, so it grants access to any resource in the storage account and cannot be tied to a workspace identity or revoked per user. It suits time-limited external sharing where the caller has no Microsoft Entra ID principal.

JSON

Why it fails: Azure ML CLI v2 deployment configuration is defined in YAML, not JSON, so a JSON file will not be parsed as a valid deployment specification. JSON is tempting because it is a common configuration format elsewhere in Azure tooling, but the CLI v2 schema expects YAML keys such as $schema and type.

XML

Why it fails: XML is a general-purpose markup language with no schema support in the Azure ML CLI v2, which expects YAML for deployment configuration files. XML is tempting because it is widely used for configuration in .NET and Java ecosystems, and would be correct for those frameworks' config files, but not here.

Bicep

Why it fails: Bicep provisions Azure infrastructure declaratively, but Azure ML CLI v2 deployment configuration is defined in YAML, which the CLI parses directly. Bicep is tempting because it is Microsoft's standard for infrastructure as code, and would be correct for deploying the underlying workspace, compute and networking resources rather than the model deployment spec.

Increase the idle time for the compute cluster

Why it fails: Idle time controls how long a node stays provisioned after a job finishes, so it cannot reduce peak GPU memory consumption during training. Increasing it merely keeps the cluster running and billing longer. Idle time would be relevant when jobs queue waiting for nodes to deallocate, not when memory is exhausted mid-run.

Enable auto-scale to zero

Why it fails: Auto-scale to zero deallocates nodes when idle, reducing cost, but it does not increase per-node GPU memory during training. The job still exhausts the same VRAM. Scaling to zero suits intermittent workloads where clusters sit unused; it cannot address a memory ceiling hit while a job is actively running.

Update the workspace storage account

Why it fails: The workspace storage account holds artefacts, logs and datasets; it has no bearing on GPU memory allocated to a training process. Changing it cannot resolve an out-of-memory failure. Storage configuration matters when dealing with dataset access latency or quota limits, not when the compute node itself runs out of VRAM.

Visual Studio Code extension

Why it fails: The Visual Studio Code extension provides editor-side authoring and debugging of pipelines; it contributes no build or release tasks to Azure DevOps itself. It would be the correct pick for writing YAML locally, but the pipeline needs an installed extension supplying Azure ML task steps.

Terraform extension

Why it fails: Terraform provisions infrastructure declaratively through the Terraform CLI and state files, exposing no Azure ML pipeline tasks to Azure DevOps. It is correct when pipelines must create or update cloud resources, not when build and release stages must trigger Azure ML jobs.

Kubernetes extension

Why it fails: The Kubernetes extension deploys and manages container workloads on Kubernetes clusters; it exposes no Azure ML pipeline or model tasks to Azure DevOps. It is the right choice when a release pipeline must orchestrate containerised applications, not when Azure ML jobs need invoking from build or release stages.

Azure Bastion

Why it fails: Azure Bastion provides RDP and SSH access to virtual machines through the portal, without exposing those VMs publicly. It is tempting because it removes public IPs from hosts, but it secures administrative VM sessions, not the Azure Machine Learning workspace, which needs a private endpoint.

Application Gateway

Why it fails: Application Gateway is a layer-7 HTTP load balancer and web application firewall, not a workspace isolation control. It is tempting because it filters inbound web traffic, but that suits publishing web apps; private connectivity for Azure Machine Learning requires a private endpoint with a private link.

Service Tags

Why it fails: Service Tags are named IP address ranges for use in network security group and firewall rules; they do not create private connectivity. They are tempting because they restrict traffic to Azure services, but that still traverses public endpoints, whereas workspace isolation requires a private endpoint.

Azure Event Grid

Why it fails: Azure Event Grid routes discrete event notifications between services; it does not collect model inference metrics or logs. It is tempting because Azure ML publishes events such as model registration and drift alerts, which suits reactive event-driven automation, but continuous metric aggregation comes from Azure ML's own monitoring integration.

Azure Policy

Why it fails: Azure Policy evaluates and audits resource compliance against governance rules; it does not collect model telemetry. Azure ML integrates with Azure Monitor and Application Insights for automated metrics, logging and data drift signals. Policy is tempting because it also targets Azure resources, but its scope is configuration compliance, not runtime model health.

Azure Data Factory

Why it fails: Azure Data Factory orchestrates data movement and transformation pipelines; it emits no model telemetry into Azure ML. It is tempting because it schedules and triggers workflows, which suits ETL orchestration, but Azure ML's built-in monitoring already captures inference metrics and logs without a separate pipeline service.

Compute Target

Why it fails: A compute target supplies the CPU or GPU nodes that execute a step, not the Python packages or Conda dependencies loaded onto them. It is tempting because compute is mandatory in every pipeline, and specifying an AmlCompute cluster is correct when the question asks where a step runs rather than what environment it runs in.

Datastore

Why it fails: A datastore defines where pipeline data is read from and written to, such as an Azure Blob or file share connection, so it holds no package or Conda specification. It is tempting because data location is a required pipeline input, and a datastore is the correct choice when the question asks where intermediate outputs are persisted.

Component

Why it fails: A component packages a step's code, inputs and outputs, but its environment is referenced separately through an Environment object or inline conda YAML. It is tempting because components are the reusable building blocks of a pipeline, and a component is correct when the question asks how to encapsulate a script and its port bindings.

Experiment tracking

Why it fails: Experiment tracking logs metrics, parameters and artefacts from runs; it does not provide the connection abstraction to underlying storage. It is tempting because tracking is central to Azure ML workflows, and the experiment tracking facility would be correct when the requirement is comparing run metrics or recording outputs across training iterations.

Model registry

Why it fails: A model registry stores and versions trained models; it does not abstract connection details for storage services. It is tempting because registering models is part of the ML lifecycle, and the registry would be the correct component when the requirement is tracking model versions and deploying them to endpoints.

Compute resource management

Why it fails: Compute resource management provisions clusters and targets for training or inference; it does not hold connection information for data sources. It is tempting because compute is configured alongside data access in Azure ML, and a compute cluster would be correct when the requirement is specifying where training jobs or scoring services execute.

Azure Portal

Why it fails: The Azure Portal is a graphical interface for manual resource creation; it produces no version-controlled template defining the workspace. It is tempting because the portal is the standard starting point for exploring and provisioning services, and would be correct for one-off interactive setup rather than repeatable infrastructure as code.

PowerShell

Why it fails: PowerShell likewise executes imperative cmdlets and stores no declarative template describing the workspace configuration. It is tempting because PowerShell is a legitimate automation and administration tool for Azure resources, and would be correct for scripted operational tasks rather than defining infrastructure as code.

Azure CLI

Why it fails: Azure CLI issues imperative commands against existing resources; it does not declare a workspace's desired state as a template file. It is tempting because CLI scripting is genuinely useful for automating deployments, and would be correct for ad-hoc or pipeline-driven provisioning rather than infrastructure as code.

Network Security Group

Why it fails: NSGs control network traffic, not identity-based permissions.

Azure Storage Access Policies

Why it fails: Storage policies do not control compute resource creation.

Azure ML Datastore configuration

Why it fails: Datastores manage data connectivity, not compute administration permissions.

Environment variables in the Dockerfile

Why it fails: Dockerfile environment variables are baked into the image and visible to anyone with access, so they are not secret storage. They suit non-sensitive configuration such as paths or mode flags; secrets belong in Azure Key Vault, referenced via the workspace connection.

Local configuration files

Why it fails: Local configuration files sit on the compute instance's filesystem, so secrets are neither versioned centrally nor rotated, and they vanish when the cluster scales or reimages. They suit single-machine development, but Azure ML jobs need secrets injected at runtime from a managed store.

Hardcoding in the script

Why it fails: Hardcoding exposes secrets in plaintext within source control and build logs, so any reader of the script or repository obtains the API key directly. It is tempting as the quickest local hack for throwaway notebooks, yet the requirement explicitly forbids embedding secrets in the script.

Modify the storage account permissions

Why it fails: Storage account permissions govern blob access, not which image tag Azure ML resolves. It is tempting because ACR storage underpins the registry, but the correct workflow pushes an updated tag and references that tag or digest in the environment, prompting Azure ML to pull the new image.

Restart the compute cluster

Why it fails: Restarting the compute cluster reinitialises nodes but does not alter which image tag the environment resolves. It is tempting because restarts often clear stale state, yet the correct workflow pushes an updated tag to ACR and updates the Azure ML environment to reference that tag or digest.

Delete and recreate the workspace

Why it fails: Recreating the workspace destroys compute, datastores and job history without changing the image Azure ML pulls. It is tempting as a reset when environments misbehave, but the correct workflow pushes a new tag to ACR and updates the environment definition to reference it.

Provisioning timeout

Why it fails: Provisioning timeout bounds how long instance creation may run before failing; it does not monitor activity or stop a running instance. It is tempting because it is a lifecycle timing control, and would be correct when capping deployment duration so stalled provisioning attempts are abandoned automatically.

Auto-scaling

Why it fails: Auto-scaling adjusts the number of running instances in response to load; it never stops an individual instance after an idle period. It is tempting because it manages compute capacity automatically, and would be correct when matching fleet size to demand rather than halting one inactive instance.

Priority based scheduling

Why it fails: Priority-based scheduling determines queue order and preemption among jobs competing for compute resources; it does not detect inactivity or stop an instance. It is tempting because it governs when workloads run, and would be correct for prioritising critical training jobs over lower-priority ones in a shared cluster.

Static node count

Why it fails: A static node count fixes capacity, so the endpoint cannot add instances when traffic spikes and requests queue or fail. Static allocation suits steady, predictable workloads where provisioning cost must be capped; here the requirement is elastic response to sudden load, which static counts cannot provide.

Batch deployment

Why it fails: Batch deployment processes scoring jobs against stored data on a schedule; it exposes no real-time endpoint to receive spike traffic at all. It is tempting because it scales across large volumes cheaply, and would be correct for offline scoring of accumulated records rather than low-latency online inference.

Pre-warmed instances

Why it fails: Pre-warmed instances reduce cold-start latency by keeping allocated capacity ready, but the count stays fixed, so sudden spikes beyond that capacity still throttle. Pre-warming suits latency-sensitive steady traffic; the stem requires dynamic scale-out, which pre-warmed instances alone do not deliver.

None of the above

Why it fails: Dismissing all listed configurations ignores that autoscaling exists precisely for this requirement, so the endpoint would remain unable to absorb traffic spikes. It tempts when none of the offered options appear to match, yet here a valid scaling configuration is available and should be selected instead.

Environments

Why it fails: Environments capture the Python packages and Docker image needed to reproduce a run; they store no metrics or parameters. It is tempting because reproducibility underpins experiments, but comparing performance metrics across runs requires Azure Machine Learning job run history, not environment definitions.

Model Registry

Why it fails: The Model Registry stores and versions trained model artefacts for deployment; it does not record per-run metrics or parameters. It is tempting because it tracks models, but experiment tracking and metric comparison belong to Azure Machine Learning jobs and their run history, not the registry.

Compute targets

Why it fails: Compute targets provide the infrastructure that executes training or scoring jobs; they hold no experiment metrics or run history. It is tempting because experiments run on compute, but comparing performance metrics requires the run-tracking capability of Azure Machine Learning jobs, not the compute resource itself.

A storage account

Why it fails: A Component is a reusable, versioned pipeline step, not a storage account, so it cannot be defined as one. Storage accounts are tempting because Components reference code and data held in Azure storage, but the storage account is an external dependency, not the Component.

A user role

Why it fails: A Component is a reusable, versioned pipeline step, not a user role, so it cannot be defined as one. User roles are tempting because Components are shared and versioned within a workspace, but access to them is governed by Microsoft Entra ID role assignments, not by the Component definition.

A physical server

Why it fails: A Component is a reusable, versioned step in an Azure ML pipeline, not hardware, so a physical server cannot satisfy the definition. Physical servers are tempting because pipelines ultimately execute on compute, but that compute is a separate Azure ML resource, not the Component itself.

Delete the datastore

Why it fails: Deleting the datastore removes the registered data location that the failing job reads from, so it destroys the very input the container needs and cannot expose container-level errors. It is tempting because datastores are managed through the workspace and are used to fix broken data paths, but that is a data-management action, not a debugging one.

Use the Azure ML SDK to download the container image

Why it fails: Downloading the image via the Azure ML SDK retrieves the container's layers for local inspection, but the failure occurs at runtime inside the job, so static image contents reveal nothing about the actual error. This suits auditing or reproducing an environment, not diagnosing a live failing training run.

Submit a new training job without parameters

Why it fails: Omitting parameters discards the container configuration, image and entrypoint needed to reproduce the failure, so nothing is investigated. It tempts as a quick rerun, but debugging requires the same environment; the correct approach inspects logs or opens a shell inside the failing container.