Microsoft Power BI Quiz: Credentials And Privacy Levels
10 questions · exam conditions
0:00
Credentials And Privacy LevelsQuestion 1 of 10

A Power BI Desktop model combines an internal SQL Server inventory table with a public government exchange-rate feed. The SQL Server is accessible only to employees, while the exchange-rate feed is intentionally available without authentication. Query folding is enabled where possible.

Which privacy-level configuration most appropriately protects the sources while allowing Power Query to evaluate the combination?

Set SQL Server to Organizational and the exchange-rate feed to Public.
Set SQL Server to Private and the exchange-rate feed to Organizational.
Set SQL Server to Public and the exchange-rate feed to Organizational.
Set both sources to Private and enable the option to ignore privacy levels.
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Credentials And Privacy Levels

Practice Credentials And Privacy Levels 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 Credentials And Privacy Levels, 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 model combines an internal SQL Server inventory table with a public government exchange-rate feed. The SQL Server is accessible only to employees, while the exchange-rate feed is intentionally available without authentication. Query folding is enabled where possible.

Which privacy-level configuration most appropriately protects the sources while allowing Power Query to evaluate the combination?

  1. Set SQL Server to Organizational and the exchange-rate feed to Public. (correct answer)
  2. Set SQL Server to Private and the exchange-rate feed to Organizational.
  3. Set SQL Server to Public and the exchange-rate feed to Organizational.
  4. Set both sources to Private and enable the option to ignore privacy levels.
Explanation: When working with Power Query privacy levels, your goal is to reflect actual data sensitivity so Power BI knows which sources can safely share data with each other — not to lock everything down arbitrarily. Power Query uses three privacy tiers: Private (isolated, never combined with other sources), Organizational (internal, can interact with other organizational or public sources), and Public (freely shareable, no restrictions). The engine uses these labels to decide whether query folding across sources could accidentally expose sensitive data. Option A is correct because it matches real-world sensitivity precisely. The SQL Server holds internal employee-only inventory data — Organizational is exactly right, signaling it can interact with other trusted sources but won't leak to the outside world. The government exchange-rate feed is intentionally public and unauthenticated, so labeling it Public is accurate and allows Power Query to freely fold or combine it with other sources without triggering privacy barriers. Option B is flawed because marking SQL Server as Private would completely isolate it, preventing any combination with the exchange-rate feed and breaking query folding unnecessarily. Option C inverts the logic dangerously — labeling the sensitive SQL Server as Public would tell Power Query it's safe to expose that data anywhere, which misrepresents its confidentiality and creates real security risk. Option D side-steps the privacy framework entirely by ignoring privacy levels, which disables the protective firewall Power Query provides and is never a recommended production practice. As a study tip, remember: privacy levels should mirror the data's real-world audience. Match the label to who legitimately has access — employees only → Organizational, everyone → Public.

Question 2

A query reads customer identifiers from a confidential CRM system and dynamically inserts each identifier into requests sent to a public web service. Refresh produces a Formula.Firewall error after the CRM source is correctly classified as Private and the web service as Public.

What should you do to address the issue without weakening the confidentiality classification?

  1. Classify both sources as Public so the identifiers can be included in web requests.
  2. Keep the privacy levels and redesign the query so confidential identifiers are not passed to the public source. (correct answer)
  3. Classify both sources as Organizational because the semantic model is used only by employees.
  4. Keep the privacy levels and replace the CRM credentials with Anonymous authentication.
Explanation: Whenever you see a Formula.Firewall error in Power BI, think about the Privacy Level firewall — Power BI's mechanism to prevent data from one source "leaking" into requests sent to another source with a lower confidentiality level. When a Private source feeds data into a Public source query, Power BI blocks the combination by design, because it cannot guarantee that confidential data won't be exposed externally. The right fix, as option B describes, is to restructure the query so that confidential identifiers from the CRM are never dynamically embedded into requests to the public web service. For example, you might retrieve all public data first and then merge or filter it locally within Power BI, keeping the two sources isolated from each other. This resolves the firewall error while fully preserving the Private and Public classifications — exactly what the question asks for. Option A is dangerous because reclassifying the CRM as Public tells Power BI it's safe to share that data freely, directly contradicting the confidentiality requirement. Option C has the same fundamental problem: Organizational is still a weaker classification than Private, and this approach lowers the protection on sensitive data just to make the query work — a security trade-off the question explicitly rules out. Option D is a red herring; authentication method controls how you log in to a source, not how Power BI handles cross-source data flow. Switching to Anonymous for the CRM wouldn't affect the firewall behavior at all. Your study tip: on Power BI exam questions about the firewall, always ask yourself whether the proposed fix lowers a privacy classification. If it does, it's almost certainly wrong — the correct answer will honor the original classifications and fix the query logic instead.

Question 3

An open-data website publishes a dataset for unrestricted reuse but requires users to sign in with an organizational account so usage can be audited. A developer assumes that any source using organizational authentication must have the Organizational privacy level.

Which configuration is most appropriate?

  1. Use Anonymous credentials and set the privacy level to Public because the data is unrestricted.
  2. Use organizational credentials and set the privacy level to Organizational because authentication determines privacy.
  3. Use organizational credentials and set the privacy level to Public because access method and data sensitivity are separate. (correct answer)
  4. Use Windows credentials and set the privacy level to Private because audited access implies confidential data.
Explanation: When working with Power BI data source configuration, you need to recognize that credentials and privacy levels serve completely different purposes and are configured independently. Credentials control how you authenticate to a source; privacy levels control how sensitive the underlying data is and whether Power BI can combine it with other sources safely. The open-data website in this scenario requires organizational sign-in purely for audit logging — the data itself is publicly available and unrestricted. This means you correctly use organizational credentials (because that's what the site requires for access), but you set the privacy level to Public (because the data has no confidentiality restrictions). That's exactly what C describes, making it the right choice. A is tempting because the data is public, but Anonymous credentials won't work here — the site explicitly requires sign-in. The privacy level reasoning is sound, but the credential choice ignores the authentication requirement. B is the trap this question is specifically designed to catch. It reflects the developer's mistaken assumption that organizational authentication implies organizational-level data sensitivity. It doesn't. Authentication is a gatekeeping mechanism; privacy levels reflect the data's inherent sensitivity. Setting privacy to Organizational would unnecessarily restrict how Power BI can combine this data with other sources. D introduces Windows credentials, which are appropriate for on-premises resources like file shares or SQL Server — not web-based open-data portals. Audited access does not imply the data is confidential. As a study tip, always ask yourself two separate questions: "What credentials does the source require?" and "How sensitive is the data itself?" These answers can — and often do — differ.

Question 4

To eliminate Formula.Firewall warnings during development, an analyst enables the Power BI Desktop option to ignore privacy levels. The model combines a confidential payroll source with an external public website, and a query may be folded into requests against that website.

What is the primary risk of this configuration?

  1. Power BI may send values from the confidential source to the external source while evaluating the combined query. (correct answer)
  2. Power BI may permanently replace the payroll credentials with the website's Anonymous authentication method.
  3. Power BI may automatically publish the semantic model to every workspace available to the analyst.
  4. Power BI may convert all imported payroll tables to DirectQuery without preserving transformations.
Explanation: Whenever you see a question about Power BI privacy levels, think about data leakage across trust boundaries. Privacy levels exist specifically to prevent Power BI's query engine from inadvertently combining data sources of different sensitivity classifications. When you disable privacy-level checks by ignoring them in Desktop settings, you remove that protective barrier entirely. Here's the core risk: Power BI's query folding and query optimization engine can merge logic from multiple sources into a single request. If privacy levels are ignored, the engine may use values from your confidential payroll source as parameters or filter predicates in a request sent to the external public website. That website's server — or anyone monitoring traffic to it — could then observe sensitive payroll data embedded in those requests. Answer A captures this precisely: confidential values can be transmitted to an external source as a side effect of query evaluation. Answer B is incorrect because authentication methods are source-specific and credential-independent from privacy settings — disabling privacy checks does not alter or overwrite stored credentials for any source. Answer C is a fabricated risk; ignoring privacy levels has no relationship to workspace publishing behavior, which is governed by separate publishing and sharing controls. Answer D is similarly invented — privacy settings have no effect on storage mode; switching between Import and DirectQuery is a deliberate, manual model design decision. A useful study tip: on Power BI exam questions, any time you see "Formula.Firewall" or "ignore privacy levels," immediately think data exfiltration risk — the exam consistently tests whether you understand that this setting trades security for convenience, not performance for accuracy.

Question 5

A company has development and production SQL databases on the same server. The databases use different database credentials, but both contain internal business data. A query is changed from the development database to the production database before deployment.

How should the production connection be configured?

  1. Reuse the development credentials because privacy levels, rather than database paths, define the credential scope for all databases on the same server.
  2. Classify the production source as Private so Power BI automatically discovers and requests the correct production database credentials on next refresh.
  3. Use Anonymous authentication for the production database and rely on the Organizational privacy level to handle authorization at query time.
  4. Create or edit the production data-source entry with its production credentials and classify it as Organizational. (correct answer)
Explanation: When working with Power BI data sources, it's important to understand how credential scope and privacy levels function independently. Credentials are scoped to the specific data source path (server + database combination), while privacy levels control how data from different sources can be combined. Confusing these two concepts is the most common trap in questions like this one. The correct approach, choice D, reflects how Power BI actually handles distinct databases: even when two databases live on the same server, they are treated as separate data source entries requiring their own credentials. You must explicitly configure the production database entry with its production credentials and assign it an appropriate privacy level — Organizational works here because the data is internal business data shared within the company, not public-facing or strictly confidential. Choice A is wrong because credential scope is tied to the full data source path, not just the server. Databases with different paths need separate credential entries, regardless of proximity on the same server. Choice B misrepresents how the Private privacy level works — Private restricts data from being combined with other sources; it doesn't trigger automatic credential discovery or prompting. Choice C introduces a double error: Anonymous authentication bypasses proper database credentials entirely, and Organizational privacy doesn't perform authorization — it only governs how Power BI may combine query results across sources. A useful rule of thumb: privacy levels govern data combination; credentials govern access. On the Power BI exam, whenever you see a scenario involving multiple databases or environments, ask yourself separately — "Who can access this?" (credentials) and "Can this data be merged with other sources?" (privacy levels).

Question 6

A developer successfully refreshes a semantic model in Power BI Desktop by using an OAuth account for a cloud SaaS source. After publication, scheduled refresh in the Power BI service reports that the data source credentials are missing.

What should you do?

  1. Republish the PBIX file after selecting Private for the SaaS source in Desktop.
  2. Configure OAuth credentials for the semantic model's data source in the Power BI service. (correct answer)
  3. Embed the OAuth access token as a parameter in the Power Query expressions.
  4. Install an on-premises data gateway and reuse the credentials stored by Desktop.
Explanation: Whenever you see a question about credentials and the Power BI service, remember this key principle: Desktop and the Power BI service maintain completely separate credential stores. Just because a connection works in Desktop doesn't mean the service inherits those credentials — you must configure them independently after publishing. When you publish a semantic model to the Power BI service, the service needs its own authenticated connection to every data source. For cloud SaaS sources using OAuth, you navigate to the semantic model's settings in the Power BI service, find the Data source credentials section, and sign in with your OAuth account there. This explicitly authorizes the service — not just your local Desktop client — to connect and refresh. That's exactly what option B prescribes, making it the correct action. Option A is a trap — changing the privacy level to Private in Desktop affects how Power Query isolates data during query folding, not how the service authenticates. Republishing won't carry credentials into the service. Option C is dangerous and wrong: hardcoding OAuth tokens inside Power Query expressions is a security antipattern, and access tokens expire quickly, making scheduled refresh unreliable. Option D introduces unnecessary complexity — on-premises data gateways are designed for private network or on-premises sources, not cloud SaaS endpoints that are already publicly accessible. Installing one won't resolve a missing-credentials error for a cloud source. Your study tip: memorize the phrase "Desktop ≠ Service credentials." On the Power BI exam, any scenario describing a refresh failure after publication almost always points to re-entering credentials in the Power BI service settings — this is one of the most commonly tested operational gotchas.

Question 7

A published semantic model combines an on-premises SQL Server database with SharePoint Online. Refresh works in Power BI Desktop but fails in the Power BI service. The SQL Server is not reachable from the public internet, and no service-side connections have been configured.

Which configuration should you implement for scheduled refresh?

  1. Configure an on-premises gateway connection for SQL Server and authenticate SharePoint Online separately in the service. (correct answer)
  2. Configure one SharePoint Online connection and route both sources through its organizational credentials.
  3. Store both sets of credentials as Power Query parameters and republish the semantic model.
  4. Set both sources to Public in Desktop so the service can reuse the local credentials.
Explanation: When a semantic model in the Power BI service fails to refresh despite working in Desktop, your first instinct should be to examine where each data source lives and what connectivity path is available to the service. Power BI Desktop runs on your local machine, so it can reach on-premises resources directly. The Power BI service, however, runs in the cloud and cannot natively reach anything behind a corporate firewall. The on-premises data gateway is the purpose-built solution for this gap. It acts as a secure bridge between the Power BI service and on-premises sources like SQL Server. For cloud sources like SharePoint Online, the service can connect directly using credentials you configure in the dataset settings. Answer A is correct because it addresses each source appropriately: the gateway handles the private SQL Server, and SharePoint Online authenticates separately through its own organizational credentials in the service — no gateway required for a cloud endpoint. Answer B is wrong because SharePoint Online credentials cannot "carry" connectivity to SQL Server. These are entirely different authentication mechanisms and network paths; you cannot proxy one source's credentials through another. Answer C is a misconception about what Power Query parameters do. Parameters control values like server names or file paths — they do not establish network connectivity or bypass the gateway requirement. Republishing changes nothing about how the service reaches an on-premises resource. Answer D is incorrect because the Privacy Level setting ("Public") controls how Power Query combines data from different sources, not how the service authenticates or routes network traffic. Local Desktop credentials are never transferred to or reused by the service. Remember this pattern: any on-premises source in the service requires a gateway — no exceptions.

Question 8

A SQL Server password was changed. Power BI Desktop continues trying the old password and repeatedly returns an authentication error before prompting for new credentials. The server name and database name have not changed.

Which action should you take first in Power BI Desktop?

  1. Change the source privacy level from Organizational to Private and refresh the preview.
  2. Clear or edit the source permissions in Data source settings, and then authenticate again. (correct answer)
  3. Delete all query steps after the Source step and recreate the database connection.
  4. Enable the option to ignore privacy levels, and then enter the new password during refresh.
Explanation: When Power BI Desktop caches credentials for a data source, it stores them in Data source settings — a centralized location separate from individual query steps. When a password changes, the cached credentials become stale, and simply refreshing won't fix the problem because Power BI keeps retrying the old stored credentials. The solution is to clear or edit those stored permissions so Power BI can prompt you to enter the updated credentials fresh. That's exactly why B is correct. Navigating to File → Options and settings → Data source settings, finding your SQL Server source, and selecting "Clear Permissions" (or editing them directly) removes the outdated password. Power BI will then prompt you to authenticate again with the new credentials — clean and targeted. A is a red herring. Privacy levels control how Power BI handles data isolation between sources during query folding — they have nothing to do with authentication failures caused by a changed password. Switching to Private won't re-prompt you for credentials. C is unnecessarily destructive. Deleting query steps would dismantle your data model work for no reason. The problem isn't in the query logic — the server and database names haven't changed. The problem is solely in the stored credential. D misunderstands privacy levels entirely. Ignoring privacy levels bypasses data isolation checks, not authentication checks. It won't help you input a new password, and it introduces unnecessary security risk. Study tip: On Power BI exam questions involving authentication or credential errors, always think "Data source settings" first — that's where Power BI stores and manages credentials globally, independent of individual reports or queries.

Question 9

A developer connects to a CSV file in SharePoint Online by using the file's full URL and organizational credentials. Several queries will later access files in different folders of the same SharePoint site. The developer wants refresh to use one maintainable credential scope without granting access to unrelated SharePoint sites.

Which approach should the developer use?

  1. Connect at each file URL, use Windows authentication, and disable privacy checks for folder combinations.
  2. Connect at the SharePoint tenant root, authenticate anonymously, and set every site to the Public privacy level.
  3. Create a separate embedded username and password parameter for every individual CSV file URL.
  4. Connect at the relevant SharePoint site URL, authenticate with an organizational account, and set an appropriate Organizational privacy level. (correct answer)
Explanation: When working with SharePoint data sources in Power BI, credential scope is everything. Power BI maps credentials to a URL prefix, meaning the level at which you authenticate determines which resources share that credential. Choosing the right "entry point" URL lets you maintain one credential that covers multiple files without over-permissioning. Connecting at the SharePoint site URL (option D) is the correct approach because it scopes the credential precisely to that site. All queries hitting files within that site's folders will automatically reuse the same organizational account credential. Setting the Organizational privacy level ensures Power BI treats data from that source as internal and trustworthy, enabling query folding and cross-source combinations without leaking data inappropriately. This is the maintainable, least-privilege solution the scenario asks for. Option A fails on two counts: Windows authentication is designed for on-premises Active Directory environments, not SharePoint Online, and disabling privacy checks is a security risk that bypasses important data isolation guardrails. Option B is dangerous — anonymous authentication on a SharePoint Online site typically won't work with organizational data, and setting everything to Public privacy level exposes potentially sensitive data to uncontrolled query combinations. Option C embeds separate credentials per file URL, which is the opposite of maintainable. Every time a file path changes or credentials rotate, you'd need to update each one individually — a maintenance nightmare that the question explicitly asks you to avoid. Your study tip: on Power BI exam questions about credentials, always ask "at what URL level is the credential scoped?" Broader scopes reduce maintenance; narrower scopes increase it. Match scope to the smallest unit that covers all your sources.

Question 10

A Power Query uses a commercial web API. The API requires a key in a named query-string parameter. The returned market data is approved for public disclosure, but the API key must remain secret and must be replaceable without editing the M expression.

Which design best meets the requirements?

  1. Concatenate the key directly into the request URL string, use Anonymous credentials for the connection, and classify the source as Private to restrict combination with other queries.
  2. Store the key in a named text parameter in the query, pass it to the URL via string concatenation, use Basic credentials, and classify the source as Organizational.
  3. Specify the API key parameter name using the ApiKeyName option in Web.Contents, supply the key through Web API credentials in the data source settings, and classify the returned data as Public. (correct answer)
  4. Place the key value in a custom column that is merged into the request, use OAuth credentials for the web connection, and disable privacy-level checks to allow the query to evaluate without a firewall error.
Explanation: When a Power Query needs to pass a secret credential (like an API key) through a URL query string, you should separate the secret from the M code itself. Power BI's Web.Contents function has a built-in mechanism for exactly this: the ApiKeyName option. When you specify ApiKeyName, Power BI knows which query-string parameter carries the credential and lets you supply the actual key value through the data source settings UI — completely outside the M expression. This means the key never appears in your code, can be rotated without touching the query, and is stored securely by Power BI. Because the returned data is approved for public disclosure, classifying the data source as Public is correct and allows the query to combine freely with other sources without firewall restrictions. Option C satisfies every stated requirement: the key stays secret, it's replaceable without editing M, and the data privacy level matches the actual sensitivity of the output. Option A fails immediately because it hardcodes the key directly in the URL string — the key is visible in the M expression and cannot be replaced without editing code. Option B stores the key in a named query parameter, which still embeds it inside the M expression and exposes it to anyone who can view the query. Classifying it as Organizational also unnecessarily restricts data combination. Option D is a security and governance anti-pattern: merging credentials via a custom column exposes the key in the data model, and disabling privacy checks removes an important safeguard rather than solving the root problem properly. Your study tip: whenever a question pairs "secret credential" with "no code edits," think ApiKeyName + data source settings. That pairing is a signature Power BI pattern worth memorizing.