DP-600 · Analytics Security and Governance
19 cards
Granular Data Access Controls
-
Quick check
Fabric has already authenticated a user and confirmed Fabric access. What does the data-security stage decide?
AWhich workspace the user belongs to
Workspace membership is settled earlier and says nothing about a specific table or file.
BWhether the user's Microsoft Entra ID sign-in has succeeded and can be trusted
Sign-in is the first stage, Microsoft Entra ID authentication, and it has already happened by this point.
CWhether the user can perform the requested action on a table or file
Right. This stage checks whether the requested action is allowed on the table or file in question.
2 / 19
-
Quick check
Users query lakehouse data with T-SQL through the SQL analytics endpoint, and granular permissions must be applied there. What do you use?
AA OneLake security role, enforced across every engine
OneLake roles are the cross-engine route; here the restriction belongs specifically to the SQL analytics endpoint.
BT-SQL permissions, with GRANT and DENY
Right. T-SQL permissions are the compute permissions for the SQL analytics endpoint, applied with Data Control Language commands.
CA workspace role that covers the whole workspace
A workspace role applies to every item in the workspace, which is far broader than endpoint granularity.
4 / 19
-
Quick check
An analyst querying through the SQL analytics endpoint must see only the patient records assigned to their unit. Which control fits?
ARow-level security, applied through T-SQL for that endpoint's access
Right. Restricting which records a SQL user can access is exactly what row-level security decides.
BColumn-level security, applied through T-SQL
Column-level security restricts which fields are visible, not which records are returned.
CRead item permission on the lakehouse
Read item permission exposes the item and its reports, and grants no underlying data access by default.
7 / 19
-
Keep your progress in the app
That’s 3 of 8 quick checks. In the app they stay answered, and every lesson remembers where you left off.
-
Quick check
A Viewer must be blocked from confidential columns through Spark, SQL, and the OneLake APIs alike. What do you configure?
AA OneLake security role with a row filter
A row filter decides which records are returned; it does not hide the confidential columns.
BA OneLake security role with a column filter in its constraints
Right. A column filter in the role's constraints is enforced across all three of the engines named in the requirement.
CA Member workspace role, whose full data access covers every engine
Member already holds full read and write access to OneLake data and is not restricted by a OneLake role.
9 / 19
-
Quick check
A Viewer must read the files in one folder through Spark and the OneLake APIs, without being able to edit them. How do you define the role?
ASelect the folder, and set Permission to ReadWrite
ReadWrite allows viewing and editing, which goes beyond the view-only requirement.
BSelect a table instead, and set Permission to Read
A table selection grants the wrong data scope when the requirement names a folder of files.
CSelect the folder, with Permission Read
Right. The Data component selects the folder and the Permission component is Read for view-only access.
12 / 19
-
Quick check
A OneLake role carries a row constraint, yet a user who is a workspace Contributor still reads every row. Why?
AAdmin, Member, and Contributor already hold full read and write access to OneLake data, which a OneLake role does not restrict
Right. Those three workspace roles already have full OneLake data access, and a custom role cannot narrow it.
BRow constraints are enforced only through Spark
OneLake roles are enforced across Spark, SQL, and OneLake APIs, so the engine is not the explanation.
CThe role should have used ReadWrite
ReadWrite would widen the role's permission to editing; it would not make the constraint bite.
14 / 19
-
Quick check
A Viewer was shared a lakehouse with Read all Apache Spark and subscribe to events, then added to a narrow custom folder role. The user still reads every file. What do you do?
AChange the custom role to ReadWrite
ReadWrite widens the custom role rather than closing the wider path the user already has.
BReplace the folder selection in the custom role with a table selection
Changing the selected data scope narrows the custom role but leaves DefaultReader untouched.
CRemove the user from the DefaultReader role
Right. That sharing permission added the user to DefaultReader, which keeps read access to all data until the membership is removed.
17 / 19
-
Quick check
Which summary keeps the two granular routes and their limits straight?
AUse OneLake roles for the SQL endpoint and T-SQL for Spark, and trust a custom role to restrict everyone
The two routes are swapped, and a custom role cannot restrict Admin, Member, or Contributor access.
BUse T-SQL row-level and column-level security for the SQL analytics endpoint, use a OneLake role when the restriction must hold across Spark, SQL, and the OneLake APIs, and remember that Admins, Members, and Contributors are not restricted by it
Right. T-SQL for the endpoint, a OneLake role for cross-engine consistency, and higher workspace roles outside the reach of both.
CUse T-SQL for every engine, and rely on DefaultReader to narrow a Viewer's access
T-SQL permissions are compute permissions for the SQL endpoint, and DefaultReader widens access rather than narrowing it.
19 / 19
-
8 quick checks · then the test
In the app, finishing the quick checks opens this lesson’s 10-question test, and the ones you miss come back exactly when you’re about to forget them.
The whole course, on your phone
Lessons you can read, audio you can listen to on the way to work, and practice that remembers what you got wrong.