In this post we are going to cover security, governance and CI/CD in Microsoft Fabric: who can see what, how rows and columns are protected, how the network is locked down, and how changes move from dev to production. These are 7 real Microsoft Fabric interview questions, asked the way they come up on a real project, and the last one is a scenario where an auditor asks how your Fabric platform is secured and how changes reach production.
Security in Fabric works in layers. Workspace roles decide who works in a workspace, item permissions and OneLake security decide who reads which data, network settings decide where traffic can go, and Git plus deployment pipelines decide how a change gets to prod. Interviewers ask about it because every real project hits these questions in the first month, usually when a contractor, an HR table or an auditor shows up.
Part 9 of the Real Time Microsoft Fabric Interview Questions and Answers series on TechBrothersIT.
- The short answer
- Question 1: A contractor should see one lakehouse table but nothing else in the workspace. How do workspace roles and item permissions work?
- Question 2: HR data must be restricted by row and column for some users. How does OneLake security work, and where is it enforced?
- Question 3: Analysts query through the SQL analytics endpoint and the warehouse. How do GRANT, row-level security and column-level security work there?
- Question 4: The security team wants no public internet access to the data. What are private links and outbound access protection in Fabric?
- Question 5: Three engineers work on the same workspace and overwrite each other. How does Git integration work in Fabric?
- Question 6: You need to promote changes from dev to test to prod with different connections. How do deployment pipelines, deployment rules and variable libraries work?
- Scenario 7: An auditor asks how your Fabric platform is secured and how changes reach production. What do you show?
The short answer
Workspace roles cover every item; share single items for narrow access. OneLake security adds table, row and column rules enforced across engines, and the warehouse uses T-SQL GRANT, RLS and CLS. Network: Private Link inbound, outbound access protection outbound. Changes flow through Git and deployment pipelines with rules and variable libraries.
Keep that in mind. Every question below is one piece of it.
Question 1: A contractor should see one lakehouse table but nothing else in the workspace. How do workspace roles and item permissions work?
Workspace roles are the wrong tool here. Admin, Member, Contributor and Viewer all apply to every item in the workspace.
Let's look at what each role gives you:
| Workspace role | Sees | Data access | Manages access |
|---|---|---|---|
| ADMIN | every item | read and write all | yes |
| MEMBER | every item | read and write all | adds members |
| CONTRIBUTOR | every item | read and write all | no |
| VIEWER | every item | SQL read, no Spark | no |
Contributor and above can read and write all the data. Even a Viewer sees every item and can query it through SQL. So none of these fit a contractor who should see one table.
Here is how we do it instead, step by step:
- No workspace role. The contractor gets nothing at the workspace level.
- Share only the lakehouse, with Read. Read lets them connect and see metadata, but no data yet.
- Grant the data with OneLake security. Create a role that contains just that one table, and add the contractor to it. These roles apply to Viewers and to users with item Read, which is exactly this case. If they query through SQL, the endpoint must be in user identity mode.
One more thing in the share dialog: don't tick the Read all boxes. They open up far more than one table.
Making the contractor a Contributor to unblock them. That is read and write on everything. Use an Entra group, and remove it when the contract ends.
Question 2: HR data must be restricted by row and column for some users. How does OneLake security work, and where is it enforced?
OneLake security is role-based access on the data itself. It replaced the older OneLake data access roles and became generally available in May 2026. A role gives Read or ReadWrite on tables, folders or schemas.
Let's build it for HR. We create one Read role per department on the employee table. For Sales it looks like this:
- Role - Sales managers, Read
- Scope - the employee table
- Row filter - department = Sales (a fixed value)
- Hidden columns - salary, bank details
- Members - an Entra group of Sales managers
A few rules to know. Row filters use fixed values, not the user's name. A ReadWrite role can't carry row or column rules. And Microsoft recommends a schema-enabled lakehouse.
Roles are grant only, and access is denied by default. They apply only to Viewers and users with item Read. Admins, Members and Contributors already have full data access, so the roles don't touch them.
Now where it is enforced. It works across engines:
| Engine | Enforced |
|---|---|
| LAKEHOUSE | GA |
| SPARK NOTEBOOKS | GA |
| DIRECT LAKE ON ONELAKE | GA |
| SQL ENDPOINT, USER IDENTITY | GA |
| EVENTHOUSE (RLS ONLY) | preview |
The SQL analytics endpoint only enforces it in user identity mode, and Eventhouse support is still in preview.
Test with a real Viewer account. Engineers test as Contributors, see everything, and never notice the role doesn't apply to them.
Question 3: Analysts query through the SQL analytics endpoint and the warehouse. How do GRANT, row-level security and column-level security work there?
First Read on the item, then T-SQL does the rest. To connect at all, a user needs at least the Read permission on the item.
After that, T-SQL controls access:
- GRANT, DENY and REVOKE on objects.
- Column-level security with GRANT SELECT on a column list.
- Row-level security with a security policy.
- Dynamic data masking.
Let's look at an example on the employee table:
-- column-level security: no salary column
GRANT SELECT ON dbo.employee
(employee_id, full_name, department) TO [HR Analysts];
GO
-- row-level security: managers see their own team
CREATE SCHEMA sec;
GO
CREATE FUNCTION sec.fn_team(@manager_upn AS varchar(100))
RETURNS TABLE WITH SCHEMABINDING
AS RETURN SELECT 1 AS ok WHERE @manager_upn = USER_NAME();
GO
CREATE SECURITY POLICY sec.team_filter
ADD FILTER PREDICATE sec.fn_team(manager_upn)
ON dbo.employee WITH (STATE = ON);The first statement is column-level security: HR Analysts can select every column except salary. Then row-level security is a predicate function plus a security policy. The function returns a row only when the manager column matches the user's name, and the policy applies it as a filter on the employee table.
Now, where does this apply? It depends on where you are:
| Where | SQL security |
|---|---|
| WAREHOUSE | GRANT, RLS, CLS, masking |
| ENDPOINT, DELEGATED | GRANT, RLS, CLS, masking |
| ENDPOINT, USER IDENTITY | OneLake security on tables |
In the warehouse, all of it applies fully, because the warehouse doesn't use OneLake security roles. On the SQL analytics endpoint, it depends on the mode. In delegated identity mode, SQL security applies. In user identity mode, tables follow OneLake security only, GRANT on tables is ignored, and masking isn't supported.
Switching the mode interrupts every SQL endpoint in the workspace, so plan it. And SQL row-level security on a table makes Direct Lake on the SQL endpoint fall back to DirectQuery.
Question 4: The security team wants no public internet access to the data. What are private links and outbound access protection in Fabric?
Split it into inbound and outbound. Inbound is who can reach Fabric. Outbound is where Fabric can send data.
Let's start with inbound:
- Tenant Private Link - with the Block Public Internet Access setting, all access goes through private endpoints in your virtual network. It secures inbound traffic only, and it doesn't work on a trial capacity.
- Workspace private link - locks down a single workspace, for a narrower scope.
- Workspace IP firewall - allows only listed address ranges.
Then outbound:
- Outbound protection - workspace outbound access protection blocks all outbound traffic by default. Then you allow exceptions.
- Managed private endpoints - the exception for Spark and OneLake shortcuts.
- Data connection rules - the exception for Data Factory and mirroring.
Outbound access protection needs an F SKU, not a trial, and support differs by workload, so check the workload you care about.
What about a storage account behind a firewall? For firewall-protected ADLS Gen2, use trusted workspace access with the workspace identity, instead of opening the firewall.
With a managed virtual network, starter pools aren't available, so Spark sessions take minutes to start. Tell the team before they call it a bug.
Question 5: Three engineers work on the same workspace and overwrite each other. How does Git integration work in Fabric?
Git integration connects a workspace to a branch in Azure DevOps or GitHub. Items like notebooks, pipelines, lakehouses and environments are saved as files in the repo. You commit your changes, or update the workspace from the branch.
So why do they overwrite each other? Because three people edit the same items in one shared workspace. The fix is isolation.
Here is the flow, in order:
- Each engineer works in their own workspace, on their own feature branch. Branch workspaces make this easy, and they became generally available in September 2026.
- When a feature is done, they open a pull request into main.
- Reviews and merge conflicts are handled in Git, not by overwriting each other in Fabric.
- Then the shared dev workspace updates from main.
Now know the limits, because interviewers like them:
- Only a workspace Admin can connect a workspace to Git.
- For a lakehouse, Git tracks the metadata only. The table data is never committed.
- My workspace can't connect to Git at all.
It is not "be careful". It is one workspace and one branch per engineer, and main as the only way into the shared workspace.
Question 6: You need to promote changes from dev to test to prod with different connections. How do deployment pipelines, deployment rules and variable libraries work?
A deployment pipeline moves items between stages, and rules and variable libraries handle what is different in each stage.
First, the pipeline. It has two to ten stages, usually dev, test and prod, and each stage is one workspace. Items are paired across stages, so you can compare them, deploy everything or only selected items, and see the deployment history.
Then the differences. Deployment rules handle them, and you set them on the target stage:
| Item | Deployment rule |
|---|---|
| SEMANTIC MODEL | data source, parameter |
| NOTEBOOK | default lakehouse |
| MIRRORED DATABASE | data source |
A data source rule can only switch to a source of the same type.
For everything else, use a variable library. It is a workspace item with variables and value sets, with one active value set per stage:
| Variable | Dev | Test | Prod |
|---|---|---|---|
| server | dev-sql | test-sql | prod-sql |
| lakehouse | lh_dev | lh_test | lh_prod |
| send_alerts | false | false | true |
Variables can be text, numbers, or references to items and connections. Pipelines, notebooks, shortcuts, Dataflow Gen2 and copy jobs read them. So the same notebook points at lh_dev in dev and lh_prod in prod, and only prod sends alerts.
Many teams go code-first instead: they deploy from the Git repo with the fabric-cicd Python library, run from Azure DevOps or GitHub Actions with a service principal. Microsoft officially supports it now.
Nobody edits prod by hand.
Scenario 7: An auditor asks how your Fabric platform is secured and how changes reach production. What do you show?
I walk the auditor through five layers, and for each one I show evidence, not slides.
Here is the whole picture first:
| Layer | What I show the auditor |
|---|---|
| IDENTITY | Entra groups in workspace roles, few Admins, least-permission sharing |
| DATA | OneLake security rows and columns, SQL security, sensitivity labels, DLP |
| NETWORK | Private Link, IP firewall rules, outbound protection, customer-managed keys |
| AUDIT | Purview Audit, SQL audit logs, domains and the OneLake catalog |
| CHANGE | reviewed pull requests, deployment pipeline or fabric-cicd, history |
Now let's go through it in order:
- Identity and access. Entra groups in workspace roles, very few Admins, and items shared with the least permission.
- Data protection. OneLake security roles with row and column rules, SQL security in the warehouse, and Purview sensitivity labels on Fabric items, with data loss prevention policies on top.
- Network. Private Link, workspace IP firewall rules and outbound access protection, plus customer-managed keys where they are required.
- Audit. Purview Audit records Fabric activities, and warehouse and SQL endpoint audit logs go to Purview too. Domains and the OneLake catalog show who owns what.
- Change control. Every change goes through a reviewed pull request in Git, then a deployment pipeline or fabric-cicd with a service principal. The deployment history shows who promoted what, and when.
So the change path is simple: a pull request reviewed in Git, a deployment run by a service principal, and production with no manual edits. Nobody edits production directly.
Bring the role lists, the policies, the pull request history and the deployment history. That is what an auditor actually checks.
Key points to remember
- Workspace roles cover every item; share one item for narrow access
- OneLake security: table, row and column rules across engines
- Warehouse: T-SQL GRANT, RLS, CLS; endpoint depends on the mode
- Private Link inbound, outbound access protection outbound
- Git per engineer, deployment pipelines, rules, variable libraries
Part 10: Real-World Manager Scenarios
Part of the Real Time Microsoft Fabric Interview Questions and Answers series on TechBrothersIT. Features, limits and their status (GA or preview) are current as of October 2026; check the Microsoft Learn page for anything you quote in an interview.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.