In this post we are going to cover the Purview Data Map, scans and integration runtimes: how metadata gets into Purview, what permissions a scan needs, and how Purview reaches sources behind firewalls and private endpoints. 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 a scan says succeeded but users can't find half the tables.
The Data Map is where Purview keeps the technical metadata about your sources. A scan is the job that reads a source and fills it. An integration runtime is the compute that runs the scan. Interviewers love this topic because it is where projects actually break: a permission is missing, a firewall blocks the scan, or the assets just don't show up.
Part 2 of the Real Time Microsoft Purview Interview Questions and Answers series on TechBrothersIT.
- The short answer
- Question 1: You join a project where nobody knows what data exists across Azure SQL, ADLS and Snowflake. What is the Purview Data Map, and how do you start filling it?
- Question 2: A scan of ADLS Gen2 fails with a permission error. What does the Purview managed identity need, and what else do you check?
- Question 3: Your Azure SQL scan returns databases but no tables, and lineage is empty. What permissions and network settings are missing?
- Question 4: The on-premises SQL Server and Oracle databases are behind the firewall. Which integration runtime do you use, and how do the integration runtime types differ?
- Question 5: The storage account has public access turned off and only private endpoints. How does Purview scan it?
- Question 6: Scans run every night and cost time. What is the difference between a full and an incremental scan, and what forces a full scan again?
- Scenario 7: The scan says succeeded, but users can't find half the tables in the catalog. How do you troubleshoot it, step by step?
The short answer
The Data Map is Purview's metadata foundation, filled by scans, lineage connections and the API. Scans need the right data-plane permissions and the right integration runtime: Azure, managed VNet or self-hosted. The first scan is full, later runs are incremental where the source supports it.
Keep that in mind. Every question below is one piece of it.
Question 1: You join a project where nobody knows what data exists across Azure SQL, ADLS and Snowflake. What is the Purview Data Map, and how do you start filling it?
The Data Map is Purview's metadata foundation. It holds technical metadata, schemas, classifications and lineage for sources across Azure, on-premises, other clouds, SaaS and Fabric. It's built on Apache Atlas.
It gets filled in three ways: by scans, by lineage connections from tools like Azure Data Factory, and through the REST API. For a scan, the flow is: the scan reads the source, ingestion loads the results, and only then do assets show up.
Let's start filling it, step by step:
- Domains and collections. Plan them first, say by business unit.
- Register each source into a collection.
- Set up a credential. A managed identity where you can, or a secret in Key Vault. For Snowflake, that means key pair authentication now.
- Create a scan with a scan rule set and a schedule.
In the new portal, live view already shows supported Azure and Fabric resources without a scan, but Snowflake still needs one.
Start with the sources the business cares about most. And remember you can't register the same source twice in one account.
Question 2: A scan of ADLS Gen2 fails with a permission error. What does the Purview managed identity need, and what else do you check?
The Purview managed identity needs Storage Blob Data Reader on the storage account, or on its resource group or subscription. To assign it, you need Owner or User Access Administrator rights.
Here is the checklist, in the order I go through it:
- Storage Blob Data Reader on the account, resource group or subscription.
- Not Owner or Contributor. Those are control plane roles, with no data access.
- Firewall. If the account allows only selected networks, turn on allow trusted Microsoft services, and use the managed identity with the Azure integration runtime.
- Key Vault. If the scan uses a service principal instead, Purview needs Get and List on secrets. An expired or rotated secret breaks a scan that used to work.
- Your own roles. To register and scan, you need Data source admin and Data reader on the collection, plus Azure Reader on the storage account.
Thinking Owner or Contributor is enough. Those roles manage the account, but they don't let you read the data. The scan needs the data plane role.
Question 3: Your Azure SQL scan returns databases but no tables, and lineage is empty. What permissions and network settings are missing?
Databases but no tables usually means Purview can list the server, but it can't read inside the databases. The managed identity needs a user in each database.
Let's fix it. As an Entra admin, create a user from external provider for the Purview account name, and add it to db_datareader. That's the documented minimum. Allow about 15 minutes for permissions to apply.
-- run in each database, as an Entra admin
CREATE USER [pv-contoso] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [pv-contoso];
-- only for stored procedure lineage (preview)
ALTER ROLE db_owner ADD MEMBER [pv-contoso];
CREATE MASTER KEY; -- only if the database has noneThen the network. With the Azure integration runtime, turn on allow Azure services and resources to access this server. With a self-hosted runtime, the managed identity doesn't work for Azure SQL, so use a service principal or SQL authentication.
Empty lineage is a separate switch. Azure SQL stored procedure lineage is in preview. You turn on enable lineage extraction on the scan, and the managed identity needs db_owner plus a database master key.
| Symptom | Fix |
|---|---|
| No tables | db_datareader user |
| Can't connect | allow Azure services |
| No lineage | db_owner, master key |
It's captured from real procedure runs, every 6 hours, and it doesn't work when public access is disabled or over private endpoints. Many teams miss that and think lineage is broken.
Question 4: The on-premises SQL Server and Oracle databases are behind the firewall. Which integration runtime do you use, and how do the integration runtime types differ?
You use a self-hosted integration runtime, installed on a Windows machine on-premises or in your virtual network that can reach the databases. Oracle is self-hosted only, and on-premises SQL Server needs it too.
Now let's look at the types side by side:
| Use it for | Managed by | |
|---|---|---|
| AZURE IR | public endpoints (the default) | Microsoft |
| MANAGED VNET IR | managed private endpoints | Microsoft |
| SELF-HOSTED IR | on-premises, IP allow lists | you: add nodes to scale |
| KUBERNETES SHIR | self-hosted IR on a Linux cluster | you |
| AWS IR | Amazon S3 and RDS | Microsoft |
The Azure integration runtime is the default, managed by Microsoft, for sources with public endpoints. The managed virtual network runtime runs in a Purview-managed network, and reaches sources through managed private endpoints. The self-hosted runtime is yours to maintain, and you scale it by adding nodes. There's also a Kubernetes version that runs it as containers on a Linux cluster, and an AWS runtime for Amazon S3 and RDS.
On a real project, the machine needs the right software. Oracle needs OpenJDK 8 and the Oracle JDBC driver, and plan memory at roughly 1 GB per 1,000 tables.
The most common failures are that the runtime is offline or out of date. And SQL authentication on SQL Server needs mixed mode turned on.
Question 5: The storage account has public access turned off and only private endpoints. How does Purview scan it?
The default Azure integration runtime can't reach it, because it comes in over the public endpoint. You have two options.
Option one is the managed virtual network integration runtime. Purview runs it in a network Microsoft manages, and creates a managed private endpoint to your storage account. The storage owner has to approve that endpoint. Use version 2, because version 1 can't create new managed private endpoints.
Option two is a self-hosted integration runtime on a machine in the same or a peered virtual network, plus a Purview ingestion private endpoint. With that setup, ADLS uses a service principal or an account key, not the managed identity.
Then two gotchas to know:
- The managed runtime hibernates after 90 days without scans, so the first scan can wait about 15 minutes while it wakes up.
- If test connection passes but the scan fails, check the NSG rules and the private endpoint DNS.
Question 6: Scans run every night and cost time. What is the difference between a full and an incremental scan, and what forces a full scan again?
A full scan reads the whole scope. An incremental scan reads only the resources that changed since the last scan. The first scan is always full, and after that runs are incremental, on sources that support it.
| Full scan | Incremental scan | |
|---|---|---|
| READS | the whole scope | only what changed |
| WHEN | first run, and after some changes | every run after that |
| SOURCES | all | not Snowflake or Oracle |
Not every source does. Snowflake and Oracle don't support incremental scans, so every run there is a full scan. Keep that in mind when you schedule them.
Some changes force a full scan again:
- Changing the scan rule set
- Changing a custom classification
- Raising the scan level
Here are the levels, so the last one makes sense:
| Level | Adds |
|---|---|
| L1 | basic metadata |
| L2 | + schema |
| L3 | + sampling, classification |
Raising the level, for example from schema only up to sampling and classification, forces a full scan. Lowering the level makes the next run incremental.
To save time, narrow the scope, stagger scans at off-peak hours, scan slow-changing sources less often, and turn off lineage extraction where you don't need it.
Under the new billing model scanning isn't charged, but it still loads your sources and takes hours.
Scenario 7: The scan says succeeded, but users can't find half the tables in the catalog. How do you troubleshoot it, step by step?
Let's go through it in five steps.
- Wait for ingestion. The scan run finishing isn't the end. Ingestion still has to load and index the assets, and they only show up after it completes.
- Check the scan scope. If the scan was scoped to selected folders or tables, anything outside that scope was never read, and new tables won't appear unless they're included.
- Check the scan identity. If it's a user in only some databases, you get only some tables. And names with a slash, backslash or hash (
/,\,#) can't be scanned. - Check resource sets. In a data lake, thousands of partition files become one resource set asset, so the data may be there under one grouped name.
- Check the users, not the scan. Search only shows assets where people have Data reader on the collection, and read access on the resource.
In my experience it's step five: users lack Data reader on the collection. The tables are in the Data Map; search just hides them.
Key points to remember
- The Data Map is the metadata foundation: scans, lineage, API
- ADLS: Storage Blob Data Reader; Azure SQL: db_datareader user
- Self-hosted IR for on-premises; managed VNet IR for private endpoints
- First scan full, then incremental; rule set changes force full
- Missing assets: ingestion, scope, identity, resource sets, user roles
Part 3: Classifications and Sensitive Data
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.