For each study scenario, name the deliverable keyword, map it to one service and configuration, then refute the nearest alternative out loud. Drill this two-step habit across vision, NLP, knowledge mining, and generative AI topics. Administrative details, current exam status, and scheduling are confirmed on the Microsoft Learn credential page.
Reading scenario prompts for the discriminating detail
AI-102-style scenarios describe a business outcome plus constraints. Your task is to map the requirement keywords to one named service and configuration, and to articulate why the nearest alternative service fails to satisfy the same requirement.
Treat every practice scenario as a two-step decision. First, underline the phrase that states the deliverable: 'structured fields,' 'bounding boxes,' 'redacted entities,' 'answers with citations,' 'scheduled indexing.' Second, map that phrase to one named service and one configuration, then state why the runner-up fails. 'Key-value pairs from invoices' points to Document Intelligence prebuilt models, while 'raw text from mixed-language scans' points to the Read feature of Azure AI Vision. Practicing the explicit refutation converts scattered feature knowledge into repeatable scenario judgment.
Worked scenario: a logistics company scans supplier invoices and needs invoice numbers, totals, and line-item amounts written into an ERP system. A plausible first pick is Read OCR from Azure AI Vision, because scanned documents suggest OCR. The better decision is the prebuilt invoice model in Azure Document Intelligence. OCR returns words and text lines with coordinates, forcing hand-written parsing logic per supplier layout. The prebuilt model returns labeled fields, line-item tables, and per-field confidence, so integration code reduces to reading a structured JSON response and handling low-confidence fields.
| Requirement keyword | First choice | What it returns | Near-miss alternative |
|---|---|---|---|
| Extract invoice fields and line items | Document Intelligence prebuilt invoice | Labeled key-value pairs, tables, confidence | Azure AI Vision Read (raw text only) |
| Locate and count defects in photos | Custom Vision object detection | Bounding boxes with labels | Image classification (label only, no location) |
| Route chat utterances to billing or support | Conversational language understanding | Detected intent and entities | Custom question answering (returns text answers) |
| Remove names and card numbers from transcripts | Language Service PII detection | Categories and redacted text | Key phrase extraction (no redaction) |
| Chat over a changing document set with citations | Azure OpenAI grounded with AI Search | Grounded answer plus source references | Fine-tuning (frozen patterns, no citations) |
| Index thousands of blobs continuously | AI Search indexer (pull) | Scheduled, bulk enrichment | Push indexing (documents submitted manually) |
Planning and managing Azure AI resources without guesswork
The planning domain covers provisioning decisions: one shared resource versus dedicated resources per service, authentication with keys versus managed identities, region and storage placement, plus monitoring and responsible AI configuration for deployed solutions.
When you read a provisioning scenario, separate three concerns. Resource layout: a single multi-service resource simplifies management, while dedicated resources per service isolate billing, limits, and access control. Authentication: keys are simple for server-side development, but managed identities and Microsoft Entra ID remove stored secrets for services calling each other. Storage placement: keeping source documents and outputs in the same region as the AI resource avoids latency and data-movement surprises. Practice stating which concern each scenario constraint is actually about.
Worked scenario: a web application calls a Language Service resource directly, and a reviewer notes the endpoint key is embedded in client-side JavaScript. A tempting quick fix is rotating the key weekly. The better decision is to move the call behind a backend API or use a managed identity between Azure services, so the key never reaches the browser. This matters because any exposed key allows quota theft and unexpected cost until revoked, and the scenario constraint 'no secrets in client code' is a design requirement, not an operational chore.
Computer vision: classification, detection, or prebuilt analysis?
Image classification assigns labels to whole images, object detection returns bounding boxes with labels per object, prebuilt Vision analysis supplies captions and tags, and the Read feature extracts printed and handwritten text from images and PDFs.
Anchor each capability to the question it answers. Classification answers 'what is this image?' Detection answers 'what is here and where is it?' Prebuilt analysis answers 'describe or tag this image' without any training. Read answers 'what text does this contain?' Custom Vision enters when your domain objects are not covered by prebuilt models, and it offers both classification and detection project types. A requirement saying 'count' or 'locate' is the discriminator for detection, while 'tag each photo by category' points to classification.
Worked scenario: a factory wants photos of assemblies inspected to find missing bolts, reporting each bolt's position. A plausible mistake is training a Custom Vision image classification project, since 'inspect photos' sounds like labeling. The better decision is a Custom Vision object detection project, because only detection returns bounding boxes and per-object probabilities. With classification, the model might output 'bolts missing' with no coordinates, and the downstream reporting requirement fails even if the label accuracy looks acceptable, forcing a retraining cycle and new labeled data.
Natural language: matching Language Service features to the request
The Language Service bundles distinct features: named entity recognition, PII detection and redaction, key phrase extraction, sentiment analysis, summarization, conversational language understanding for intents, and custom question answering. Translator is the separate translation service.
Trace one requirement chain to see how features differ. A call-center transcript pipeline must (1) remove patient names and card numbers before storage, (2) detect the reason each customer called, and (3) summarize each call. Step 1 uses PII detection with redaction, not key phrases. Step 2 uses conversational language understanding with defined intents, because routing needs a predicted intent label rather than a free-text answer. Step 3 uses abstractive summarization. One document, three features, three different outputs, and each scenario constraint names its own feature.
Exercise: write five one-line requirements such as 'route utterances to returns or billing,' 'produce a two-sentence digest of each article,' 'strip employee IDs from HR documents,' 'surface the main topics of a review,' and 'answer FAQs from a support site.' For each, name the feature and the discriminator word that ruled out the second candidate. Expected observation: state why each runner-up fails in output terms — question answering returns free-text answers rather than an intent label, and key phrase extraction lists topics rather than removing text. Articulating the rejected feature's output shape is what cements the distinction.
Knowledge mining: indexer pipelines and Document Intelligence as an enrichment skill
Azure AI Search builds solutions over indexed content. Indexers pull from data sources on a schedule, skillsets enrich documents during indexing, and knowledge store projections persist enriched output. Push indexing is the alternative when documents arrive through a custom pipeline.
Pull versus push is the central indexing decision. An indexer connects to a supported source such as Azure Blob Storage, runs a skillset (OCR, language detection, entity recognition, or a custom web API skill), and writes to an index repeatedly without extra orchestration code. Push indexing makes sense when documents originate in an application, when you need transactional control over each submission, or when a source has no indexer. Scanned PDFs add a specific wrinkle: Document Intelligence can act as an enrichment step, converting page images into structured text before other skills run.
Exercise: sketch the full pipeline for a library of scanned contracts needing searchable text, extracted party names, and clause-level metadata. Expected observations: blob storage triggers the indexer; document cracking and OCR or a Document Intelligence skill handle the scanned images; entity recognition extracts party names; knowledge store projections write enriched shapes to tables or files; a final check confirms the index schema has fields mapped from each skill's output. If your sketch routes scanned files straight to the index with no OCR stage, the enrichment order needs revisiting.
Generative AI and agentic patterns: grounding versus fine-tuning versus tools
For Azure OpenAI solutions, distinguish three levers: prompt engineering shapes a single response, grounding supplies retrieved facts with citations, and fine-tuning teaches a model a stable style or format. Agentic solutions add function calling, letting the model invoke your tools and APIs.
Choose the lever that matches how the knowledge behaves. Prompt engineering is the first adjustment and costs no retraining. Grounding with Azure AI Search suits facts that change, because retrieval happens at query time and citations come from your index. Fine-tuning encodes patterns that rarely change, such as a strict output format or domain tone, but it does not give the model fresh facts, and retraining on every document update is expensive. Content filter configurations and clear system messages sit around all three levers as responsible AI controls.
Worked scenario: a support bot must answer questions over a product manual that ships updates monthly and must cite section sources. A plausible mistake is fine-tuning a model on the manual text, because 'teach it the manual' sounds natural. The better decision is grounding: index the manual in Azure AI Search, retrieve relevant chunks per query, and have the model compose answers from them. This matters because retrieval always reflects the latest indexed manual, citations are auditable, and the fine-tuned alternative would serve stale answers until an expensive retrain completed.
Agentic thinking extends this: when a requirement says 'the bot must fetch the customer's current order status,' the model should call a function or tool that hits the orders API rather than guessing. Identify the tool, its parameters, and how results return to the model, and practice describing that loop in one sentence.
A five-phase preparation sequence with a self-check rubric
Sequence your preparation in five phases: map the service portfolio, complete hands-on SDK repetitions, run scenario drills, go deep on generative AI and agentic patterns, then finish with mixed timed review. Score each drill against a three-point rubric.
Phase 1, build your own version of the discriminator table above from the six skill areas and extend it weekly. Phase 2, small hands-on reps in Python or C#: call one prebuilt model, train one tiny Custom Vision project, index a sample blob container, and complete one grounded chat call against a small index. Phase 3, written scenario drills using the rubric below. Phase 4, deep dive on Azure OpenAI deployment choices, grounding pipelines, content filters, and function calling. Phase 5, mixed drills under time pressure, revisiting only categories where your rubric scores stayed low.
Self-check rubric: for each drill scenario, award 0-2 points each for correct service choice, named discriminator keyword, and explicit refutation of the runner-up; 6 of 6 means mastery of that item, 4 or less flags it for review. Readiness checks before you finish: state the discriminator for at least fifteen scenarios without notes, explain pull versus push indexing with an example of each, choose between keys and managed identity for a given architecture, and describe a grounded generative pipeline end to end. One administrative note: the credential page on Microsoft Learn carries a retirement notice alongside its study resources, so confirm current exam status, duration, and scheduling there before booking.
- Phase 1: build and extend the keyword-to-service discriminator table
- Phase 2: hands-on reps covering one prebuilt model, one custom model, one index, one grounded chat call
- Phase 3: written scenario drills scored against the 6-point rubric
- Phase 4: deep dive on Azure OpenAI grounding, content filters, and function calling
- Phase 5: mixed timed review; revisit any category scoring below 4
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.