A multi-department RAG app on Azure Database for PostgreSQL must keep HR-adjacent public-records rows scoped by department. What approach fits?
Select an answer to reveal the explanation.
Short Explanation
Row-level security is the badge reader on each department aisle—PostgreSQL only hands RAG the shelves that badge is allowed to see, instead of trusting the chatbot to look away.
Full Explanation
A multi-department RAG app on Azure Database for PostgreSQL that must keep HR-adjacent public-records rows scoped by department needs enforcement in the database, not in the model. PostgreSQL row-level security policies bind each department role to authorized rows so RAG retrieval cannot see out-of-scope municipal records even if a prompt tries to ask for them. Giving every department the same superuser login and relying on the LLM to ignore out-of-scope rows places access control in probabilistic generation instead of the data plane and fails civic isolation requirements. Deleting all department columns so filtering is impossible removes the attributes RLS and application filters need to scope retrieval. Storing department secrets inside embedding vectors instead of using database access controls confuses representation with authorization and does not stop unauthorized SELECT paths. Exam caveat: RLS is complementary to app filters and managed identities; the exam expects the authoritative row scope to live in PostgreSQL for multi-tenant civic RAG. Operationally, define department roles and policies, connect the RAG service with constrained credentials, and verify cross-department prompts return empty or denied results rather than leaked rows.