Index operations and who is allowed to see what

The last card, and the one carrying a correction rather than only facts. Two topics: keeping an index honest over time, and making sure people only see what they are allowed to see.

Change detection is automatic. Deletion detection is not.

That sentence is the whole first half. An indexer notices new and modified documents on its own. It does not notice deletions unless you tell it how.

Two policies:

Native blob soft delete — NativeBlobSoftDeleteDeletionDetectionPolicy. Blob Storage only. It needs blob soft delete switched on and blob versioning switched off, with the document key mapped to a blob property or to metadata.

Soft-delete column — SoftDeleteColumnDeletionDetectionPolicy, with softDeleteColumnName and softDeleteMarkerValue. You flip the marker, the indexer removes the document, and then you delete the file. That order matters: delete the file first and the indexer never sees the marker.

Green status, empty index

Four ways an indexer reports success and indexes nothing:

• Cosmos DB automatic indexing switched off — success, nothing indexed.
• The high-water mark set to a future date — everything earlier is skipped.
• Private-execution misconfiguration — fails silently. This is the card 6 failure again.
• Run caps: 2 hours multitenant, 24 hours private execution.

The habit worth forming: check warnings, not just status. Green means the run completed, not that it did anything.

Document-level security

• Security filters — generally available, plain strings, any push-model index, custom identity systems.
• ACL and RBAC scopes — ADLS Gen2 and Blob, in preview.
• Purview sensitivity labels — preview.
• SharePoint Microsoft 365 ACLs — preview.
• Token header: x-ms-query-source-authorization.

There are two checks, not one. The application needs Search Index Data Reader, and the user's claims must match each document. Both. An application that can read the index does not thereby let its users read everything in it — and an application without that role cannot serve even documents the user is entitled to.

Aliases

A second name for an index, so you can repoint instead of redeploying. Exactly one index per alias. An alias cannot be an indexer's targetIndexName, and cannot be used to delete an index or test tokenization. Updates take up to 10 seconds to propagate.

Where third-party practice tests will lie to you

This is the correction worth publishing, and the reason this card exists.

Popular quiz sites answer the least-privilege inference question with "Cognitive Services OpenAI User". For Foundry that is wrong. Microsoft's documentation says outright not to assign built-in roles beginning with Cognitive Services — they are for AI Services resources directly, not for Foundry.

Azure AI Developer is also ruled out. Despite the name, it is scoped to Azure Machine Learning workspaces and Foundry hubs.

The right answers:

• Foundry User — developers building and testing.
• Foundry Agent Consumer — least privilege, calls agent endpoints only.
• Foundry Owner — the only single role holding both data and control plane, and therefore the only one that can fine-tune and deploy the result.

If you have been revising with a third-party question bank, expect to have been taught the wrong answer confidently.

The trap

The deletion policy must exist from the very first indexer run.

Add it later and everything deleted before that point stays in the index permanently. A reset will not clear it. The only fix is a new index with a new indexer.

That is a genuinely expensive mistake — not a lost mark, but a rebuild — and it is the strongest argument for thinking about index operations at design time rather than after go-live. Which is exactly the seam the original course material left out.