Microsoft Power BI Quiz: Data Refresh And Troubleshooting
10 questions · exam conditions
0:00
Data Refresh And TroubleshootingQuestion 1 of 10

A Power BI Desktop file imports data from several tables in the same SQL Server database by using Windows authentication. After the report developer changes their domain password, every query from that database fails during refresh with a credential error. The developer can connect to the database successfully from SQL Server Management Studio.

What should the developer do first to restore refresh in Power BI Desktop?

Open Data source settings, edit permissions for the SQL Server source, and authenticate again
Open Power Query Editor, delete the Navigation steps, and select the database tables again
Disable background data previews and then restart Power BI Desktop with the existing credentials
Change each query from Import storage mode to DirectQuery and reconnect to the database
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Data Refresh And Troubleshooting

Practice Data Refresh And Troubleshooting in Microsoft Power BI with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Data Refresh And Troubleshooting, giving you a quick way to practice the rules, question types, and explanations that matter most for Microsoft Power BI.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A Power BI Desktop file imports data from several tables in the same SQL Server database by using Windows authentication. After the report developer changes their domain password, every query from that database fails during refresh with a credential error. The developer can connect to the database successfully from SQL Server Management Studio.

What should the developer do first to restore refresh in Power BI Desktop?

  1. Open Data source settings, edit permissions for the SQL Server source, and authenticate again (correct answer)
  2. Open Power Query Editor, delete the Navigation steps, and select the database tables again
  3. Disable background data previews and then restart Power BI Desktop with the existing credentials
  4. Change each query from Import storage mode to DirectQuery and reconnect to the database
Explanation: When you see a credential error after a password change in Power BI Desktop, think about how the application stores and manages connection credentials. Power BI Desktop caches data source credentials separately from Windows system credentials — changing your domain password doesn't automatically update what Power BI has stored for that source. The fix is exactly what A describes: navigate to File → Options → Data source settings, find the SQL Server source, edit its permissions, and re-authenticate. This forces Power BI Desktop to capture your new Windows credentials and clears the stale cached ones that are causing the refresh failure. The fact that SSMS connects successfully confirms the database itself is fine — only Power BI's stored credential is outdated. B is a red herring. Deleting Navigation steps and reselecting tables is a drastic structural change to your queries. It doesn't address the credential cache at all and would unnecessarily break your query logic. C misunderstands the problem entirely. Background data previews are a performance setting unrelated to authentication. Restarting Power BI with the existing (now invalid) credentials would accomplish nothing — the stale credentials are precisely the problem. D conflates storage mode with authentication. Switching to DirectQuery doesn't re-authenticate you; it changes how data is fetched. You'd still face the same credential error, plus you'd be introducing unnecessary architectural changes to your data model. Study tip: On Power BI exam questions involving credential or authentication errors, always look for the answer that targets the credential cache directly — that's almost always the right first step before touching query structure or storage modes.

Question 2

A Power Query query connects successfully to an Excel workbook. Its Source step shows the workbook contents, but the next step fails with the message The key didn't match any rows in the table. The workbook owner recently renamed the Sales worksheet to Sales_2026; the worksheet's columns are unchanged.

Which change should you make to repair the query with the least disruption?

  1. Edit the Navigation step to select the worksheet named Sales_2026 (correct answer)
  2. Edit the Source step to use a different Excel file connector
  3. Remove the Changed Type step and allow automatic type detection
  4. Clear the workbook credentials and reconnect with anonymous authentication
Explanation: When a Power Query query breaks after a data source is renamed, your first instinct should be to trace where in the step sequence the failure occurs. Power Query records each transformation as a discrete step, and navigation to a specific sheet, table, or named range is captured in its own Navigation step — separate from the Source step that simply opens the file. Here, the Source step still succeeds (the workbook loads fine), but the very next step fails with "The key didn't match any rows in the table." This error is Power Query's way of saying it tried to look up an item by name — Sales — and couldn't find it, because the worksheet was renamed to Sales_2026. The fix is surgical: open the Navigation step in the formula bar or step settings and update the worksheet reference to Sales_2026. That's exactly what A does, and it leaves every downstream step (type changes, filters, etc.) completely intact. B is wrong because the file connector isn't the problem — the workbook opens successfully. Switching connectors adds complexity without addressing the root cause. C is a red herring; the Changed Type step applies after navigation, and no type-detection setting can resolve a missing worksheet name. Removing it wouldn't fix the lookup failure and could silently corrupt your data types. D is irrelevant because credential type (anonymous vs. organizational) has nothing to do with a worksheet lookup error; authentication controls access to the file, not the internal navigation within it. For the exam, remember: a "key didn't match" error in Power Query almost always points to a Navigation step referencing a renamed or deleted item — not a connection or authentication problem.

Question 3

In Power BI Desktop, an analyst opens Power Query Editor and selects Refresh Preview. The preview displays the newest records from the source. After returning to the report, the visuals still display values from the previous day, and no refresh error is shown.

Which action should the analyst take to update the data used by the report visuals?

  1. Select Recalculate on each visual so it reads directly from the preview cache
  2. Select Refresh Preview again after disabling column profiling in Power Query Editor
  3. Clear the data source permissions and recreate the connection from the report view
  4. Select Refresh on the Home ribbon in the main Power BI Desktop window (correct answer)
Explanation: When working with Power BI Desktop, it's critical to understand the distinction between the Power Query Editor environment and the main report environment — they operate on separate data states. The Power Query Editor uses a preview of your data purely for designing and testing transformations. This preview does not automatically flow into the report's underlying dataset. To actually load refreshed data into the dataset that powers your report visuals, you must trigger a full data refresh from the main Power BI Desktop window. Answer D is correct — selecting Refresh on the Home ribbon in the main window executes the full query pipeline, loads results into the in-memory dataset, and updates all visuals accordingly. This is the only action that completes the data refresh cycle end-to-end. The distractors each reflect common misconceptions. A is wrong because visuals have no "Recalculate" option that reads from a preview cache — visuals render from the loaded dataset, not from Power Query's preview buffer. B is wrong because Refresh Preview only updates the sample rows shown inside Power Query Editor; disabling column profiling changes diagnostic behavior, not data loading. Neither action touches the report dataset. C is wrong because clearing data source permissions is a credential/security action — it doesn't refresh data and would more likely break the connection than fix a stale dataset. A useful rule of thumb: Power Query Editor = design time; Home ribbon Refresh = runtime. Any time a question describes visuals showing stale data with no errors, the answer almost always involves triggering a full dataset refresh from the main Desktop interface.

Question 4

A Power BI Desktop query connects to a web API by using an organizational account. After the account password is reset, refresh fails with an HTTP 401 Unauthorized response. The same user can sign in to the API through a browser and retrieve data.

What should you do first in Power BI Desktop?

  1. Convert the web query to DirectQuery so authentication occurs only in the browser
  2. Change the API connection to Anonymous while retaining the existing request headers
  3. Edit or clear the API source permissions and sign in again at the correct URL scope (correct answer)
  4. Remove all transformation steps because an HTTP 401 indicates invalid query syntax
Explanation: When Power BI Desktop connects to a web API using an organizational account, it stores the credential and its scope (the URL it applies to) in the Data Source Settings permission store. After a password reset, the cached token or credential becomes stale — even though you can still log in through a browser, Power BI's stored credential no longer matches the valid session. The fix is to go to File → Options → Data Source Settings, find the API source, and either edit the credential to sign in again or clear it entirely so Power BI prompts for fresh authentication at the correct URL scope. This is exactly what C describes, making it the right first step. A is a trap — DirectQuery changes how data is loaded, not how authentication is handled. An HTTP 401 is an auth failure, not a query-mode problem, so switching to DirectQuery does nothing to re-authenticate your credential. B is wrong because changing to Anonymous removes authentication entirely. The API requires an organizational account; stripping credentials would still produce a 401 (or worse, expose a security gap). D is completely off-base. HTTP 401 means Unauthorized — it's an authentication/authorization error, not a syntax error. Removing transformation steps has no effect on whether your credential is valid. Study tip: On Power BI exam questions involving HTTP error codes, map them to their meaning first — 401 = authentication failure, 403 = authorization/permission denied, 404 = resource not found. Whenever you see a 401 after a credential change, your first instinct should be "refresh or re-enter the stored credential in Data Source Settings."

Question 5

A report imports an Excel workbook from C:\Finance\Budget.xlsx. The workbook is moved to D:\Approved\Budget.xlsx without changing its worksheets or columns. Refresh now returns a file-not-found error. The report contains many transformation steps that must be preserved.

Which action is the most appropriate way to restore the connection while preserving the transformations?

  1. Change the file location for the existing source in Data source settings (correct answer)
  2. Edit the Navigation step so that it points to the new workbook location
  3. Clear the permissions for the old file and refresh without changing the path
  4. Delete the existing queries and import the workbook again from its new location
Explanation: When a Power BI report loses its connection to a moved file, you need to understand the difference between the data source path and the query transformation steps. These are two separate layers — the source path tells Power BI where to find the file, while the transformation steps (in Power Query) define what to do with it once found. The cleanest solution is A: using Data source settings to update the file path. This setting lives at the source level and affects only the connection string — all your downstream transformation steps remain completely untouched. Power BI simply starts fetching from the new location and applies every existing step exactly as before. This is precisely what Data source settings was designed for: reconnecting to a relocated or renamed source without rebuilding anything. B is tempting but wrong. The Navigation step selects a specific worksheet or table within an already-connected workbook — it doesn't define the file path itself. Editing it wouldn't fix a file-not-found error and could break your worksheet selection logic. C is a red herring. Clearing permissions removes stored credentials, which addresses authentication problems — not missing file paths. The file still won't be found after clearing permissions. D is the nuclear option. Deleting and reimporting the workbook would require you to rebuild all your transformations from scratch, which the scenario explicitly says you want to avoid. As a study tip: on Power BI exam questions, watch for scenarios that separate where data comes from (source settings, credentials) from how data is shaped (Power Query steps). Knowing which layer to touch saves you from both data loss and unnecessary rework.

Question 6

An imported SQL Server query refreshes successfully when restricted to one month of data. After the filter is expanded to five years, Power BI Desktop reports that the command timed out. The same SQL statement completes successfully in a database tool, but it requires several minutes. A database administrator is already working to optimize the query.

What is the most appropriate temporary change in Power BI Desktop?

  1. Disable relationship detection so the SQL command can continue running indefinitely
  2. Increase the credential encryption level in the source permission settings
  3. Increase the command timeout in the SQL Server connection's advanced options (correct answer)
  4. Clear the preview cache so the database returns fewer rows during model refresh
Explanation: When Power BI Desktop imports data, it sends queries to the source database and waits for a response. By default, this wait has a built-in timeout limit. If a query legitimately takes several minutes — as this five-year SQL statement does — Power BI will abort it before it finishes, reporting a timeout error. The fix isn't to optimize the query right now (the DBA is already on that), but to buy the query enough time to complete successfully in the interim. That's exactly what option C does. In the SQL Server connector's advanced options, you can set a Command Timeout in Minutes, overriding the default. Since the query already succeeds in an external database tool given enough time, simply allowing Power BI to wait longer resolves the immediate problem without any infrastructure changes. The distractors each represent a different misunderstanding. Option A confuses relationship detection — a feature that auto-detects table joins after import — with query execution control. Disabling it has no effect on how long a source query is allowed to run. Option B conflates credential encryption with query performance; encryption level governs how connection credentials are stored and transmitted, not how long a command can execute. Option D misidentifies the issue as a data volume problem during preview, but this is a model refresh timeout, not a preview cache issue — clearing the cache wouldn't extend the allowed execution window. A useful pattern to remember: when a Power BI error message includes the word "timed out," your first instinct should be to look for a timeout setting in the connector's advanced options, not a data or security setting.

Question 7

A report imports a file from Z:\Operations\Daily.csv, where Z: is a mapped network drive on the developer's desktop computer. On a company laptop, the user can browse the share by using \\FileServer\Operations, but Power BI refresh reports that Z:\Operations\Daily.csv cannot be found. The laptop does not have a Z: drive mapping.

Which action provides the most reliable fix for refresh on the laptop?

  1. Clear the CSV transformation steps and let Power BI infer the mapped drive automatically
  2. Update the source to the UNC path and authenticate to the network share if prompted (correct answer)
  3. Change the source privacy level to Public so Power BI can create the missing drive mapping
  4. Disable parallel loading so the unavailable mapped drive is checked one query at a time
Explanation: When Power BI connects to a data source, it stores the literal path string you gave it — it doesn't resolve network locations dynamically. So when a report built with a mapped drive path like Z:\Operations\Daily.csv moves to a machine without that mapping, the path simply doesn't exist, and refresh fails. The fix lives at the source level: replace the drive-letter path with a UNC path (\\FileServer\Operations\Daily.csv), which is a machine-independent network address that any computer on the domain can resolve, regardless of local drive mappings. If the share requires credentials, Power BI will prompt you to authenticate, which you handle in the Data Source Settings dialog. Updating the source path this way — option B — is the correct and reliable fix. Option A is wrong because Power BI has no mechanism to "infer" a mapped drive. Clearing transformation steps would destroy your query logic and still wouldn't produce a valid path on a machine without Z:. Option C misunderstands what Privacy Levels do — they control how Power BI combines data from sources with different trust levels to prevent data leakage; they have absolutely nothing to do with drive mappings or network discovery. Option D is wrong because serial versus parallel query loading is a performance setting; disabling it doesn't make an unavailable path suddenly resolvable — the path either exists on the machine or it doesn't. As a study rule: whenever you see a Power BI refresh failure tied to a file path, immediately think UNC path vs. mapped drive. UNC paths are always more portable across machines and environments, and this distinction appears frequently on the exam.

Question 8

A report connects to a Microsoft Access .accdb file. It refreshes on a computer running 32-bit Power BI Desktop. On a new computer running 64-bit Power BI Desktop, refresh fails with a message indicating that the required Access database provider is not registered. The file path and permissions are valid.

Which action is most likely to resolve the refresh failure on the new computer?

  1. Install the 64-bit Microsoft Access Database Engine that matches Power BI Desktop (correct answer)
  2. Install a 32-bit SQL Server ODBC driver and configure a system data source name
  3. Convert the imported model to DirectQuery and leave the Access provider unchanged
  4. Clear the Access file permissions and reconnect by using Windows authentication
Explanation: Whenever you see a question about connectivity failures tied to a bitness mismatch, think about how Windows handles 32-bit vs. 64-bit drivers. Power BI Desktop relies on OLE DB providers installed on the local machine, and those providers must match the bitness of Power BI Desktop itself — they cannot be mixed. On the old 32-bit machine, Power BI Desktop used the 32-bit Microsoft Access Database Engine (ACE provider) without issue. On the new 64-bit machine, Power BI Desktop looks for a 64-bit ACE provider, which is a separate installation. Since it wasn't installed, the refresh fails with exactly the kind of "provider not registered" error described. Installing the 64-bit Microsoft Access Database Engine — as option A suggests — directly resolves this by giving Power BI the matching driver it needs. Option B is wrong because an ODBC driver for SQL Server has nothing to do with connecting to an Access .accdb file; these are entirely different data sources and driver families. Option C is a red herring — switching to DirectQuery doesn't eliminate the need for an installed, compatible Access provider; the connection still requires the same local driver. Option D conflates a permissions issue with a driver issue. The passage already states permissions are valid, so clearing them and switching authentication methods won't fix a missing provider registration. A useful rule of thumb: driver bitness must match application bitness. If you see "provider not registered" in a Power BI question alongside a platform change, your first instinct should be to check whether the correct 32-bit or 64-bit driver is installed on that machine.

Question 9

A CSV-based report refreshed successfully for several months. A new file contains N/A in three rows of a column that the query converts to Whole Number. Refresh now fails at the Changed Type step with a conversion error. The model requires valid values in that column to remain numeric.

Which modification best resolves the refresh error while preserving the intended model data type?

  1. Change the entire column to Text after the Changed Type step has already failed
  2. Replace N/A with null before the Changed Type step, then retain Whole Number (correct answer)
  3. Remove the Source step and import only the three rows containing N/A
  4. Change the column's visual formatting to display numbers without decimal places
Explanation: When troubleshooting Power Query refresh errors, the key is identifying where in the step sequence the failure occurs and fixing the data upstream of the problematic step — not patching things downstream or bypassing the pipeline entirely. Here, the Changed Type step fails because Power Query encounters literal text (N/A) when it expects a Whole Number. The fix must happen before that step. Option B does exactly this: by replacing N/A values with null prior to the type conversion, you give Power Query clean, castable data. Null values pass through a Whole Number conversion without error and are a valid representation of missing data in Power BI's data model. The column retains its Whole Number type, satisfying the model requirement. Option A is backwards — changing the column to Text after the step has already failed doesn't prevent the error, and even if reordered, switching to Text abandons the numeric data type the model requires. Option C is nonsensical from a data modeling perspective; removing the Source step and importing only the three problematic rows would destroy the entire dataset, not fix a data quality issue. Option D confuses visual formatting with data types — changing how numbers display in a visual has absolutely no effect on how Power Query processes or stores values during refresh. A useful pattern to remember: Power Query steps execute in order, so data quality problems must be resolved before the step that enforces the type constraint. When you see conversion errors on this exam, look for the answer that cleans the data upstream — that's almost always the correct strategy.

Question 10

A query reads department identifiers from an internal SQL Server and uses them as parameters in requests to an approved internal web API. Refresh returns a Formula.Firewall privacy error. The SQL Server is classified as Organizational, but the internal API was mistakenly classified as Public.

What should you do to resolve the error without globally disabling privacy protection?

  1. Change the SQL queries to DirectQuery so the web API bypasses privacy evaluation
  2. Classify the SQL Server as Public so both sources permit unrestricted data transfer
  3. Enable the option to ignore all privacy levels for every Power BI Desktop file
  4. Classify the approved internal API as Organizational and refresh the combined query (correct answer)
Explanation: When Power BI combines data from multiple sources, it enforces privacy levels to prevent sensitive data from leaking between sources. The Formula.Firewall error specifically appears when Power BI cannot safely fold or pass data from one source into another because their privacy classifications are incompatible — it's Power BI protecting you from accidentally sending internal data to a less-trusted destination. In this scenario, the SQL Server is correctly marked Organizational, but the internal API was mistakenly marked Public. Power BI sees a potential risk: internal organizational data (department IDs) being sent to what it thinks is a public endpoint. The fix is simply correcting that misclassification. Once the API is also marked Organizational, both sources share the same trust tier, and Power BI allows the combined query to execute — which is exactly what D prescribes. No privacy protections are weakened; you're just accurately reflecting reality. A is incorrect because switching to DirectQuery changes how data is loaded, not how privacy levels are evaluated. Privacy isolation still applies regardless of query mode. B is a dangerous overcorrection — downgrading the SQL Server to Public means organizational data is treated as unrestricted, which undermines the entire privacy framework and could expose sensitive internal data. C globally disables privacy evaluation for every file you open in Power BI Desktop, which is a sledgehammer approach that eliminates all privacy protections system-wide, far exceeding what the question asks you to avoid. As a study tip: whenever you see a Formula.Firewall error, immediately think "mismatched privacy levels." The fix is almost always to align the classifications accurately rather than disable protections entirely.