A dynamic row-level security role on a "semantic model" maps each user to their permitted regions through a bridge table that holds one row per user and region. The model owner wants to confirm that a specific manager sees only their two regions before publishing the change to consumers. What is the appropriate way to validate the role's effect?
- APublish the model to production first, then ask the manager to open a report and confirm that only their two regions appear in the visuals.
- BRemove the dynamic filter temporarily and count the distinct regions returned, assuming the role works if the unfiltered total exceeds two for the manager.
- CGrant the manager Admin on the workspace so they can inspect the role definition and self-verify that the mapping bridge lists exactly two regions.
- DUse the View As capability to impersonate the manager's role and account, then check that queries against the model return only their two permitted regions. Correct
Why A is wrong: Validating in production exposes consumers to an unverified policy, and relying on a user's confirmation is slower and riskier than testing the role before publishing.
Why B is wrong: Counting regions with the filter removed tests nothing about the role, since disabling the predicate cannot demonstrate that it would scope the manager to two regions.
Why C is wrong: Granting Admin over-privileges the manager and inspecting the mapping does not prove the runtime filter behaviour, so it neither validates safely nor tests the effect.
Why D is correct: View As lets the owner impersonate a role and a specific user so the dynamic filter resolves as it would for that manager, confirming the two regions before any publish.