📘 Free AI-300 Sample Questions
HOTSPOT
You have an Azure subscription.
You plan to build a solution That will analyze scanned documents and export relevant fields to a
database.
You need to recommend which Azure Al service to deploy for the following types of documents:
• Internal expenditure request authorization forms
• Supplier invoices
The solution must minimize development effort.
What should you recommend for each document type? To answer, select the appropriate options in
the answer area.
A
Correct Answer:
A.
Case Study -
This is a case study. Case studies are not timed separately from other exam sections. You can use as much exam
time as you would like to complete each case study. However, there might be additional case studies or other
exam sections. Manage your time to ensure that you can complete all the exam sections in the time provided. Pay
attention to the Exam Progress at the top of the screen so you have sufficient time to complete any exam sections
that follow this case study.
To answer the case study questions, you will need to reference information that is provided in the case. Case
studies and associated questions might contain exhibits or other resources that provide more information about
the scenario described in the case. Information provided in an individual question does not apply to the other
questions in the case study.
A Review Screen will appear at the end of this case study. From the Review Screen, you can review and change
your answers before you move to the next exam section. After you leave this case study, you will NOT be able to
return to it.
To start the case study -
To display the first question in this case study, select the "Next" button. To the left of the question, a menu
provides links to information such as business requirements, the existing environment, and problem statements.
Please read through all this information before answering any questions. When you are ready to answer a question,
select the "Question" button to return to the question.
Background -
Fabrikam Inc. is a mid-sized healthcare analytics company that provides population health dashboards and
predictive insights to regional hospital systems across the United States. Fabrikam Inc. customers rely on near real
time analytics to monitor patient flow, staffing needs, and readmission risks. They use multiple traditional
forecasting machine learning models for predictions.
Fabrikam Inc. has an established Microsoft Azure footprint. The company uses Jupyter Notebooks that run on a
local server as the primary development environment. The data science team is experiencing scalability, asset
management and code management issues with the current development platform. Fabrikam Inc. plans to migrate
to a cloud-based development environment to mitigate the issues.
Additionally, the company plans to implement a Retrieval-Augmented Generation (RAG)-based chat application for
client support. Leadership requires the application to be developed and deployed with a low operational risk.
Current Environment -
Fabrikam Inc. operates a single Azure subscription that has the following components:
Azure Data Lake Storage Gen2 that contains de-identified clinical and operational datasets
Azure AI Search indexing curated analytical documents and reference materials
A small set of Python-based training scripts maintained by data scientists
Azure OpenAI Service with deployed foundational models
A Microsoft Foundry resource for building a RAG-based solution
Evaluation data has manually defined expected responses.
The current challenges faced by the data science team include the following:
Model training jobs are run manually from notebooks.
Experiment tracking is inconsistent
Model versions are registered without standardized metadata.
Deployment is performed manually by data scientists, with limited rollback capability.
The team has no standardized evaluation process for generative AI outputs.
The environment currently allows public network access. Authentication relies on user accounts rather than
managed identities. Compute targets are manually created and shared across experiments. This has led to
resource contention during peak usage.
Business Requirements -
Fabrikam Inc. has the following business requirements for the modernization initiative:
Provide a conversational interface that answers analytics questions by using internal documents and datasets.
Ensure that sensitive healthcare-related data is not exposed outside the Fabrikam Inc. Azure tenant.
Enable repeatable and auditable model training and deployment processes.
Support experimentation to compare prompt strategies and fine-tuned models.
Align the model with the ranked preferences and optimize behavior for the long term.
Minimize disruption to existing analytics workloads during rollout.
Technical Requirements -
To support the business goals, Fabrikam Inc. identifies these technical requirements:
Use Azure Machine Learning workspaces to centrally manage data assets, models, and environments.
Implement experiment tracking and model versioning for all training jobs.
Orchestrate training and evaluation by using pipelines rather than manually running notebooks.
Deploy traditional machine learning models with support for staged rollout and rollback.
Improve RAG-based solution output quality.
Use the existing evaluation datasets that are based on real data with input-output pairs.
Apply advanced fine-tuning techniques only when prompt engineering is insufficient
Issues and Constraints -
Fabrikam Inc. must comply with internal security policies that require the company to restrict network access and
avoid long-lived secrets. The data science team has limited Azure DevOps experience, so solutions must favor
managed services and automation over custom infrastructure.
Cost predictability is important. Leadership prefers serverless or managed compute options where possible but is
willing to approve dedicated compute for stable production workloads.
Problem Statement -
Fabrikam Inc. must design and implement an Azure-based AI operations solution that enables reliable training,
evaluation, deployment, and iteration of generative AI models. The solution must support experimentation and
gradual rollout while ensuring governance, security, and operational stability. The data science and platform
teams must collaborate to deliver this solution by using Azure Machine Learning and Microsoft Foundry
capabilities.
You need to standardize how Fabrikam Inc. manages machine learning assets.
Which action should you perform first?
A
Register assets in the Azure Machine Learning registry.
B
. Create a shared Azure Machine Learning workspace.
C
Deploy a managed online endpoint.
D
Create a new Microsoft Foundry project.
Correct Answer:
B. . Create a shared Azure Machine Learning workspace.
Explanation:
Why option B is the best first action
The Azure Machine Learning workspace is the central hub for all ML assets, experiment tracking, model
versioning, pipeline orchestration, and integration with other Azure services (Data Lake, Azure Al Search,
OpenAl, etc.).
Creating a shared workspace early establishes a single, governed environment that enforces access controls,
network restrictions, and identity-based authentication, directly satisfying the security and compliance
constraints.
Once the workspace exists, the team can register assets into an Azure MLregistry, set up pipelines, and later
deploy endpoints-each of these steps builds on the workspace foundation.
Deploying a managed online endpoint (C) or creating a MicrosoftFoundry project (D) without first
consolidating onto a shared workspace would fragment governance and make auditability harder.
Registering assets in a registry (A) is valuable but presupposes an already-established workspace that can
host the registry and enforce policies.
Therefore, the initial step must be to create a shared Azure Machine Learning workspace to provide the
required central management, governance, and security baseline for all subsequent modernization activities.
Why the other options are less suitable at this stage
A-Register assets in the Azure Machine Learning registry - Asset registration presupposes that a
workspace already exists to host the registry and enforce access controls; doing it first would leave the team
without a governed environment.
C-Deploy a managed online endpoint - Endpoint deployment is a production-level operation that requires
validated models, model versioning, and CI/CD pipelines, all of which rely on a shared workspace for
reproducibility and auditability.
D-Create a new Microsoft Foundry project - While Foundry orchestrates end-to-end Al workflows, its setup
benefits from an already-configured Azure ML workspace to anchor model training, evaluation, and
deployment resources.
References
Azure Machine Learning workspace overview: https://learn.microsoft.com/azure/machine-learning/concept-
workspace
Manage and track experiments with Azure Machine Learning: https://learn.microsoft.com/azure/machine-
learning/how-to-track-experiments-and-register-models
Case Study -
This is a case study. Case studies are not timed separately from other exam sections. You can use as much exam
time as you would like to complete each case study. However, there might be additional case studies or other
exam sections. Manage your time to ensure that you can complete all the exam sections in the time provided. Pay
attention to the Exam Progress at the top of the screen so you have sufficient time to complete any exam sections
that follow this case study.
To answer the case study questions, you will need to reference information that is provided in the case. Case
studies and associated questions might contain exhibits or other resources that provide more information about
the scenario described in the case. Information provided in an individual question does not apply to the other
questions in the case study.
A Review Screen will appear at the end of this case study. From the Review Screen, you can review and change
your answers before you move to the next exam section. After you leave this case study, you will NOT be able to
return to it.
To start the case study -
To display the first question in this case study, select the "Next" button. To the left of the question, a menu
provides links to information such as business requirements, the existing environment, and problem statements.
Please read through all this information before answering any questions. When you are ready to answer a question,
select the "Question" button to return to the question.
Background -
Fabrikam Inc. is a mid-sized healthcare analytics company that provides population health dashboards and
predictive insights to regional hospital systems across the United States. Fabrikam Inc. customers rely on near real
time analytics to monitor patient flow, staffing needs, and readmission risks. They use multiple traditional
forecasting machine learning models for predictions.
Fabrikam Inc. has an established Microsoft Azure footprint. The company uses Jupyter Notebooks that run on a
local server as the primary development environment. The data science team is experiencing scalability, asset
management and code management issues with the current development platform. Fabrikam Inc. plans to migrate
to a cloud-based development environment to mitigate the issues.
Additionally, the company plans to implement a Retrieval-Augmented Generation (RAG)-based chat application for
client support. Leadership requires the application to be developed and deployed with a low operational risk.
Current Environment -
Fabrikam Inc. operates a single Azure subscription that has the following components:
Azure Data Lake Storage Gen2 that contains de-identified clinical and operational datasets
Azure AI Search indexing curated analytical documents and reference materials
A small set of Python-based training scripts maintained by data scientists
Azure OpenAI Service with deployed foundational models
A Microsoft Foundry resource for building a RAG-based solution
Evaluation data has manually defined expected responses.
The current challenges faced by the data science team include the following:
Model training jobs are run manually from notebooks.
Experiment tracking is inconsistent
Model versions are registered without standardized metadata.
Deployment is performed manually by data scientists, with limited rollback capability.
The team has no standardized evaluation process for generative AI outputs.
The environment currently allows public network access. Authentication relies on user accounts rather than
managed identities. Compute targets are manually created and shared across experiments. This has led to
resource contention during peak usage.
Business Requirements -
Fabrikam Inc. has the following business requirements for the modernization initiative:
Provide a conversational interface that answers analytics questions by using internal documents and datasets.
Ensure that sensitive healthcare-related data is not exposed outside the Fabrikam Inc. Azure tenant.
Enable repeatable and auditable model training and deployment processes.
Support experimentation to compare prompt strategies and fine-tuned models.
Align the model with the ranked preferences and optimize behavior for the long term.
Minimize disruption to existing analytics workloads during rollout.
Technical Requirements -
To support the business goals, Fabrikam Inc. identifies these technical requirements:
Use Azure Machine Learning workspaces to centrally manage data assets, models, and environments.
Implement experiment tracking and model versioning for all training jobs.
Orchestrate training and evaluation by using pipelines rather than manually running notebooks.
Deploy traditional machine learning models with support for staged rollout and rollback.
Improve RAG-based solution output quality.
Use the existing evaluation datasets that are based on real data with input-output pairs.
Apply advanced fine-tuning techniques only when prompt engineering is insufficient
Issues and Constraints -
Fabrikam Inc. must comply with internal security policies that require the company to restrict network access and
avoid long-lived secrets. The data science team has limited Azure DevOps experience, so solutions must favor
managed services and automation over custom infrastructure.
Cost predictability is important. Leadership prefers serverless or managed compute options where possible but is
willing to approve dedicated compute for stable production workloads.
Problem Statement -
Fabrikam Inc. must design and implement an Azure-based AI operations solution that enables reliable training,
evaluation, deployment, and iteration of generative AI models. The solution must support experimentation and
gradual rollout while ensuring governance, security, and operational stability. The data science and platform
teams must collaborate to deliver this solution by using Azure Machine Learning and Microsoft Foundry
capabilities.
You need to isolate training workloads while remaining cost-aware to address Fabrikam Inc.’s issues, constraints,
and technical requirements.
What should you implement?
A
Training jobs that run on a single shared compute cluster
B
Fixed-size compute cluster
C
Dedicated compute clusters per experiment
D
Managed compute targets with autoscaling
Correct Answer:
D. Managed compute targets with autoscaling
Explanation:
Justification
Isolation & Contention – The current manual notebook workflow lets multiple data-science teams share the
same compute resources, causing resource contention during peak usage.Managed compute targets that are
automatically scaled create an isolated environment for each training job, eliminating interference with other
experiments.
Cost Predictability – Autoscaling provisions compute only when needed and de-allocates it when the job
completes, matching Fabrikam’s desire for a cost-aware solution. Fixed-size or dedicated clusters (OptionsB
andC) would keep resources running unnecessarily, inflating spend.
Security & Governance – Managed compute targets integrate with Azure Machine Learning’s identity model,
supporting managed identities instead of long-lived secrets, and enforce network-level restrictions (e.g.,
private endpoints, VNet injection). This aligns with security policies that forbid public network exposure.
Operational Standardisation – By using Azure Machine Learning’s managed compute, every training job
automatically benefits from consistent versioning, logging, and artifact storage, enabling repeatable pipelines
and audit-ready model registers.
Scalability for RAG Experiments – When evaluating prompt strategies or fine-tuning, the system can spin up
additional worker nodes on demand, supporting rapid iteration without provisioning permanent infrastructure.
Alignment with Technical Requirements – The approach fulfills the mandate to “use Azure Machine Learning
workspaces to centrally manage data assets, models, and environments” while meeting the constraints of
limited DevOps expertise and preference for managed services.
Why the other options are less suitable
A – Single shared cluster – Leads to ongoing contention, does not provide isolation, and offers no automatic
scaling, which contradicts the need to isolate workloads and keep costs predictable.
contrary to the “managed services” preference.
References
B – Fixed-size cluster – Provides a static compute pool that can be under- or over-provisioned; it lacks
autoscaling, so cost efficiency and elasticity are lost, and it does not isolate per-experiment workloads.
C – Dedicated compute clusters per experiment – While isolation is achieved, it results in manually
maintained clusters, higher operational overhead, and does not leverage autoscaling, making it costly and
Azure Machine Learning compute targets overview: https://learn.microsoft.com/azure/machine-learning/how-
to-set-up-training-targets
Autoscaling compute clusters in Azure Machine Learning: https://learn.microsoft.com/azure/machine-
learning/how-to-use-autorscale Compute clusters
HOTSPOT -
A team trains an MLflow model that scores customer churn risk. The model will be consumed by different
downstream systems.
One system requests predictions synchronously during customer interactions.
Another system submits files containing millions of records for scheduled scoring.
You need to deploy the model by using managed inference options that match each usage pattern.
Which option should you use for each usage pattern? To answer, select the appropriate options in the answer area.
NOTE: Each correct selection is worth one point.
A
Correct Answer:
A.
Explanation:
Real-time endpoint.
Designed for instant responses (milliseconds-seconds)
Handles synchronous requests (request - immediate response)
Ideal for:
Chatbots
Live recommendations
Interactive apps.
Batch endpoint.
Designed for large-scale, offline processing
Runs on scheduled or triggered jobs
Optimized for:
Bulk inference
Data pipelines
Cost efficiency
A team manages an Azure Machine Learning workspace where they deploy models to online endpoints.
The team needs to introduce a new version of a model to production without disrupting existing users.
The team must validate the new version before full rollout.
You need to reduce risk during deployment.
What should you do?
A
Deploy the model to a batch endpoint.
B
. Split traffic between deployments.
C
Replace the existing endpoint.
D
Route all traffic to the new deployment.
Correct Answer:
B. . Split traffic between deployments.
Explanation:
Why "Split traffic between deployments" is the optimal choice
Gradual exposure - By assigning a configurable percentage of incoming requests to the new model while the
remainder continues to serve the current version, the team can observe real-world performance, latency, and
error rates without risking the entire user base.
Rollback simplicity - If the new model exhibits unacceptable behavior, the percentage can be reduced to0%
instantly, reverting all traffic to the proven endpoint, thus minimizing service impact.
A/B testing capabilities - Traffic split enables direct comparison of metrics (prediction quality, compute cost,
resource usage) between versions, supporting data-driven validation before a full switch.
Compliance with Azure ML best practices - Deployment slots and traffic routing are built-in features
designed precisely for this "canary" or "blue-green" release pattern, ensuring safe model lifecycle
management.
Why the other options are inadequate
A. Deploy the model to a batch endpoint - Batch endpoints are intended for asynchronous, offline scoring
where request-response latency is not a concem. Online inference for production users requires a real-time
endpoint; batch deployment does not provide any rollout control for live traffic.
C. Replace the existing endpoint - Performing a full replacement eliminates the production version instantly,
leaving no fallback path. Any issue with the new model would cause immediate service disruption for all users,
increasing risk rather than reducing it.
D. Route all traffic to the new deployment - Sending 100% of requests to the unvalidated model bypasses
any safety net. Without an initial validation window, any defects (e.g., accuracy regression, performance
degradation) propagate instantly, jeopardizing availability and user experience.
References
Microsoft Learn - Deploy and manage Azure Machine Learning models - Traffic splitting for canary releases:
https://learn.microsoft.com/azure/machine-learning/how-to-deploy-online-endpoints#traffic-splitting
Azure Machine Learning documentation - Blue-green deployment using endpoint versioning:
https://learn.microsoft.com/azure/machine-learning/how-to-canary-deploy-models
You have a deployment of an Azure OpenAI Service base model.
You plan to fine-tune the model.
You need to prepare a file that contains training data.
Which file format should you use?
A
. CSV
B
TSV
C
JSONL
D
JSON
Correct Answer:
C. JSONL
Explanation:
Justification
Correct option –JSONL
Azure OpenAI fine-tuning expects a JSON Lines (JSONL) file where each line is a self-contained JSON object
describing a single training example (e.g., "prompt": "...", "completion": "...").
The service ingests the file line-by-line, validates the JSON schema, and streams the data efficiently to the
training job.
JSONL is the only format officially documented and supported for both base-model fine-tuning and
parameter-efficient fine-tuning (LoRA, adapters).
Why CSV/TSV are unsuitable
without additional processing.
Why plain JSON is unsuitable
CSV/TSV are flat, delimited text files that cannot express nested objects or multiple fields per example
cause request size limits to be exceeded.
Why JSONL is the optimal choice
Azure OpenAI does not provide an automatic converter or schema inference for these formats, so training
would fail or require custom preprocessing scripts.
A single JSON array containing all records is not accepted; the service only streams line-delimited JSON.
Loading an entire array into memory would violate the service’s streaming-ingest requirement and could
Guarantees compliance with the API contract (each line = one training record).
Enables scalability (files can be many GBs) and parallel processing.
Aligns with the examples shown in Microsoft’s fine-tuning documentation and SDK code samples.
Answer: C – JSONL
References
Fine-tune a model with Azure OpenAI Service – Data format requirement (JSONL):
Prepare training data for fine-tuning (JSONL specification): https://learn.microsoft.com/azure/cognitive-
services/openai/guides/fine-tuning?tabs=python
You have a deployment of an Azure OpenAI Service base model.
You plan to fine-tune the model.
You need to prepare a file that contains training data for multi-turn chat.
Which file encoding method should you use?
A
. ISO-8859-1
B
UTF-16
C
UTF-8
D
ASCII
Correct Answer:
C. UTF-8
Explanation:
Correct answer: C – UTF-8
Why UTF-8 is optimal
Azure OpenAI fine-tuning scripts and the underlying tokenizer expect text encoded in UTF-8; this is the
default for all supported instructions (e.g., prepare_data.py).
UTF-8 is fully compatible with Unicode characters, allowing the inclusion of multi-language prompts, special
tokens, and meta-data without loss of information.
Why the other encodings are unsuitable
References
to/prepare-your-data
your-data
The format is widely supported across Azure services, CLI tools, and storage connectors, ensuring seamless
ingestion when the data is uploaded to Azure Blob/ADLS or passed directly to the training API.
stripped or cause encoding errors during preprocessing.
ISO-8859-1 – limited to Western European characters; it cannot represent many non-ASCII symbols (e.g.,
emojis, Asian scripts) used in chat datasets, leading to data loss or mis-interpretation.
UTF-16 – while Unicode-compliant, Azure OpenAI tooling does not automatically detect UTF-16; it may ignore
or mis-read such files, and it adds unnecessary byte overhead (2bytes per code unit) compared to UTF-8.
ASCII – only supports the 0-127 code range; any non-English text, special punctuation, or formatting will be
Azure OpenAI documentation – Data preparation: https://learn.microsoft.com/azure/ai-services/openai/how-
OpenAI fine-tuning guide – Input format: https://platform.openai.com/docs/guides/fine-tuning/preparing-
These links provide the official specifications for required file encoding when preparing multi-turn chat
training data for Azure OpenAI models.
You are fine-tuning a base language model to analyze customer feedback.
You label examples of support tickets. You must improve classification accuracy by configuring and fine-tuning
the base model in Microsoft Foundry.
You need to configure and run fine-tuning.
What should you do first?
A
Use prompt flow to generate multiple prompt templates for evaluation.
B
Deploy the base model to an online endpoint before starting fine-tuning.
C
Enable tracing for all inference calls in the evaluation pipeline.
D
Format the dataset as a JSONL file with prompt-completion pairs and upload the file.
Correct Answer:
C. Enable tracing for all inference calls in the evaluation pipeline.
Explanation:
Why optionC is the best first step
Visibility into inference quality – Enabling tracing captures latency, error rates, and token usage for every
call made by the evaluation pipeline. This data is essential to diagnose problems (e.g., out-of-domain inputs,
token-limit overflows) before any model-level changes are introduced.
Feedback loop for prompt design – The logged traces feed directly into prompt-flow evaluation, allowing you
to measure which prompts actually perform well on the support-ticket domain. Without this visibility you
cannot reliably generate or refine prompt templates (OptionA).
Fine-tuning readiness – Tracing configures the underlying infrastructure (e.g., logging hooks, metric
collection) that the fine-tuning workflow expects. It ensures that any subsequent model updates can be
measured against a baseline, making the fine-tuning loop reproducible and auditable.
Minimal prerequisites – Unlike deploying the model to an online endpoint (OptionB) or re-formatting the
dataset (OptionD), enabling tracing can be turned on instantly in the evaluation definition and does not require
external resources or file uploads before the first run.
Why the other options are less suitable as the first action
their quality.
References
A – Generate prompt templates via Prompt Flow – This step assumes you already have a working evaluation
pipeline that can be traced; otherwise you would be generating prompts blindly and have no way to assess
B – Deploy the base model to an online endpoint – Deployment is needed only when the model must serve
production traffic. Fine-tuning can be orchestrated from a training cluster without exposing an endpoint first.
D – Format the dataset as JSONL and upload – While data preparation is critical, the dataset can be uploaded
later once you have traced the current inference behavior and identified the required prompt format; it does
not enable the diagnostic foundation required for a successful fine-tuning cycle.
Microsoft Foundry – Enabling tracing for inference pipelines
Fine-tuning models in Azure Machine Learning (Foundry integration)
A team is working in Microsoft Foundry to test and compare large language model (LLM) prompt variants in a
development environment.
The team requires consistent inputs to evaluate prompt variants without relying on live user traffic.
You need to create a controlled evaluation of input data.
Which action should you perform first?
A
Generate synthetic interaction data.
B
Configure content filters.
C
Apply a blocklist.
D
Enable observability metrics.
Correct Answer:
A. Generate synthetic interaction data.
Explanation:
Technical justification
Generating synthetic interaction data provides a repeatable, controlled source of input that can be precisely
shaped to match the characteristics the team wants to evaluate (e.g., query length, style, intent, ambiguity). In
a development or testing environment, synthetic data eliminates reliance on live traffic while preserving the
statistical properties needed to compare prompt variants objectively.
Option A – Generate synthetic interaction data – Directly creates a reproducible dataset that can be fed to
each prompt variant, enabling fair side-by-side performance measurement and iteration without external
variables.
Option B – Configure content filters – Addresses safety or compliance concerns, but does not supply the
structured input data required for systematic prompt testing.
Option C – Apply a blocklist – Also focuses on restricting undesirable content; it does not create or
standardize the input set for evaluation.
inputs needed for initial comparison.
References
Option D – Enable observability metrics – Useful for monitoring model behavior in production, yet it is a
downstream activity that presupposes an already-defined input stream; it does not establish the controlled
Thus, the first step must be to generate synthetic interaction data to build the consistent inputs required for
a reliable, repeatable evaluation of LLM prompt variants.
Microsoft Foundry documentation on generating synthetic datasets for AI model testing:
https://learn.microsoft.com/en-us/foundry/synthetic-data
Azure Machine Learning guide on synthetic data generation for model evaluation:
https://learn.microsoft.com/en-us/azure/machine-learning/how-to-generate-synthetic-data
Questions: 1-10 out of 107
Continue Full Practice..
GET ALL 107 QUESTIONS