Part 5 Full Quiz

B is correct. OcrSkill reads text from images embedded in documents (scanned pages, image attachments). However, OcrSkill writes its output to its own field — not the main content field. MergeSkill is always paired with OcrSkill: it takes the OCR output and merges it with the original document text into one unified content field that downstream skills and the index can use. Without MergeSkill, OCR-extracted text is isolated and not part of the searchable content (D is wrong). SentimentSkill and NER (A) operate on already-extracted text — they don't help get text out of images. SplitSkill + Embedding (C) enables vector search but doesn't extract image text.

C is correct. Category needs: filterable (so users can select "Electronics" to filter) and facetable (to generate the "Electronics (45)" aggregated counts in the sidebar). Making it "searchable" (A/B) would enable full-text search within category names — not what's needed here. in_stock must be filterable to be used in $filter expressions ($filter=in_stock eq true). price must be filterable ($filter=price lt 500) and sortable ($orderby=price asc). A field must be filterable before it can be used in filter expressions or sort operations.

B is correct. Knowledge Store is designed exactly for this use case — persisting enriched content outside the search index for analytics and reporting. You define projections inside the skillset: table projections (→ Azure Table Storage, ideal for Power BI), object projections (→ Blob Storage, full JSON documents), and file projections (→ Blob Storage, extracted images). Power BI connects directly to Table Storage. Scoring Profiles (A) affect relevance ranking — not data routing. Semantic Ranking (C) re-orders search results — it has no data export capability. Custom Skill (D) could work technically, but Knowledge Store is the purpose-built, no-code Azure-native solution for this exact requirement.

C is correct. The pyramid of relevance quality in Azure AI Search is: Keyword < Vector < Hybrid (RRF) < Hybrid + Semantic Ranking. Hybrid search merges keyword and vector results using Reciprocal Rank Fusion (RRF) — handling both exact vocabulary and semantic meaning. Adding semantic ranking on top applies a language model to re-score results by deep semantic relevance, returning semantic captions and answers. Standard tier supports semantic ranking. Scoring Profile (A) boosts fields but doesn't improve semantic understanding. Vector-only (B) misses exact product name/code matches. Synonym maps (D) require manually maintaining every synonym pair — not scalable.

C is correct. The Indexer is the pipeline orchestrator. It: (1) connects to the data source and reads documents, (2) passes each document through the Skillset where AI skills enrich the content, (3) writes the enriched document fields to the Index, (4) tracks state to only re-process changed documents on subsequent runs. The Skillset only defines the AI steps — it doesn't pull data or write to the Index itself. The Index is the final searchable store — it doesn't pull data, it only receives it from the Indexer. The data source is passive — it doesn't push data anywhere.

C is correct. The key phrase is "same standardised form" and "always in section X" — this is a fixed-layout document. Custom Template model is optimised for fixed-layout forms where fields always appear in the same position on every document. The minimum training requirement is 5 labelled documents. Custom Neural (B) is for variable-layout documents — using it here adds unnecessary complexity, and 50 is not a hard minimum. Prebuilt Invoice (A) doesn't cover mortgage applications. Layout (D) extracts raw structure but doesn't label semantic field names.

C is correct. The scenario describes multiple distinct layouts needing one endpoint — the exact use case for a Composed model. Each carrier has unique layouts (→ Custom Neural models), then all are composed into one model. The Composed model automatically classifies incoming documents and routes to the best component model. Option B (one neural model across all 15) is less accurate than composition — the model sees too many conflicting patterns. Prebuilt Invoice (A) may not have carrier-specific fields. Manual routing (D) defeats the purpose of a unified endpoint and adds external logic.

C is correct. begin_analyze_document() is asynchronous — it submits the job and returns a DocumentOperationPoller object immediately (not the result). To get the actual extracted data, you call poller.result(), which blocks until the operation completes (polling internally) and returns an AnalyzeResult object. You then iterate over result.documents and access doc.fields for the extracted fields. Option A is wrong — the result is not immediately available. Option B confuses REST response codes with the Python SDK pattern. Option D is manual polling — the SDK's .result() handles this automatically.

C is correct. The prebuilt ID Document model (passports, driver's licences, national IDs) is a Limited Access feature — like Face API identification. Microsoft requires organisations to apply, demonstrate a legitimate use case, and receive approval before deploying in production. This policy protects personal identity information. The model doesn't require custom training (A) — it's pre-trained by Microsoft. Pricing tier (B) doesn't unlock Limited Access features. Layout model (D) extracts raw text but doesn't understand passport field semantics (doesn't know "MRZ line 1" = date of birth).

B is correct. In 2023 Microsoft renamed Azure Form Recognizer to Azure Document Intelligence. Both the service name and the Python SDK changed: old package azure-ai-formrecognizer → new package azure-ai-documentintelligence; old client FormRecognizerClient → new client DocumentIntelligenceClient. The exam may use either name — they refer to the same underlying service. The old SDK still works for older API versions but is not updated with new features. New code should always use the new package.

C is correct. Content Understanding's audio modality handles the entire pipeline: (1) transcription is automatic for all audio inputs, (2) a field schema with AccountNumber extracts the account number from the transcript, (3) classification labels the call type, (4) a Sentiment field captures overall emotional tone — all in one submit-and-poll operation. Option D (three separate pipelines) works technically but is the wrong exam answer — Content Understanding's entire value proposition is consolidating this into one pipeline. Document Intelligence (B) has no audio capability. Azure AI Language (A) can do NLP on text but cannot process audio directly — you'd still need a separate transcription step.

C is correct. The Field Schema is a list of named output fields you want extracted from every piece of content. Each field has: a name (what you call it in the output JSON), a type (number, date, string, array — tells the AI what format to return), and a description in plain English (e.g. "The total monetary value of the contract") that instructs the AI language model what to look for. No labelling or training required — the LLM uses your descriptions as instructions. Content modalities are defined by the "scenario" setting in the analyzer, not the field schema. There is no confidence threshold setting in the schema.

C is correct. HTTP 202 Accepted is the standard async response across all Azure AI document processing APIs (Document Intelligence, Content Understanding, batch translation, etc.). It means the job is queued and processing — not that something went wrong. The developer must: (1) read the Operation-Location header from the 202 response (this is the polling URL), (2) send GET requests to that URL periodically until the JSON body's status field becomes "succeeded", (3) then read the full result JSON containing extracted fields, summary, and classification. Re-POSTing to the same endpoint (D) would submit a second duplicate job.

C is correct. Content Understanding's document analyzer supports all three operations simultaneously in a single submission: a field schema for structured field extraction, summarisation using an LLM backbone, and classification with defined category labels — all returned in one result JSON per document. No separate calls or code stitching needed. Document Intelligence (A) has no summarisation or classification capability — it does structured field extraction only. AI Search skillsets (B) are optimised for indexing and search, not extracting semantic named fields or summarising. Option D works but is the exact anti-pattern Content Understanding was built to replace.

A is correct. (1) Fixed layout → Custom Template model. (2) Same fields, 20 different adjuster layouts → Custom Neural model (variable layouts; if each adjuster layout is sufficiently distinct, individual models + Composed is even better). (3) Agent search across 50,000 pages → Azure AI Search — indexed, queryable. (4) Phone call recordings → Content Understanding audio analyzer — transcribes, extracts fields, classifies. (5) Scanned legacy PDFs with no text → AI Search with OcrSkill + MergeSkill in a skillset — OCR extracts handwritten text, MergeSkill combines, then it's indexed for search. Option B misidentifies (1) as Invoice and (4) as Document Intelligence Read model (which handles documents/images, not audio). Option C misidentifies (1) as Neural. Option D has multiple wrong assignments.