In this post we are going to cover access, roles and self-service requests in Microsoft Purview: who can do what inside Purview, and how people ask for access to data. These are 7 real Purview interview questions, asked the way they come up on a real project, and the last one is a scenario where an auditor finds that a contractor still had access to customer data three months after leaving.
Purview has its own roles, for the people who run scans, curate assets and own data products. It also runs access requests, where an analyst asks for data and approvers say yes or no. Interviewers ask about this because it is where most permission tickets come from, and because many people think Purview grants access to the data itself. It doesn't, and saying that clearly is a big part of a good answer.
Part 7 of the Real Time Microsoft Purview Interview Questions and Answers series on TechBrothersIT.
- The short answer
- Question 1: A data steward can see assets in the catalog but cannot edit the domain. How do Data Map roles and Unified Catalog roles differ?
- Question 2: Your Data Map has collections by business unit. What are domains and collections, and who should be a collection admin?
- Question 3: A new data product owner can't add assets to the product. Which two permissions does she need?
- Question 4: An analyst requests read access to the Sales data product. What happens in Purview, and who actually grants the access?
- Question 5: Your security lead asks you to use Purview data owner policies to manage SQL access. What do you tell her?
- Question 6: Compliance requires a privacy review before anyone gets HR data. How do you build that into the access workflow?
- Scenario 7: An auditor finds a contractor still had access to customer data three months after leaving. What should the process have been, and what part is Purview's job?
The short answer
Purview has two role systems: Data Map roles on domains and collections for sources, scans and assets, and Unified Catalog roles on governance domains for data products and business concepts. Access requests run through Purview's approval workflow, but access is granted and enforced at the source. Classic SQL access policies retire on October 30, 2027.
Keep that in mind. Every question below is one piece of it.
Question 1: A data steward can see assets in the catalog but cannot edit the domain. How do Data Map roles and Unified Catalog roles differ?
Purview has two separate sets of roles. Data Map roles control the technical side, and Unified Catalog roles control the business side.
| Data Map roles | Unified Catalog roles | |
|---|---|---|
| SCOPE | Data Map domain, collection | catalog, governance domain |
| CONTROLS | sources, scans, assets | domains, products, terms, OKRs, CDEs, health |
| EXAMPLES | Collection admin, Data curator, Data reader | Domain Owner, Data Product Owner, Data Steward |
| ASSIGNED IN | the domain or collection | Unified Catalog settings, domain Roles tab |
Data Map roles sit on Data Map domains and collections, and they cover sources, scans and assets. Unified Catalog roles sit at the catalog level or on a governance domain, and they cover domains, data products, glossary terms, OKRs, critical data elements and health.
Now let's look at our steward. She probably has Data reader on the collection, which is why she sees assets. The Data Steward role lets her create and update terms, OKRs and CDEs in the domain. But the domain's roles and its domain-level access policies belong to the Governance Domain Owner.
Where do you assign them? Catalog-level roles, like Data Governance Administrator and Governance Domain Creator, are assigned in the Unified Catalog settings. Domain roles are assigned on the domain's Roles tab.
Most tasks need one role from each side. Remember that, and half of your permission tickets go away.
Question 2: Your Data Map has collections by business unit. What are domains and collections, and who should be a collection admin?
A Data Map domain is the top-level container, and collections sit inside it in a tree.
Let's start at the top. You get a default domain, plus up to four custom domains, for hard separation, like a subsidiary that is administered on its own. When you upgrade, the root collection becomes the default domain.
Then the collections. Here they are Sales, Finance and HR. Collections organize sources, scans and assets, and they are the main unit of access control. Permissions inherit from parent to child.
For a sensitive business unit like HR, turn on restrict inherited permissions. That removes inherited members from every role except Collection admin.
So who should be a collection admin? Collection admins assign roles, so keep it small:
- Collection admin: a few people per business unit, like the governance lead and a platform engineer.
- Data reader, curator and source admin: everyone else, through Entra security groups.
Data Map domains are technical boundaries. Governance domains in Unified Catalog are business boundaries for data products.
Question 3: A new data product owner can't add assets to the product. Which two permissions does she need?
She needs one role on each side: Data Product Owner in Unified Catalog, and Data reader in the Data Map.
First, the Data Product Owner role on the governance domain. There is no separate role scope for a single data product, so it is assigned at the domain level.
Second, read permission in the Data Map: Data reader on the collection that holds the assets. When she adds assets, she is searching the Data Map from inside the product, and that search only shows assets she can see there.
This is one of the most common tickets in a new rollout. The Unified Catalog role looks right, but the asset search comes back empty, because the Data Map role is missing.
If both roles are in place, here are two more checks:
- The product is in Draft. A data product can only be edited while it's in Draft.
- The assets are already scanned into the Data Map, in a collection she can read.
When the asset search is empty for a new owner, check the Data Map side first.
Question 4: An analyst requests read access to the Sales data product. What happens in Purview, and who actually grants the access?
Purview runs the request and approval workflow. The access itself is granted at the source, by a person.
Let's follow the request step by step. The analyst opens the data product, selects Request access, and fills in the form: the purpose, any attestations, and the terms of use. She sends it and tracks it under My data access.
Then Purview runs the approval chain from the product's access policy, in a fixed order:
- Manager
- Privacy reviewer
- Approvers
- Access provider
Only the steps the policy turns on are used, and the first denial stops it.
Now the key point. Purview doesn't grant the access. An approver, or the access provider, grants it at the source, like a Fabric workspace role, a SQL database role or a storage permission, and records it in Purview. So the status moves from Pending, to Approved while provisioning is still open, to Completed. A denied request ends as Declined.
Purview runs the workflow. The source enforces the access. Attestations, like no copies, are not enforced by Purview.
Question 5: Your security lead asks you to use Purview data owner policies to manage SQL access. What do you tell her?
I would tell her not to build anything new on them. Purview access policies for SQL, meaning DevOps policies, data owner policies and self-service policies, are classic features, and they retire on October 30, 2027.
That covers Azure SQL Database, SQL Managed Instance and Arc-enabled SQL Server 2022. After that date, SQL stops enforcing them and removes the access they granted.
| Purview SQL access policies | SQL native authorization | |
|---|---|---|
| STATUS | classic, retire Oct 30, 2027 | current, the replacement |
| TYPES | DevOps, data owner, self-service | Entra groups, database roles, server roles |
| AFTER OCT 30, 2027 | not enforced, access removed | unchanged |
So plan the move now, not in 2027. Instead, use SQL's own authorization: Entra groups added as database users, database roles, and the built-in server roles that replace the DevOps policies. Row-level security and masking come from SQL too.
Here is what that looks like for a sales readers group:
-- SQL native: an Entra group as a database user
CREATE USER [sg-sales-readers] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [sg-sales-readers];Also, the label-based protection policies no longer support Azure SQL Database.
Purview discovers, classifies, catalogs and runs the access request. SQL enforces it.
Question 6: Compliance requires a privacy review before anyone gets HR data. How do you build that into the access workflow?
Set it once, on the HR governance domain's access policy, with privacy review turned on.
Policies on a governance domain, a glossary term or a critical data element are added to every data product under them. So every HR data product inherits the review, and you see it on the Inherited policies tab.
The order is fixed: the manager from Entra ID approves first, then the privacy reviewer, then the approvers, then the access provider, who grants at the source. The first denial stops the request.
Now one detail interviewers like. With the access policy, the requester names the privacy reviewer on the form. So let's tighten it:
- Add the privacy team's security group as approvers, so the privacy office always signs off.
- Add an attestation and terms of use, and narrow the permitted purposes.
For more control, build a data product access workflow in the new workflow experience, where you can fix the privacy approver and email the privacy office.
The access workflow takes user principals only and mail-enabled security groups, and it has no external connectors.
Scenario 7: An auditor finds a contractor still had access to customer data three months after leaving. What should the process have been, and what part is Purview's job?
Let's walk through what the process should have been, in four steps.
- Grant through Entra security groups. Access should never go to individual people. The approver grants it at the source through an Entra security group, so one leaver action removes everything.
- Leaver process. The contract ends, the Entra account is disabled on the last day, and the contractor is removed from groups. That is identity, not Purview.
- Revoke in two steps. Remove the access at the source, then delete the completed request in Unified Catalog. Only the data product owner can delete a completed request, after the access is removed.
- Access reviews. Run regular reviews on those groups and on each product's approved requests, and keep the trail of who requested, who approved and why.
So what is Purview's job? Knowing where customer data lives, who owns it, and who asked for access with what approval. Entra and the source decide who actually gets in.
Purview records it. Entra and the source enforce it. That is exactly what the auditor wants to hear.
Key points to remember
- Data Map roles: sources, scans, assets. Unified Catalog roles: domains, products
- Collections inherit; restrict inheritance for HR
- Add assets: Data Product Owner plus Data reader
- Purview approves; access is granted at the source
- Classic SQL access policies retire Oct 30, 2027
Part 8: Sensitivity Labels and Information Protection
Part of the Real Time Microsoft Purview Interview Questions and Answers series on TechBrothersIT. Product names, features and their status (GA or preview) are current as of October 2026. Microsoft changes Purview every month, so 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.