Housing authority QA wants proof that Row-Level Security still filters case rows after each Database Project deploy to test. What should their integration suite assert?

Housing authority QA wants proof that Row-Level Security still filters case rows after each Database Project deploy to test. The integration suite should assert that RLS predicates continue to restrict case visibility for test principals after the project deploys—not merely that the dacpac task returned success. Municipal housing case data is tenant-sensitive; a deploy that drops a predicate, mis-orders security objects, or grants overly broad rights can pass a shallow “deploy OK” check while breaking isolation. RLS-focused assertions encode the security contract DP-800 expects teams to verify when securing database solutions.

Asserting only that the deploy completed, ignoring whether security predicates still apply, fails by measuring pipeline success instead of security outcomes. Disabling RLS in test so integration tests never exercise tenant isolation fails by concept: a test environment that turns off the control cannot detect regressions in the control. Granting db_owner to every test account and skipping predicate checks fails because elevated roles bypass the very filters the suite must prove still work for ordinary caseworker principals.

Exam caveat: after-deploy validation for RLS is about behavioral proof under representative principals, not deployment exit codes. Distractors that disable RLS or elevate testers to owners remove the signal the question is testing.

Operational check: after each housing project deploy to test, connect as at least two principals mapped to different tenancy contexts, select from the case table, and assert each sees only permitted rows. Include a negative case that attempts cross-tenant reads and expects empty or denied results; fail the pipeline if predicates are missing, disabled, or ineffective after publish.