Free Practice Questions for the Microsoft Certified: Machine Learning Operations (MLOps) Engineer AI-300 Exam (2026 Updated)

Chunk size and overlap directly affect the precision and completeness of information retrieved in a RAG architecture. Microsoft identifies effective chunking as a critical part of successful RAG implementation. If chunks are too large, they can contain excessive unrelated information, reducing retrieval precision because the vector representation covers multiple concepts. Conversely, chunks that are too small can omit necessary surrounding context or separate related information across chunk boundaries, resulting in incomplete retrieval.

Overlap helps preserve semantic continuity between adjacent chunks. Microsoft recommends using overlap particularly with fixed-size chunking because relevant facts or concepts can span chunk boundaries. The optimal chunk size and overlap should therefore be evaluated against representative documents and queries rather than treated as fixed constants. Microsoft specifically notes that larger chunks can preserve contextual richness, while appropriately configured overlap prevents contextual information from being lost at segmentation boundaries.

Temperature controls generation variability , not document retrieval. Token limits constrain how much content a model processes but do not inherently make retrieval more relevant. Embedding strategy can also influence retrieval quality, but given the stated symptom of irrelevant or incomplete retrieved passages , tuning chunk size and overlap is the directly targeted remediation.

Study Guide Reference: Optimize generative AI systems and model performance — RAG optimization, document chunking, retrieval precision, contextual completeness, and grounding.

===============

In Azure ML command jobs, MLflow automatically creates a run context, so explicit start_run is optional. The training script must call mlflow.log_param to record each hyperparameter for the run. If the script calls this for each hyperparameter, the requirement for capturing parameters per run is met. The script must also call mlflow.log_metric to record numeric metrics such as accuracy or loss, optionally indexed by training step. Metrics and parameters logged inside an Azure ML command job are automatically associated with the correct experiment and run — no manual specification of experiment or run ID is required. If all three elements (run context, parameter logging, metric logging) are present in the script, all experiment tracking statements are True. If any element is absent, the corresponding statement is False and the tracking requirement is not met.

Microsoft Learn Reference Topic: Log metrics, parameters, and artifacts during Azure Machine Learning training runs with MLflow

For deployment failures when containers do not start, review deployment logs in Azure ML Studio or use the CLI get-logs command to surface dependency installation errors, missing files, or scoring script import failures. For authentication errors such as 401 or 403 responses, check that client applications are using valid authentication keys or bearer tokens, as mismatched or expired credentials cause auth failures. For performance degradation and slow responses, review compute instance scaling configuration, since a surge in traffic saturates a fixed number of replicas causing queuing and high latency without autoscaling. For internal server errors such as HTTP 500, these typically originate in the scoring script, so inspect the init and run functions for unhandled exceptions and verify the environment has all required packages installed.

Microsoft Learn Reference Topic: Troubleshoot online endpoint deployment failures – Azure Machine Learning

Domain specialization: Supervised fine-tuning

Poor response accuracy of a RAG-based solution: Apply prompt engineering

For domain specialization , Supervised Fine-Tuning (SFT) is the correct first strategy. Microsoft describes SFT as the foundational fine-tuning technique for training a model from labeled input-output pairs , and specifically identifies domain specialization as one of its principal use cases. Microsoft also recommends starting with SFT for most customization projects because it supports task specialization, instruction following, style, and domain-specific behavior. Fabrikam already possesses evaluation data containing input-output pairs, which aligns directly with the SFT data model.

For poor RAG response accuracy , the first action is prompt engineering . The case explicitly requires advanced fine-tuning only when prompt engineering is insufficient. In a RAG system, prompt engineering determines how the model interprets retrieved context, constrains answers to grounding information, handles missing evidence, and formats responses. Microsoft notes that inadequate RAG prompting can produce false or incomplete answers even when retrieval returns appropriate content.

DPO is primarily appropriate for alignment using preferred versus non-preferred responses, while RFT targets complex reward-based reasoning optimization. Neither is the initial technique for domain specialization in this requirement.

Study Guide Reference: Optimize generative AI systems and model performance — prompt engineering, RAG optimization, supervised fine-tuning, preference optimization, and model customization strategy.

Imagine a hospital analytics firm with data scientists who kick off dozens of training jobs throughout the week. During peak hours, five jobs compete for the same GPU cluster and fail or queue for hours. On quiet nights, that cluster sits completely idle, burning money. Managed compute targets with autoscaling solve both problems: the cluster scales out automatically when multiple jobs arrive simultaneously and scales back to zero when idle. Option A (single shared cluster) is exactly the resource-contention problem Fabrikam already has. Option B (fixed-size cluster) wastes money during off-peak hours. Option C (dedicated per-experiment clusters) eliminates contention but is prohibitively expensive for a cost-conscious healthcare firm. Autoscaling managed compute is the cloud-native answer to variable workload demand.

Microsoft Learn Reference Topic: Azure Machine Learning compute targets – Configure autoscale for compute clusters

In Azure Machine Learning, a workspace is the top-level resource that acts as a centralized hub for every ML activity. It stores experiments, pipelines, datasets, models, environments, and compute targets all in one place. Before you can register assets or deploy endpoints, the workspace itself must exist and be shared across the team. Fabrikam ' s core challenge is inconsistent experiment tracking, ad-hoc versioning, and no standardized deployment path — all symptoms of the absence of a single, governed workspace. Option A (registering assets) is a subsequent action only possible after the workspace exists. Option C (online endpoint) is a deployment concern, not an asset-management foundation. Option D (Foundry project) is appropriate for generative AI workloads, not for the traditional ML pipeline standardization described here. The workspace is the prerequisite that makes every other governance action possible.

Microsoft Learn Reference Topic: Azure Machine Learning workspaces – Microsoft Learn: Manage Azure Machine Learning workspaces

Interactive experimentation: Azure Machine Learning compute instance

Scalable training jobs: Azure Machine Learning compute cluster

For interactive experimentation , use an Azure Machine Learning compute instance . Microsoft defines a compute instance as a fully managed, cloud-based development workstation optimized for machine learning development. It integrates directly with Jupyter, JupyterLab, and other development tools in Azure Machine Learning studio, making it the appropriate target for notebook-driven experimentation, iterative coding, debugging, and development. A compute instance is a single-node environment and can be stopped or configured with idle shutdown to control costs.

For scalable training jobs , use an Azure Machine Learning compute cluster . Compute clusters are managed training targets that can scale from a minimum to a configured maximum number of nodes based on job demand. Microsoft specifically recommends them for larger datasets, distributed training, and workloads requiring elastic compute capacity. Setting the minimum node count to 0 allows the cluster to deallocate all worker nodes when no jobs are running, which is an important cost-optimization mechanism.

Azure Batch, Databricks, AKS, and standalone Azure VMs can support specialized workloads, but they do not match the native Azure Machine Learning development-versus-elastic-training pattern as directly as compute instance and compute cluster.

Study Guide Reference: Design and implement an MLOps infrastructure — Azure Machine Learning compute targets, compute instances, compute clusters, autoscaling, distributed training, and cost optimization.

Technique: Grid search

Constraint: Demographic parity

The appropriate mitigation technique is GridSearch with a DemographicParity constraint. Fairlearn provides reduction-based mitigation algorithms that retrain a standard estimator using differently weighted training data while enforcing a specified fairness constraint. GridSearch is one of Fairlearn ' s reduction algorithms for binary classification and can search across candidate models representing different trade-offs between predictive performance and fairness.

The appropriate constraint is Demographic parity because the model determines whether individuals receive an opportunity—in this case, selection and admission to a medical trial . Microsoft categorizes decisions that extend or withhold opportunities or resources as allocation harms and specifically identifies demographic parity as a parity constraint intended to mitigate allocation disparities in binary classification.

Demographic parity seeks comparable rates of positive predictions across groups defined by the sensitive attribute. Here, Ethnicity is the sensitive feature, so the objective is to reduce disparities in selection rates between ethnic groups.

False-positive-rate parity has a different purpose: it specifically requires comparable false-positive rates across groups among cases whose true label is negative. The scenario does not identify unequal false-positive rates as the problem.

Managed Identity is Azure ' s solution for eliminating stored secrets and API keys from application configurations. When a Microsoft Foundry resource or its dependent compute has a system-assigned or user-assigned managed identity, it can authenticate to Azure services such as Storage, Key Vault, and Cognitive Services using Azure Entra ID tokens that are automatically issued and rotated by Azure. There are no keys to store, rotate, or accidentally expose in code or configuration files, directly satisfying the requirement to authenticate without stored credentials. Role-Based Access Control (RBAC) is the Azure governance mechanism for scoping permissions. By assigning specific built-in roles to the managed identity or to user and group principals at the correct scope — subscription, resource group, resource, or project level — the organization can enforce least-privilege access across different projects and shared resources.

Microsoft Learn Reference Topic: Configure managed identities and RBAC for Microsoft Azure AI Foundry resources

The Evaluation experience in Microsoft Foundry ' s prompt flow editor shows aggregate quality scores across prompt variants — which variant produces more coherent answers, which scores higher on groundedness. However, it does not expose per-run raw telemetry: individual token counts per call, per-request latency in milliseconds, or the exact input-output pairs for each execution. The Evaluation experience is designed for comparative quality scoring, not for detailed operational telemetry. To capture inputs, outputs, token usage, and latencies at the granular run level, Tracing must be enabled in Microsoft Foundry. Tracing records each LLM call as a structured span with timing, token consumption, and the complete input-output payload — a fundamentally different view than evaluation scores that directly satisfies all four capture requirements.

Microsoft Learn Reference Topic: Trace and debug prompt flows in Microsoft Foundry – Tracing vs. Evaluation

Detect when the system is slow at returning output: Latency

Identify when the system cannot sustain expected request volume: Throughput

Measure the duration of handling a request: Response time

Latency measures delay experienced while waiting for model output and is therefore the appropriate metric for identifying degradation in perceived responsiveness. Microsoft describes latency as the time required to obtain a response from the model and exposes metrics such as Time to Response/Time to First Token and Time Between Tokens for generative AI workloads. An increase indicates that users are waiting longer for output to begin or continue.

Throughput represents the amount of workload the system can process over a unit of time. Microsoft describes system-level throughput in terms such as requests per minute and tokens per minute. Consequently, throughput is the correct metric when determining whether a deployment can sustain the required request volume as demand increases.

Response time represents the overall duration required to handle an individual request. It is appropriate for measuring end-to-end request processing and validating request-duration SLOs. Microsoft specifically includes latency, throughput, and response times among the performance metrics candidates are expected to monitor for generative AI applications.

Concurrency measures simultaneous active requests and can influence capacity and latency, but none of these requirements directly asks for simultaneous-request count.

Study Guide Reference: Implement generative AI quality assurance and observability — continuous monitoring, latency, throughput, response times, production troubleshooting, and SLO monitoring.

MLflow is the industry-standard open-source platform for experiment tracking, and Azure Machine Learning has first-class native integration with it. When you use MLflow within an Azure ML job, parameters, metrics, and artifacts are automatically logged to the run history of the AML workspace, making every run reproducible and comparable. Option A (AML job output logs) only captures console output and lacks structured parameter and metric logging. Option C (Application Insights logs) is designed for application-level telemetry, not ML experiment metadata. Option D (Azure Monitor alerts) is a reactive notification tool, not a tracking system. MLflow ' s autologging capability means that for common frameworks such as scikit-learn, XGBoost, and PyTorch, parameters and metrics are captured without a single line of custom code, directly answering Fabrikam ' s requirement for consistent experiment tracking.

Microsoft Learn Reference Topic: Track ML experiments with MLflow – Azure Machine Learning MLflow integration

Managed online endpoints with traffic splitting are the best fit because Azure Machine Learning supports multiple deployments behind a single online endpoint and allows production traffic to be distributed between them. This enables a blue-green or progressive rollout strategy : deploy the new model version alongside the current version, validate it independently, send a small percentage of production traffic to it, monitor behavior, and then gradually increase traffic. If problems occur, traffic can be redirected immediately to the previous deployment, providing a practical rollback mechanism.

This approach also aligns with Fabrikam’s requirement to favor managed services and automation because the team has limited Azure DevOps experience. Managed online endpoints handle much of the serving, scaling, security, and monitoring infrastructure automatically and support both traffic splitting and mirrored traffic for safer validation.

Option B can also implement blue-green deployment, but AKS introduces substantially more infrastructure and operational management than Fabrikam requires. Option A would require custom deployment, routing, scaling, and rollback logic. Option D is intended for asynchronous batch inference rather than staged real-time production serving.

Study Guide Reference: Implement machine learning model lifecycle and operations — managed online endpoints, multiple deployments, traffic splitting, blue-green deployment, staged rollout, monitoring, and rollback.

The first action should be to evaluate the model output . Fabrikam already has evaluation data containing manually defined expected responses, and the technical requirements explicitly state that the organization must use its existing evaluation datasets based on real data with input-output pairs . Microsoft Foundry supports evaluating a model against an existing curated dataset to establish measurable baseline performance before optimization. Evaluation results can identify weaknesses in accuracy, relevance, groundedness, safety, or other quality dimensions and provide objective evidence for subsequent changes.

This sequencing is critical because Fabrikam also requires that advanced fine-tuning be applied only when prompt engineering is insufficient . Therefore, immediately fine-tuning the model would bypass the required baseline evaluation and optimization process. Fine-tuning should be driven by demonstrated performance gaps, not applied automatically.

Deploying directly to production is also inappropriate because leadership requires low operational risk and gradual rollout. Production traffic should not be used as the first evaluation mechanism when curated evaluation data already exists. Synthetic interaction data is useful when evaluation coverage is insufficient, but Microsoft specifically positions synthetic generation as an option when an adequate test dataset is unavailable. Fabrikam already has suitable evaluation data.

Study Guide Reference: Optimize generative AI systems and model performance — evaluate model performance, benchmark against curated datasets, iterate on prompts, and apply advanced fine-tuning when justified.

Microsoft ' s guidance on production model monitoring prescribes a four-stage sequence. First, configure an Azure ML model monitor on the deployed endpoint, specifying which metrics to track and on what schedule. Second, define the threshold value below which model performance is considered unacceptable — this becomes the trigger condition. Third, create an Azure Monitor alert rule that evaluates the monitored metric against the threshold and fires when it is breached; the alert rule is associated with an action group that sends notifications to stakeholders via email, SMS, or Teams webhook. Fourth, the action group includes a webhook action pointing to an Azure Machine Learning pipeline ' s published REST endpoint, which starts the retraining job automatically. This sequence cleanly separates detection, notification, and remediation, matching Microsoft ' s recommended MLOps automation pattern.

Microsoft Learn Reference Topic: Automate model retraining based on monitoring alerts – Azure Machine Learning MLOps

UTF-8 is the universal encoding standard: it is backward-compatible with ASCII for standard Latin characters, supports every Unicode code point covering over 140,000 characters, and is the de facto standard for all modern APIs including Azure OpenAI. This matters for fine-tuning because training data often contains diverse characters from multiple languages, special punctuation, and domain-specific symbols. If they use ASCII encoding, any accented character or non-Latin script will be corrupted or lost entirely. UTF-16 adds a Byte Order Mark and can cause parsing issues with tools that expect standard JSONL. ISO-8859-1 covers Western European characters only and fails immediately with CJK or Arabic scripts. The Azure OpenAI fine-tuning documentation explicitly states that training files must be UTF-8 encoded, making it the only safe choice.

Microsoft Learn Reference Topic: Azure OpenAI fine-tuning – File format and encoding requirements

A system requesting predictions synchronously during customer interactions needs sub-second responses, while a system submitting files with millions of records can tolerate minutes of processing time. For real-time synchronous serving, a Managed Online Endpoint provisions a persistent always-on container behind an HTTPS REST endpoint that returns predictions within milliseconds. For large-batch asynchronous scoring, a Batch Endpoint accepts a data asset input, distributes scoring across a compute cluster, and writes results back to storage. Online endpoints support auto-scaling based on request volume and traffic splitting. Batch endpoints are invoked on-demand or on a schedule, automatically provisioning and de-provisioning compute, keeping costs low for intermittent large jobs. Each deployment type is purpose-built for its usage pattern and should not be swapped.

Microsoft Learn Reference Topic: Deploy and score models with managed online endpoints and batch endpoints – Azure Machine Learning

Groundedness and Relevance directly measure the two quality characteristics specified in the requirement.

Groundedness evaluates whether the generated response is supported by the supplied knowledge context rather than introducing unsupported or fabricated information. Microsoft Foundry defines the Groundedness evaluator as measuring how well a generated response aligns with the provided context without fabricating content. For an assistant that relies on internal knowledge sources, this is the primary metric for determining whether its claims are traceable to retrieved evidence.

Relevance evaluates whether the generated response actually addresses the user ' s query. Microsoft defines the Relevance evaluator as measuring how relevant the response is to the query, including whether it appropriately and accurately responds to the user ' s request. This detects responses that may be factually grounded yet tangential or insufficiently focused.

Harmfulness and Fairness are safety-oriented dimensions rather than measures of factual support or query alignment. Tone assesses communication characteristics but does not establish whether a response is supported by source material or relevant to the prompt.

Therefore, the required pair is Groundedness + Relevance .

Study Guide Reference: Implement generative AI quality assurance and observability — Foundry quality evaluators, groundedness, relevance, RAG evaluation, and pre-production validation.

A Git repository provides all three capabilities required: version history for every change with author attribution and timestamp, branching for experimentation, tagging for stable releases, and a single source of truth accessible to all projects via clone or submodule reference. Azure ML datasets (option B) are designed for training data, not text configuration artifacts, and lack per-line diff tracking and review workflows. Embedding prompts in application configuration files (option C) scatters prompt content across multiple applications with no unified view, no shared versioning, and no cross-project reuse. Unstructured Blob Storage with folder organization (option D) provides no version history, no diff tracking, no review workflow, and no native tooling for comparing prompt variants. Git is the definitive answer for centralized tracking, versioning, and reuse of prompt content across Microsoft Foundry projects.

Microsoft Learn Reference Topic: Prompt engineering and version control – Managing prompts in AI applications with Git