AI-103 sample questions — 25 answered and explained

Embeddings from different models live in different vector spaces. Matching dimensions alone does not make them comparable.

The trap is the dimensions parameter. text-embedding-3-large can return a shortened 1,536-dimension vector, so the query fits the field and no error appears. But those vectors come from a different model than the stored ones, so distances between them are meaningless. The fix is to embed documents and queries with the same model, which means re-embedding the corpus (and sizing the field for the chosen dimensions). Recall tweaks and reranking operate on top of a broken comparison.

1. Notice that the error disappeared but relevance collapsed: a silent mismatch.
2. Recall that query and document vectors must come from the same embedding model.
3. Recognise that shortening dimensions changes size, not the vector space.
4. Pick the option that re-embeds the corpus with the new model.

Exam tip: Changing embedding models means re-embedding the whole corpus; matching dimensions is not enough.

Model router is a deployable Foundry model that routes each prompt in real time to a suitable underlying LLM, trading off quality and cost behind one endpoint.

The requirements are per-request model selection, no custom model-selection code and one deployment. Model router meets all three. A pair of deployments with a classifier prompt delivers per-request selection but is the hand-built selection logic the team wants to avoid. Provisioned throughput and fine-tuning both keep every request on a single model.

1. Note the need for different models on different requests.
2. Note the constraint: no custom model-selection code and a single deployment.
3. Choose the managed routing deployment.

Exam tip: Per-request model selection behind one deployment, without your own selection code: model router.

Model router's effective context window is that of the smallest model in its routing pool; a model subset controls which models are eligible.

Two facts combine here. First, a request larger than some underlying models' context windows succeeds only if it happens to be routed to a model that can hold it, which explains the intermittent failures. Second, a custom deployment can restrict routing to a model subset, so every eligible model supports the needed context. Quality mode is the tempting answer, but it optimises answer quality rather than context size. Session affinity and auto-update solve different problems.

1. Read the symptom: intermittent context errors only on long inputs.
2. Recall that the router's context limit is set by its smallest underlying model.
3. Find the control that changes which models are eligible: the model subset.
4. Reject settings that change selection preference or versioning but not eligibility.

Exam tip: Context errors through model router: restrict the model subset to models that fit the input.

Retrieval-augmented generation (RAG) grounds answers in your own content at query time; fine-tuning changes model behaviour but does not keep facts current or provide citations.

Three requirements point to RAG: private content, weekly change and citations. Re-indexing keeps the grounding data current, and retrieved chunks carry their source document. Fine-tuning bakes knowledge into weights, which is slow to refresh and cannot cite sources. Few-shot examples in the prompt shape style but cannot hold 2,000 changing documents, and web grounding cannot reach internal content.

1. Note the content is private and changes often.
2. Note the need for citations to the source document.
3. Choose grounding at query time over changing the model's weights.

Exam tip: Private, changing content with citations: RAG, not fine-tuning.

Fine-tuning adjusts how a model responds (format, tone, style); RAG supplies what it should know. They solve different problems and are often combined.

Evaluations rule out retrieval: the right clauses arrive. The remaining failure is output style, and prompt examples have not fixed it. A large set of approved memos is exactly the training data supervised fine-tuning needs to teach a consistent structure and tone. Sending more chunks and adding semantic ranking tune retrieval, which already works, and a reasoning model improves logic rather than house style.

1. Separate the two failure types: what the model knows versus how it writes.
2. Use the evidence that retrieval is accurate to rule out retrieval changes.
3. Choose fine-tuning on approved examples to fix persistent format and tone problems.

Exam tip: Right facts, wrong format or tone after prompting: fine-tune on approved examples.

Hybrid search combines full-text (keyword) and vector queries in one request and fuses the rankings with Reciprocal Rank Fusion (RRF).

Vector search excels at meaning but is weak on exact tokens like part numbers, product codes and names. Keyword search is the reverse. A hybrid query runs both and merges them with RRF, so one search box handles both query types. Reranking, more neighbours or a bigger embedding model all stay inside vector-only retrieval.

1. Identify which queries fail: exact identifiers.
2. Recall that keyword search matches exact tokens and vector search matches meaning.
3. Choose the option that runs both and fuses the results.

Exam tip: Exact codes plus natural language: hybrid search with RRF.

In Azure AI Search, a request becomes hybrid when it carries both search_text (full-text) and one or more vector_queries.

The snippet is a vector query with semantic reranking, and search_text=None means no keyword query runs, which is why exact policy numbers are missed. Setting search_text to the user's text adds a full-text query in the same request; the service fuses both rankings with RRF and then semantic-reranks the merged results. The other changes adjust parsing or vector recall but never add keyword matching.

1. Read the request: vector query present, search_text is None.
2. Recall that hybrid means full-text plus vector in one request.
3. Pick the change that adds the full-text part.

Exam tip: Hybrid query = search_text + vector_queries in the same request.

Tool calling is a per-model capability listed on each model's catalog card.

The Foundry catalog lists Llama-3.3-70B-Instruct with 'Tool calling: No'. Request settings such as tool_choice only steer a model that already supports tools, and the Responses API doesn't add the capability. Prompting the model to imitate a call produces text, not structured tool calls. Choose a model that lists tool calling, such as Mistral-Large-3 or a GPT deployment.

1. Note the symptom: tools are sent but never called.
2. Check the model card: tool calling not supported.
3. Reject request-level settings that can't add a capability.
4. Pick a tool-calling model and keep the chat completions code.

Exam tip: Check the model card for tool calling before designing a tool-augmented flow.

The Responses API keeps multi-turn context by chaining requests to stored responses.

Each Responses API call is independent unless you link it. Passing previous_response_id=response.id tells the service to include the prior turn; alternatively you can carry the previous output items into the next input yourself. Storage settings, output length and temperature don't add the missing turn.

1. Diagnose: each call carries only the newest message.
2. Recall the Responses chaining parameter: previous_response_id.
3. Reject settings that change length, randomness or storage.

Exam tip: Chain Responses turns with previous_response_id (or carry the prior output items yourself).

The augmentation step of RAG controls whether answers stay grounded in retrieved content and remain traceable to it.

Retrieval already supplies relevant chunks; the problems are in how the prompt uses them. Labelling chunks with source IDs and asking for the ID after each claim gives citations, and instructing the model to answer only from the supplied sources, with an explicit 'I don't know' path, curbs additions from general knowledge. More chunks, exhaustive search or fine-tuning change retrieval or weights, not grounding behaviour.

1. Separate the two failures: unsupported content and missing provenance.
2. Fix provenance by labelling chunks and requiring citations.
3. Fix unsupported content with an answer-from-sources instruction and a not-found path.
4. Reject changes that only alter retrieval volume or model weights.

Exam tip: Grounded RAG prompts label sources, demand citations and give the model permission to say it doesn't know.

In multi-turn RAG, retrieval and generation are separate steps, and the retrieval query must carry the conversation's context.

Retrieval happens before generation, so giving the model history (previous_response_id) cannot fix what the search returned. And a follow-up like 'And for the X300?' lacks the noun phrase the index needs. The standard fix is query rewriting: a quick model call condenses the history and latest message into a standalone query, which is then searched. Dumping the whole history into the search text adds noise, and the semantic ranker only reorders a bad candidate set.

1. Notice that only follow-up questions fail.
2. Recall that the search step sees just the latest message.
3. Fix the query, not the model's memory: rewrite it into a standalone question.
4. Reject reranking and history dumps, which don't repair the query.

Exam tip: Rewrite follow-ups into standalone queries before retrieval; model memory doesn't fix the search.

A vector query needs a query vector: either the index's vectorizer creates it from text, or the app supplies one from the same embedding model.

Two facts decide this. A text vector query (VectorizableTextQuery, kind 'text') works only when a vectorizer is assigned to the field; this index has none and must not change. So the app must embed the question itself and send VectorizedQuery. Microsoft's guidance is to use the same embedding model for queries as for the indexed content, so text-embedding-3-large, not text-embedding-3-small. Exhaustive search doesn't remove the need for a vector.

1. Read the constraint: no index changes, so no vectorizer.
2. Recall that text vector queries need a vectorizer.
3. Switch to VectorizedQuery with an app-computed vector.
4. Use the same embedding model that built the index.

Exam tip: No vectorizer means VectorizedQuery with a vector from the same embedding model as the index.

Vector search finds nearest neighbours, and there is always a nearest neighbour, however distant.

Azure AI Search documents that vector queries return k results whenever at least k documents exist, even for nonsensical or off-topic queries, because the algorithm returns the closest vectors whatever their similarity. Mitigations include grounding instructions that let the model decline, a hybrid query, or a minimum similarity threshold (preview) on pure vector queries. The other options describe features that aren't in play or don't behave that way.

1. Note that the query is vector-only.
2. Recall that nearest-neighbour search always fills k slots.
3. Plan a mitigation: a decline instruction or a similarity threshold.

Exam tip: Vector search always returns k neighbours; relevance has to be judged downstream.

Azure OpenAI On Your Data (the data_sources request extension) is retired; Microsoft points corpus Q&A to Foundry IQ knowledge bases.

The On Your Data reference states the feature retired on 14 October 2026 and is no longer supported. For corpus Q&A, Microsoft recommends calling a Foundry IQ knowledge base directly, and adding Foundry Agent Service only when the app needs tools, actions or workflows. Classic RAG (retrieving from Azure AI Search in your own code and adding the results to the prompt) is also a generally available alternative. Swapping the data source or api-version keeps the retired extension, and fine-tuning isn't a grounding mechanism.

1. Recognise the data_sources field as Azure OpenAI On Your Data.
2. Recall that the feature is retired, for every api-version and data source.
3. Choose Microsoft's recommended path for corpus Q&A: a Foundry IQ knowledge base.

Exam tip: On Your Data is retired: ground new apps with Foundry IQ (or your own retrieval step).

In function calling, the app returns each result as a function_call_output that references the call_id of the model's function_call item.

The model's output contains function_call items with name, arguments and call_id. After the app runs the function, it sends a function_call_output item whose call_id field carries the same value, usually chaining with previous_response_id. tool_call_id is the Chat Completions equivalent and isn't accepted on a Responses input item, item.id is the output item's own ID, and response.id is used only for chaining.

1. Find the item the model produced: type function_call.
2. Use the Responses API field that links a result to a call: call_id.
3. Fill it with the call's own identifier, item.call_id.
4. Keep response.id for previous_response_id and tool_call_id for Chat Completions.

Exam tip: Return function results as function_call_output with the matching call_id.

Function calling is a contract: the model emits structured call requests, and the client application executes them.

The model returns a function_call item (name, JSON arguments, call_id). Nothing calls the API until the application runs the function and submits a function_call_output item. tool_choice and parallel_tool_calls shape what the model proposes, not who executes it. Server-side execution of HTTP APIs is a different feature: the OpenAPI tool on Foundry agents.

1. Note the evidence: function_call items exist, but the API isn't called.
2. Recall who executes function tools: the application.
3. Return the result as function_call_output so the model can answer.

Exam tip: The model asks; your code calls the function and hands back the result.

Sora 2 enforces content rules on prompts and reference images.

The Sora 2 API currently rejects real people, including public figures, and rejects input images that contain human faces; it also rejects copyrighted characters and music. A product-only reference image with a prompt about an unnamed, fictional runner meets the campaign goal within those rules. Removing the name or cropping the photo keeps a face in the input, and a remix is still a generation subject to the same restrictions.

1. List the inputs: a face in the reference image and a named real person in the prompt.
2. Recall both restrictions: no real people, no human faces in input images.
3. Keep the business goal (the product) and drop what the rules reject.

Exam tip: Sora 2 rejects real people and face images as input; build clips around products and fictional characters.

Remix edits a completed Sora 2 video while keeping its structure.

videos.remix takes the ID of a completed video and a new prompt. The service keeps the original video's framework, scene transitions and visual layout and applies the requested change. Regenerating, even from a frame of the clip, produces a new composition, and editing frames as images is a heavy custom workflow with no temporal consistency.

1. Note the constraint: keep framing, motion and timing.
2. Recall that remix reuses a completed video's structure.
3. Send the video ID with a prompt describing only the change.

Exam tip: To change a finished Sora 2 clip without re-shooting it, remix its video ID.

FLUX models in Foundry have two routes, and only the BFL provider API exposes the fine-grained controls.

FLUX models can be called through the OpenAI-compatible Image API (FLUX.1-Kontext-pro and FLUX-1.1-pro only) or through the BFL provider-specific API at https://<resource>.api.cognitive.microsoft.com/providers/blackforestlabs/v1/<model-path>?api-version=preview. Only the BFL route exposes seed, aspect_ratio, safety_tolerance and similar parameters. Its URL uses the model path (flux-kontext-pro), which is not the model ID (FLUX.1-Kontext-pro). Two facts decide: the route that has seed, and the right path on that route.

1. Identify the control needed: a fixed seed.
2. Recall that seed is exposed only by the BFL provider API, not the Image API.
3. Recall that the BFL URL uses the model path, not the model ID.
4. Reject switching to a GPT-image model, which has no seed.

Exam tip: FLUX fine controls (seed, aspect_ratio, safety_tolerance) live on the BFL route, addressed by model path.

Language models can classify custom labels such as tone that prebuilt sentiment services don't offer.

Prebuilt sentiment analysis returns a fixed sentiment scale and aspect opinions, and it's a legacy Azure Language capability. Tone categories such as sarcastic or appreciative are custom labels, which a prompted language model can assign, with a schema to return them as JSON. Content Safety and key phrase extraction answer different questions.

1. List the outputs: sentiment plus a custom tone label, as JSON.
2. Check whether a prebuilt service offers those tone labels.
3. Choose a prompted model with an output schema.

Exam tip: Custom labels like tone come from a prompted model with a schema; prebuilt sentiment has a fixed scale.

Opinion mining is aspect-based sentiment analysis in Azure Language.

Sentiment analysis returns document and sentence sentiment. Setting show_opinion_mining=True adds mined opinions: each target (an aspect such as battery) with its assessments and their sentiment. That answers the per-feature question in one flag. Sentiment analysis is a legacy Azure Language capability, supported for existing implementations like this one.

1. Identify the need: sentiment per product feature, not per sentence.
2. Recall the aspect-based option of sentiment analysis.
3. Prefer the one-flag change over multi-call workarounds.

Exam tip: Per-aspect sentiment in Azure Language is opinion mining: show_opinion_mining=True.

Content Safety returns severity on a four-level or eight-level scale.

The text analysis API returns severities as 0, 2, 4 and 6 by default (FourSeverityLevels). Setting outputType to EightSeverityLevels returns 0 to 7, which a policy that separates 4 from 5 needs. Category selection and blocklist behaviour don't change the scale.

1. Notice the returned values are only even numbers.
2. Recall the default four-level output.
3. Switch to the eight-level output for finer thresholds.

Exam tip: Need thresholds between 0, 2, 4 and 6? Ask for EightSeverityLevels.

Layout skills read the original file through /document/file_data, which exists only when allowSkillsetToReadFileData is true.

The Azure Content Understanding and Document Layout skills analyze the whole original file, not the cracked text. For blob sources the file reaches them through the /document/file_data node, which the indexer creates only when its allowSkillsetToReadFileData parameter is true. The other indexer settings control text extraction, image extraction or parsing granularity and leave file_data missing.

1. Read the error: the file_data node doesn't exist.
2. Recall which indexer parameter creates /document/file_data.
3. Set allowSkillsetToReadFileData to true.
4. Re-run the indexer.

Exam tip: No /document/file_data? Set allowSkillsetToReadFileData to true on the indexer.

Page-range citations need locationMetadata; chunks that span pages need the Content Understanding skill.

Two requirements combine here. Citing a page range needs the extractionOptions value locationMetadata, which adds page information (pageNumberFrom and pageNumberTo) to each chunk. Keeping clauses whole across page breaks needs chunks that can span pages, which the Content Understanding skill supports and the Document Layout skill doesn't, because its text chunks stay within the bounds of a page. Only the Content Understanding skill with both images and locationMetadata meets all three needs; each other option misses either the page data or cross-page chunks.

1. Split the requirements: page ranges, cross-page chunks, kept figures.
2. Recall that locationMetadata adds page data to chunks.
3. Recall which skill allows chunks to span pages.
4. Combine both in one skill configuration.

Exam tip: Citations with page ranges across page breaks: Content Understanding skill plus locationMetadata.

skipIndexingParentDocuments keeps parent-only documents out of a chunk index.

Index projections write each chunk as its own search document. By default (includeIndexingParentDocuments) the indexer also writes one document per source file whose chunk fields are null, which is how 5 files and 100 chunks become 105 documents. Setting projectionMode to skipIndexingParentDocuments leaves only the uniform chunk documents, which Microsoft recommends when chunks are the search target.

1. Count the extra documents: one per source file.
2. Recall the default projection mode includes parents.
3. Switch to skipIndexingParentDocuments.
4. Re-run the indexer.

Exam tip: Chunk index with stray empty documents? projectionMode = skipIndexingParentDocuments.