Implementing Document-Level Security Filtering in Azure AI Search
Short answer
AEF Tag each index entry with allowed groups, look up the querying user's group memberships, and pass them as an OData filter on every search request.
Question
You need to implement document-level filtering for Azure AI Search.
Which three actions should you include in the solution? Each correct answer presents part of the solution.
NOTE: Each correct selection is worth one point.
Key Takeaways
The test targets the tag–resolve–filter security trimming pattern; the trap is assuming that authenticating with a Microsoft Entra ID token performs the filtering automatically.
Azure AI Search document-level security is implemented by tagging each indexed document with allowed security groups, resolving the requesting user's memberships, and injecting them as an OData filter (options A, E and F).
Common mistake: Option C is the most tempting error: sending an Entra ID access token authenticates the request to the search service but performs no document-level trimming, so documents still must be filtered by a group-based OData filter.
Expert Analysis
The governing pattern: tag, resolve, filter
Azure AI Search implements document-level security (also called security trimming) through a three-step pattern documented in the service's access-control guidance. First, every indexed document or chunk carries a filterable field that lists the security principals — typically Microsoft Entra ID group object IDs — authorized to read it. Second, at query time the application resolves the signed-in user's group memberships. Third, those memberships are injected into the query as an OData filter, so unauthorized documents never enter the result set. Those three steps map directly onto options A, E and F.
Why A, E and F are correct
Option A is the indexing half: each index entry is stamped with the allowed groups in a field of type Edm.String with IsFilterable: true, often populated by a Security Group Enrichment skill against Microsoft Entra ID. Option E is the resolution half: the app must look up the actual group memberships of the user issuing the query rather than assuming anything. Option F is the enforcement half: an OData filter such as groups/any(g: search.in(g, '<ids>')) or a search.in clause over the stored group field is sent with every search request.
Why the distractors fail
Option B, one index per group, technically scales but multiplies index quota, indexer overhead and management effort; it is explicitly discouraged in favour of a single index with a security field. Option D, retrieving all groups, gives the client nothing usable — the filter must reflect the requesting user's memberships, not the directory's full group list. Option C is the trap: an Entra ID access token authenticates the caller to the search service, but authentication alone does no document-level trimming. Even token-authenticated requests must carry the group filter. Community analysis reaches the same conclusion, describing the flow as tagging documents, retrieving the user's memberships, and supplying them as a filter.
Official Reference
https://learn.microsoft.com/azure/search/document-level-access-control
This link opens the official vendor documentation in a new tab.
Exam Strategy
When a question describes restricting which documents a user can see, ignore authentication options and look for the three-part trimming pattern: an indexed security field, a lookup of the user's memberships, and a filter applied at query time. Eliminate any option that scales by creating per-group indexes or that retrieves the whole directory's groups, since neither reflects the requesting user's permissions.
Frequently Asked Questions
Does sending a Microsoft Entra ID token enable document-level filtering in Azure AI Search?
Why not create a separate Azure AI Search index per security group?
How is the group filter usually expressed in a search query?
Community Votes
34% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 2 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 2
-
8ac3742 👍 1Why the Answer is About "Groups" When the Question Says "Document-Level Filtering" In Azure AI Search, "document-level filtering" (officially called Security Filters or Document-level Security) means: When a user runs a search query, they should only see the specific documents they have permission to view, and documents they are not authorized to view must never appear in the search results. Azure AI Search does not integrate with Microsoft Entra ID permissions at the individual document level automatically. Instead, security trimming is implemented using security groups as document metadata: A. Add allowed groups to each index entry E. Retrieve the group memberships of the user F. Supply the groups as a filter for the search requests
-
Srikantha 👍 1Add allowed groups to each index entry: Tag documents or index chunks with a security field specifying which groups have access rights. Retrieve the group memberships of the user: Identify the active security groups or permissions belonging to the user executing the search query. Supply the groups as a filter for the search requests: Apply an OData filter (such as using search.in or collection operators) containing the user's groups to restrict the search results to only authorized content.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All AI-103 Questions
Access 88 questions with complete answers and detailed explanations.
View Full AI-103 Practice Test →