Implement information extraction solutions practice questions

With native blob soft delete detection, the indexer removes a document when it processes the blob in its soft deleted state.

Native blob soft delete detection doesn't remove anything by itself. Azure Storage moves the deleted blob into a soft deleted state, and the next indexer run that processes it deletes the matching search document. If the indexer hasn't run since the deletes, the documents are still there. The retention period should be much longer than the indexer interval so the run happens before the blob is permanently purged, and a metadata-column policy is only the alternative approach, not an extra requirement.

1. Confirm the prerequisites are met: soft delete enabled, versioning off, policy present from the first run.
2. Recall that the indexer acts only when it processes a soft deleted blob.
3. Ask whether the indexer has run since the deletes.
4. Run the indexer (or wait for its schedule) to remove the documents.

Exam tip: Soft delete detection takes effect on the indexer's next run, while the blob is still soft deleted.

Native blob soft delete detection needs versioning off and must be in place from the indexer's first run.

Two separate facts decide this. First, the native blob soft delete detection policy isn't supported when blob versioning is enabled on the storage account. Second, a deletion detection strategy has to exist from the very first indexer run: blobs deleted before the policy existed leave orphaned documents that a reset doesn't clean up, and Microsoft suggests a new index and indexer with the policy set from the start. A reset, a metadata-column policy or a longer retention period each miss at least one of those facts.

1. List the blockers: versioning on, policy added late.
2. Recall that native soft delete detection is unsupported with versioning.
3. Recall that deletions before the policy existed aren't removed by a reset.
4. Disable versioning and rebuild with the policy from the first run.

Exam tip: Native soft delete detection: versioning off, policy from day one; a late policy needs a fresh index and indexer.

Text inside images needs image normalization plus the OCR skill.

An indexer can only read text that exists as text. A scanned TIFF is an image, so its content field is empty. Setting the indexer's imageAction to generateNormalizedImages creates the normalized_images collection, and the OCR skill reads printed and handwritten text from those images. Image Analysis describes what a picture shows, and text-only settings have nothing to work on.

1. Recognize scanned files as images with no text layer.
2. Enable image extraction with imageAction.
3. Add the OCR skill over /document/normalized_images/*.
4. Map its text output to a searchable field.

Exam tip: Scans need imageAction plus the OCR skill; Image Analysis describes images, OCR reads them.

OCR output stays in its own node until the Text Merge skill puts it back into the document text.

Image text extracted during enrichment is stored per image under /document/normalized_images/*/text. It's searchable when mapped to its own field, which is why keyword search finds it, but the chunking and embedding skills only read /document/content. The Text Merge skill takes the content, the OCR text and the images' contentOffset values and produces one merged string. Feeding that merged text into Text Split and the embedding skill gets the photo text into the vectors. Output mappings run too late to change what other skills see.

1. Trace which node each downstream skill reads.
2. Notice that OCR output never reaches /document/content.
3. Add Text Merge with text, itemsToInsert and offsets inputs.
4. Point Text Split and embeddings at the merged text.

Exam tip: Downstream skills see OCR text only after Text Merge folds it into the document text.

Billable built-in skills need an attached Foundry resource; a keyless attachment meets a no-keys policy and works across regions.

Built-in skills that call Foundry Tools, such as OCR and Entity Recognition, run free for only 20 documents per indexer per day; after that, billable skills stop and the indexer logs time-outs. The fix is to attach a billable Foundry resource to the skillset. The security policy rules out any key-based attachment, and the classic CognitiveServicesByKey type additionally expects the resource in the search service's region. A keyless attachment through the search service's managed identity (with Cognitive Services User on the Foundry resource) has no region requirement and needs no code. A custom skill also works but means writing and hosting code, and tolerating failures leaves documents unenriched.

1. Recognize the daily stop as the free enrichment allowance running out.
2. Recall that a billable Foundry resource must be attached to the skillset.
3. Check the constraints: no keys, different regions, least effort.
4. Choose the keyless (managed identity) attachment.

Exam tip: Enrichment stalls daily: attach a billable Foundry resource; keyless attachment has no region requirement.

For new skillsets, the Azure Content Understanding skill handles layout-aware extraction and chunking in one step.

The Azure Content Understanding skill extracts text and images, outputs tables and figures as Markdown, recognizes tables that span pages as single units, and chunks the content so no Text Split skill is needed. Microsoft keeps the Document Layout skill for existing pipelines but recommends Content Understanding for new skillsets; Document Layout outputs tables as plain text. Document Extraction has no table handling, and OCR only reads text from images.

1. Note the needs: Markdown tables, cross-page tables, one skill for extraction and chunking.
2. Recall which built-in skill outputs Markdown tables and chunks.
3. Rule out skills that lose table structure.
4. Choose the Content Understanding skill.

Exam tip: New layout-aware pipeline with tables: the Azure Content Understanding skill.