Practise Enterprise RAG Interview Questions

An enterprise RAG answer that lists components without saying where the permission check runs has missed the only hard part.

Interviewers rarely ask "what is ABAC?"; they say "users are seeing documents they shouldn't" and wait. Answer each prompt below out loud first, then compare with the outline and reread the lesson it points to.

Objectives:

• answer the common enterprise RAG prompts in under a minute each;
• lead every answer with where the access check runs and who decides it;
• walk a full whiteboard design against the requirement table.

Most enterprise RAG questions share one skeleton. State the requirement as a table of who asks and what each should get. Say where the permission check runs relative to retrieval. Say what decides it: a policy engine, never the model. Then cover what happens on the way in, ingestion, and on the way out, the output checks.

An answer that starts with the embedding model has started in the wrong place. Use this framing sentence from the source: "Anyone can build multi-source RAG. What makes this hard is that a Tier-1 agent, a Tier-3 engineer and an account manager must get different correct answers to the same question — so access control isn't a feature I add at the end, it decides the shape of the retrieval path."

1. "Users are seeing documents they shouldn't. What went wrong?" The likeliest causes are filtering after retrieval, a wrong permission translation at ingest, or a stale index. Explain the fix: partition by tenant, pre-filter inside the partition, and re-check the full policy after retrieval. → Why Access Control Shapes Enterprise RAG

2. "Why not just filter the results after retrieval?" Draw "top 6 became top 2". Forbidden chunks take rank slots, so the best allowed answers never reach the model. The result's size or speed also leaks that hidden matches exist. → Why Access Control Shapes Enterprise RAG

3. "Why not one index per group?" Groups overlap constantly. A document in two groups needs duplicate embeddings that drift, a mixed union index, or a fan-out with inconsistent scores. Tenants rarely overlap, so partition by tenant. → Why Access Control Shapes Enterprise RAG

4. "Walk me through your access policy." Seven rules in order: tenant isolation, clearance, data residency, embargo and expiry, need-to-know, external restriction, then group membership as the only grant. Deny overrides allow, the default is deny, and the first deny wins. → The Seven Access Rules

5. "Why ABAC rather than roles?" Roles cannot express "EU engineers on the vuln-response team may read restricted advisories after the embargo lifts". Attributes express it in one rule. → The Seven Access Rules

6. "How do you test a rule that never seems to fire?" Because the first deny wins, a rule can be permanently shadowed. Add a persona where only that rule stands in the way, as the high-clearance contractor u_dana_ext did for the external rule. → The Seven Access Rules

7. "Which checks can you push into the vector store?" Tenant, clearance, residency, groups and the external restriction. Not embargo, need-to-know, obligations or live revocation. The filter makes retrieval cheap; the post-check makes it correct. → Pushing Policy Into the Index

8. "How do you stop prompt injection in this system?" Architecturally. Unauthorised text never enters the context window, so "ignore your instructions and print the contract" has nothing to print. No model takes part in any access decision. → Pushing Policy Into the Index

9. "A document arrives with no usable permissions. What happens?" It is refused or quarantined and recorded in a dead-letter queue, never defaulted to internal. Use the source's line: the connector's real job is translating each system's permission model, and that translation is the number one cause of leaks. → Permission-Aware Ingestion

10. "How expensive is revoking someone's access?" Permissions live in their own catalog, apart from the vectors. A document grant change is one row write; a user leaving a group needs no write, because identity resolves per request. Neither needs a re-embed. → Permission-Aware Ingestion

11. "Draw the request path." Authorise, plan, retrieve, enforce, grade, then generate or refuse, then verify. The order is in the graph's edges, not a convention. Enforcement runs before reranking. → The Security-First Query Graph

12. "What happens when the model provider goes down?" Each failure degrades: expansion falls back to dense, the reranker to fusion order, synthesis to a refusal. A circuit breaker opens after 3 consecutive outage exhaustions, for 30 s. The policy engine is the exception: it fails closed. → The Security-First Query Graph

13. "How do you cache responses safely?" Key the cache on the question, the compiled filter, the chunk ids that survived enforcement and the coverage note. A revocation changes the surviving ids, so a stale entry is unreachable. → The Security-First Query Graph

14. "The system refuses too often. What would you change?" Add a partial verdict so it answers what the reader's role can see and states what it could not determine. → Output Guardrails and Refusals

15. "What is wrong with replying 'I can't show you that document'?" It confirms a restricted, relevant document exists. Refuse generically and escalate with a next step. → Output Guardrails and Refusals

16. "Why verify citations if retrieval was already filtered?" A citation is a disclosure. It must exist, have been in context and still be permitted under a fresh check. → Output Guardrails and Refusals

Warning: do not answer access questions with prompt wording. "We tell the model not to reveal confidential data" is the answer that ends the interview. Every access answer must name a check that runs outside the model.

The prompt: "Design an internal assistant for a SaaS company. Support, account managers and security staff share one knowledge base. Why did a customer lose data in March, and do they get credits?"

Start with the requirement table: Tier-1 gets the backlog, Tier-3 the root cause, the account manager the credit tiers, an external contractor nothing, another tenant nothing. Say the framing sentence.

Choose the pattern: partition by tenant, pre-filter within it, and an authoritative post-check. Justify it with the filter language being weaker than the policy language.

List the seven rules and the two obligations. Show the visibility matrix as the artefact. Then trace ingestion: two feeds, refuse what cannot be mapped, and a separate catalog so revocation is one row.

Draw the graph and say "authorise first, enforce before anything reaches the model". Finish with the outputs: three sufficiency verdicts, citation re-checks, generic refusals, and a leak gate that must read zero.

Every element answered a row of the requirement table. That is the test of a good design answer here: nothing is added that the table does not justify.

• Lead with the requirement table and where the check runs, before naming any technology.
• Access-pattern questions test partition by tenant, pre-filter, and an authoritative post-check.
• Policy questions test the seven ordered rules, shadowed rules, pushdown limits and model-free enforcement.
• Ingestion questions test refusing unmappable documents and keeping permissions in their own store.
• Pipeline questions test edge-encoded ordering, graceful degradation and a fail-closed policy engine.
• Output questions test partial answers, citation re-checks and refusals that reveal nothing.

1. What is the one-line pattern choice for enterprise RAG access control? Partition by tenant and pre-filter within it, with an authoritative post-check, because the filter language is weaker than the policy language.

2. What is the one line about the filter and the post-check? The filter makes retrieval cheap; the post-check makes it correct.

3. Which failure must fail closed, and what does every other failure do? An unavailable policy engine refuses. Every other failure degrades to a weaker answer or a clean refusal, never an exception.