Plan and manage an Azure AI solution practice questions

Where a model runs is part of model choice: offline or on-device requirements point to a small language model run locally rather than any cloud deployment type.

Two constraints decide: the feature must work with no network, and it should not incur per-token cloud charges. Only a model running on the laptop satisfies both. Small language models are sized for modest local hardware, and Foundry Local serves them through an OpenAI-compatible local endpoint. Every cloud option, however cheap or well provisioned, still needs connectivity.

1. Spot the deciding constraint: no network access during the task.
2. Rule out every option that calls a cloud endpoint, regardless of deployment type.
3. Choose a small model that fits local hardware and runs on the device.

Exam tip: Offline or on-device requirement: run a small language model locally, not a cloud deployment.

Reasoning models (for example the o-series) spend extra compute thinking through multistep problems; they are the choice when a task fails on chained logic rather than on missing information.

The stem removes the grounding explanation: the rules are present on every request. The failure is in reasoning across several dependent rules, and accuracy outranks latency. A reasoning model addresses exactly that with no new data pipeline. Fine-tuning is the tempting alternative, but it is slower to build and mainly shapes format and tone. Retrieval changes and a cost-oriented router do not touch the reasoning step.

1. Locate the failure: information is present, but multistep application of it goes wrong.
2. Note that accuracy is prioritised over latency.
3. Choose the model class designed for multistep reasoning before considering costlier fixes.

Exam tip: Right facts in context, wrong multistep conclusions: move to a reasoning model.

Multimodal models accept more than one input type, such as image plus text, and reason across them in a single response.

The task needs one model that takes a photo and a question together and answers in natural language about the image. That is the definition of a multimodal (vision-capable) chat model. A text-only SLM cannot see the image, an image generation model produces images rather than answers, and an embedding model returns vectors.

1. Identify the inputs: a photo plus a question.
2. Identify the output: a natural-language answer grounded in the photo.
3. Pick the model class that accepts image input and produces text output.

Exam tip: Image in, answer out: use a multimodal chat model.

Azure Content Understanding in Foundry Tools turns documents, images, audio and video into structured output defined by an analyzer's field schema, with confidence and grounding per field.

The deciding requirements are a fixed schema across many layouts, per-field confidence to drive human review, and minimal prompt engineering. Content Understanding is built for that: you define the fields once in an analyzer and it returns each value with a confidence score and where it came from. Prompting a multimodal model can work but leaves schema enforcement, prompt maintenance and confidence handling to the team. Search indexing and translation solve different problems.

1. List the outputs needed: fixed fields, line items and per-field confidence.
2. Note the constraint to minimize prompt engineering.
3. Choose the prebuilt extraction service that returns a schema with confidence over a hand-built prompt.

Exam tip: Structured fields with confidence from varied documents: Content Understanding analyzer, not a hand-prompted model.

Foundry Tools (formerly Azure AI services) provide prebuilt capabilities such as Azure Speech, Azure Translator, Azure Language and Azure Content Understanding that often beat a hand-built LLM flow on effort and fidelity.

Each feature has a deciding detail. Live transcription with domain vocabulary needs real-time speech to text plus customisation, which is Azure Speech with a custom speech model. Translating thousands of Word files while keeping structure is what Translator document translation does natively. An LLM flow could translate the words, but rebuilding layout is extra development. Content Understanding handles recorded media rather than live streams, and Language summarisation assumes a transcript already exists.

1. Split the scenario into its two features and find each one's deciding detail.
2. Live audio plus custom vocabulary points to Azure Speech with a custom model.
3. Whole documents with preserved formatting point to Translator document translation.
4. Reject options that need extra build work or handle a different input mode.

Exam tip: Prefer a prebuilt Foundry Tool when it already does the whole job: Speech for live audio, Translator for documents.

Vector search needs an embedding model: it maps text to vectors so that similar meanings land close together.

Similarity by meaning is the job of vector search, and vector search compares embeddings. Only an embedding model, such as text-embedding-3-large or text-embedding-3-small, produces those vectors. Chat, reasoning and small instruct models generate text, so none of them fills a vector field.

1. Recognise the requirement as semantic similarity search.
2. Recall that a vector field stores embeddings.
3. Choose the embedding model rather than a text-generation model.

Exam tip: Vectors for search come from an embedding model, not a chat model.