Free AI-300 Practice Test

Speed of recovery is the central requirement. Rolling back traffic to the previous deployment is the fastest possible action: because the previous deployment still exists on the same endpoint, you simply update the traffic weights --- setting the old deployment to 100% and the new deployment to 0% --- using a single Azure ML CLI command or SDK call that completes in seconds without reprovisioning any compute. Deleting and redeploying (option B) requires tearing down the endpoint, waiting for deprovisioning, recreating it, re- deploying the model, and waiting for containers to start --- potentially 10 to 30 minutes. Changing authentication type (option C) does not affect application errors caused by a bad model. Increasing compute size (option D) does not fix model logic errors. The entire reason Azure ML supports multiple concurrent deployments with traffic splitting is precisely to enable this instant rollback pattern. Microsoft Learn Reference Topic: Roll back deployments on managed online endpoints -- Azure Machine Learning safe deployment practices

For Azure Machine Learning SDK v2, Microsoft recommends MLflow Tracking for experiment logging. When a requirement specifically calls for logging a list of numerical metric values, the appropriate operation is log_batch(). Microsoft provides an explicit SDK v2 migration example in which a list of numeric values is converted into MLflow Metric objects and submitted through MlflowClient().log_batch(). Technically, the concrete Python implementation uses the tracking client: MlflowClient().log_batch(run_id, metrics=metrics) where metrics contains a sequence of Metric objects representing the numerical values. Microsoft likewise documents batch metric logging as preferable when multiple metrics or multiple values of the same metric need to be recorded efficiently. mlflow.log_metric() records an individual numeric metric value. It can be invoked repeatedly, but Microsoft specifically demonstrates log_batch() for a curve or list of numeric values. mlflow.log_artifact() stores files and other artifacts rather than numerical tracking metrics, while mlflow.log_image() is intended for images and therefore does not satisfy the requirement. Therefore, A is the intended answer. In actual Python SDK v2 code, this operation is normally invoked as MlflowClient().log_batch(). Study Guide Reference: Implement machine learning model lifecycle and operations --- Azure Machine Learning experiments, MLflow tracking, metric logging, experiment observability, and SDK v2 migration.

Azure Monitor is valuable for production observability, but it is not the appropriate mechanism for the stated development-time requirement: manually inspecting individual prompt-flow executions and comparing prompt variants with their inputs, outputs, token consumption, and latency. Prompt flow provides purpose-built run outputs and tracing. Microsoft documents that after a flow execution, the Outputs experience exposes detailed flow inputs and outputs. When tracing is enabled, the Trace view provides execution duration and token information and lets the developer expand individual steps to inspect their inputs and execution details. Prompt flow also directly supports variants and batch/evaluation runs. Multiple variants can be executed and compared, while the run details expose per-test-case inputs, outputs, token counts, duration, and evaluation results. Microsoft explicitly states that multiple runs can be selected to compare their metrics and outputs. Azure Monitor/Application Insights can collect operational metrics such as token consumption and flow or node latency for deployed applications, but that telemetry is primarily intended for monitoring and troubleshooting rather than the interactive prompt-variant evaluation workflow described here. Therefore, the proposed solution does not meet the goal. Study Guide Reference: Implement generative AI quality assurance and observability --- prompt evaluation, tracing, debugging, token consumption, latency, and prompt-variant comparison.

Azure Machine Learning's model registry supports three lifecycle states: Active (the default, fully usable state), Archived (not deployable but still accessible for review), and Deleted (permanently removed). Archiving is precisely designed for this scenario: it ensures that operations teams cannot accidentally select the old version for a new deployment, while compliance officers can still inspect it, compare its metrics to newer versions, and reactivate it quickly if a rollback is needed. Deleting (option B) would permanently remove the version, making compliance review and rollback impossible and violating both requirements. Unregistering (option D) is not a standard Azure ML operation; deletion is the removal action. Archiving the training dataset (option A) is unrelated to the model version's deployability. Archiving creates a soft-block on deployment while preserving the full artifact history. Microsoft Learn Reference Topic: Manage model versions in the Azure Machine Learning registry -- Archive and lifecycle management

During experimentation, a data science team produces trained model artifacts they want to share with the MLOps team for deployment, with the governance team for compliance, and with the QA team for testing. Registering the model in the Azure ML model registry gives each of these teams access to the versioned, immutable artifact through a single reference. Option B (Component) packages a reusable pipeline step, not the model output itself. Option C (Environment) captures the Python runtime, not the trained artifact. Option D (Pipeline) defines the orchestration workflow, not the resulting model. In Azure ML, the model registry is the governance store for trained model artifacts, recording who created it, when, from what data and code, and which metrics it achieved --- making it the asset to register for reuse and governance across projects. Microsoft Learn Reference Topic: Register and manage models in Azure Machine Learning -- Model registry