Microsoft Power BI Quiz: Gateways
10 questions · exam conditions
0:00
GatewaysQuestion 1 of 10

A company publishes two import-mode Power BI semantic models. The first connects to a SQL Server database available only on the corporate network. The second connects to a publicly accessible Azure SQL Database. Both models require scheduled refresh.

Which gateway configuration meets the requirement with the least on-premises infrastructure?

Install one standard on-premises data gateway for the corporate SQL Server model and use a cloud connection for the Azure SQL model.
Install separate standard on-premises data gateways for both models and configure each database as an on-premises gateway connection.
Install a personal-mode gateway for the Azure SQL model and configure the corporate SQL Server model as a direct cloud connection.
Install one standard on-premises data gateway and require both models to route all refresh traffic through the corporate network.
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Gateways

Practice Gateways 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 Gateways, 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 company publishes two import-mode Power BI semantic models. The first connects to a SQL Server database available only on the corporate network. The second connects to a publicly accessible Azure SQL Database. Both models require scheduled refresh.

Which gateway configuration meets the requirement with the least on-premises infrastructure?

  1. Install one standard on-premises data gateway for the corporate SQL Server model and use a cloud connection for the Azure SQL model. (correct answer)
  2. Install separate standard on-premises data gateways for both models and configure each database as an on-premises gateway connection.
  3. Install a personal-mode gateway for the Azure SQL model and configure the corporate SQL Server model as a direct cloud connection.
  4. Install one standard on-premises data gateway and require both models to route all refresh traffic through the corporate network.
Explanation: When you see a question about Power BI gateway configurations, the core decision framework is simple: does the data source live behind a corporate firewall, or is it publicly reachable? That distinction determines whether you need on-premises infrastructure at all. The corporate SQL Server is only accessible on the private network, so it requires a standard on-premises data gateway — there's no way around it. The Azure SQL Database, however, is publicly accessible, meaning Power BI's cloud service can reach it directly without routing traffic through any on-premises hardware. This is exactly what a cloud connection is designed for. Answer A correctly installs exactly one on-premises gateway (for the corporate SQL Server) and uses a native cloud connection for Azure SQL — satisfying both refresh requirements with the minimum possible infrastructure. Answer B is wasteful and unnecessary: deploying a second standard gateway for Azure SQL adds hardware and maintenance overhead when no on-premises gateway is needed for a publicly accessible source. Answer C gets the logic entirely backwards — a personal-mode gateway is designed for individual use, doesn't support scheduled refresh in shared workspaces reliably, and would be the wrong tool even if the placement were correct; additionally, Azure SQL doesn't need any gateway. Answer D forces all refresh traffic through the corporate network even for Azure SQL, which introduces unnecessary latency, a single point of failure, and extra infrastructure with zero benefit. A handy rule of thumb: on-premises gateway = private/firewall-protected source; cloud connection = publicly reachable source. Match each data source to only the infrastructure it actually needs.

Question 2

A business intelligence team publishes several semantic models that import data from the same on-premises Oracle database. Refreshes must continue when individual developers are signed out, and gateway administration must be shared among multiple team members.

Which gateway deployment should the team use?

  1. Install personal-mode gateways on each developer's computer and assign the same Oracle credentials to every installation.
  2. Install one personal-mode gateway on an always-on server and share its connections with the semantic model owners.
  3. Install a standard-mode gateway on an always-on computer and grant the appropriate users access to its Oracle connection. (correct answer)
  4. Install a standard-mode gateway on each developer's computer and bind each semantic model to its owner's installation.
Explanation: When a Power BI question involves shared data refresh and team-based administration, you should immediately think about the two gateway modes: personal and standard (enterprise). The key differences are that personal-mode gateways tie to a single signed-in user, cannot be shared, and are designed for individual use — while standard-mode gateways run as a Windows service, stay active independently of any user's sign-in status, and support multiple administrators and shared connections. Option C is correct because a standard-mode gateway installed on an always-on machine (like a dedicated server) satisfies every requirement: refreshes continue even when developers are signed out, and multiple team members can be granted admin or connection access through the Power BI service gateway management page. Option A fails on two counts: personal-mode gateways cannot be shared or jointly administered, and tying refreshes to individual developer machines means they stop whenever that machine is offline or the user signs out. Option B seems appealing — putting it on an always-on server sounds smart — but personal-mode gateways still cannot be shared with other users or co-administered, regardless of where they're installed. One person owns it, period. Option D uses the correct gateway mode (standard) but installs it on each developer's individual computer, which reintroduces the availability problem and defeats the purpose of centralized administration. A useful rule of thumb: if a question mentions sharing, team access, or unattended refresh, the answer almost always involves a standard-mode gateway. Personal mode exists for single-developer, ad hoc scenarios only.

Question 3

A scheduled refresh through a standard on-premises data gateway begins failing after a SQL login password expires. The gateway remains online, other connections using the same gateway continue to refresh, and the affected Power BI Desktop file refreshes after its author enters the new password locally.

What should the administrator do to restore the scheduled refresh?

  1. Restart the gateway service so that it imports the updated credential from the author's Power BI Desktop file.
  2. Republish the semantic model so that the new SQL password is embedded in the published Power Query definitions.
  3. Change the gateway Windows service account to the SQL login whose password was updated by the report author.
  4. Update and validate the stored credentials for the affected gateway connection in the Power BI service. (correct answer)
Explanation: When a scheduled refresh fails in Power BI service, your first instinct should be to separate the gateway infrastructure from the data source credentials stored in the service. These are two distinct layers, and the question gives you a clear clue: the gateway is online and other connections still work. That eliminates any gateway-level problem immediately. The root cause here is that Power BI service stores credentials for each data source connection independently, in an encrypted credential store managed through the service portal. When a SQL login password changes, those stored credentials become stale. The fix is straightforward — navigate to the semantic model's gateway connection settings in Power BI service, re-enter the updated SQL credentials, and validate them. This is exactly what option D describes, and it's the correct answer. Option A is wrong because the gateway service process has no awareness of Power BI Desktop files on the author's machine — they are completely separate applications. Restarting the gateway would accomplish nothing here. Option B is a dangerous misconception: Power Query definitions do not embed passwords in published models. Republishing would not transfer the new credential, and doing so is not how credential management works in Power BI service at all. Option C confuses two unrelated concepts — the gateway's Windows service account handles the gateway process itself, not SQL login authentication for individual data sources. Swapping service accounts would not update a SQL password. A useful pattern to remember: in Power BI, credential problems are always solved at the service level, not the Desktop level or gateway service level. If credentials expire, the fix lives in the dataset settings inside Power BI service.

Question 4

A company plans to install an on-premises data gateway in a restricted network segment. Security policy blocks unsolicited inbound internet connections but permits approved outbound connections. The gateway computer can reach the internal data sources.

Which network change is generally required for the gateway to communicate with the Power BI service?

  1. Permit inbound connections from the Power BI service to the gateway computer and block all outbound gateway traffic.
  2. Permit the gateway's required outbound connections to Microsoft endpoints without creating an unsolicited inbound route. (correct answer)
  3. Publish the internal database port to the internet so that Power BI can bypass the gateway during scheduled refresh.
  4. Permit inbound connections directly to each internal data source while restricting the gateway to local network traffic.
Explanation: When you see a question about on-premises data gateway networking, the key concept to anchor on is connection direction. The gateway is designed specifically to work in environments where inbound internet connections are blocked — it solves this problem by initiating outbound connections itself, then using those persistent connections to relay data back and forth with the Power BI service. This is why B is correct. The gateway computer establishes outbound connections to Microsoft's Azure Service Bus endpoints. Power BI "responds" through those already-open channels rather than initiating a new inbound connection to your network. Your firewall only needs to allow the gateway's outbound traffic to specific Microsoft URLs and ports — no holes need to be punched inward. A gets the direction completely backwards. Requiring inbound connections from Power BI defeats the entire architectural purpose of the gateway, which exists precisely to avoid exposing your network to unsolicited inbound traffic. C describes a dangerous misconfiguration — directly publishing a database port to the internet eliminates the security layer the gateway provides and would bypass the gateway entirely, not assist it. D confuses the gateway's role: the gateway sits between Power BI and internal sources, so restricting the gateway to local-only traffic would sever its connection to the Power BI service, making refresh impossible. A useful study tip: on Power BI exam questions about the on-premises data gateway, always ask yourself "who initiates the connection?" The answer is always the gateway reaching out, never Power BI reaching in. This single principle eliminates most distractor answers you'll encounter.

Question 5

A company has one standard on-premises data gateway that supports several critical refreshes. Maintenance of the gateway server currently interrupts all refreshes. The company wants another gateway computer to take over automatically while retaining centrally managed connections.

What should the administrator do?

  1. Install another standard gateway and add it to the existing gateway cluster by using the cluster's recovery key. (correct answer)
  2. Install a personal-mode gateway and configure it with the same data source names as the existing standard gateway.
  3. Install another standard gateway as an unrelated cluster and expect semantic models to switch clusters automatically.
  4. Clone the current gateway computer while it is running and operate both clones with the same machine identity.
Explanation: When you see a question about gateway high availability in Power BI, think about how clustering works: a gateway cluster allows multiple gateway machines to share the same logical identity and connections, so if one node goes down, another automatically handles the load — all without changing anything in your semantic models or data source configurations. This is exactly why A is correct. Installing a second standard gateway and joining it to the existing cluster using the cluster's recovery key makes it a peer node in that same logical gateway. Power BI treats the cluster as a single unit, round-robins or failovers between nodes automatically, and all centrally managed connections remain intact. No reconfiguration of reports or datasets is needed. B is wrong because personal-mode gateways are isolated to a single user account, cannot join clusters, and aren't designed for shared enterprise use. Matching data source names doesn't create any automatic failover relationship between two separate gateways. C is wrong because semantic models are bound to a specific gateway cluster — they do not automatically detect or switch to an unrelated cluster. You would have to manually reassign every dataset, which defeats the purpose of seamless failover and breaks centralized management. D is wrong for both practical and architectural reasons. Running two machines with the same identity causes conflicts rather than failover. This isn't a supported configuration and would likely corrupt connectivity rather than provide redundancy. Study tip: Remember that the recovery key is the mechanism that ties a new gateway installation into an existing cluster — any question about adding gateways for redundancy should immediately make you think "cluster + recovery key."

Question 6

A Power BI semantic model uses DirectQuery against an on-premises SQL Server database. Users must be able to open reports throughout the business day and retrieve current database results. The organization initially proposes installing a personal-mode gateway and scheduling one refresh each morning.

Which configuration correctly supports the requirement?

  1. Use personal mode and increase the scheduled refresh frequency so cached DirectQuery results remain current during the day.
  2. Use a standard gateway that remains online whenever reports can issue DirectQuery requests to the on-premises database. (correct answer)
  3. Use either gateway mode because DirectQuery requires connectivity only when the semantic model is published or refreshed.
  4. Use a standard gateway that starts only during a scheduled refresh and shuts down after imported data is updated.
Explanation: When you see a question combining DirectQuery and on-premises gateways, the central concept to anchor on is when DirectQuery actually queries the database. Unlike Import mode, DirectQuery sends a live query to the source every time a user opens or interacts with a report — not just during a scheduled refresh window. This means your gateway must be continuously available, not just present at a specific time of day. That's exactly why B is correct. A standard (enterprise) gateway that stays online throughout the business day ensures that every report request can pass through to the SQL Server database in real time, which is precisely what DirectQuery demands. A is built on a false premise: DirectQuery doesn't cache results that need periodic refreshing. There is no "cached DirectQuery result" to keep current — each interaction triggers a fresh query. Scheduling more frequent refreshes doesn't change this architecture at all. C contains a critical misconception. DirectQuery does not only need connectivity at publish or refresh time. It requires an active gateway connection every single time a user opens or interacts with a report. Assuming otherwise would mean users see errors or stale data whenever the gateway is offline. D describes Import mode behavior, not DirectQuery. Shutting down the gateway after a scheduled data import would work fine for Import mode, but DirectQuery has no local data store to fall back on — the gateway must remain running for any live query to succeed. Your study tip: memorize the key distinction — Import = refresh-time connectivity, DirectQuery = always-on connectivity. Exam questions often hide this difference inside gateway configuration scenarios exactly like this one.

Question 7

A gateway administrator creates and successfully tests an on-premises PostgreSQL connection. A report author publishes a semantic model whose server and database values exactly match the connection. However, the author cannot select the connection in the semantic model settings. Other authorized users can select it.

What should the gateway administrator do?

  1. Add the report author as an administrator of every workspace that contains a semantic model using the gateway.
  2. Change the PostgreSQL credentials to the report author's personal database credentials and test the connection again.
  3. Transfer semantic model ownership to the gateway administrator so that connection permissions are no longer evaluated.
  4. Grant the report author permission to use the PostgreSQL gateway connection and then configure the semantic model mapping. (correct answer)
Explanation: When working with on-premises data gateways in Power BI, it helps to think in two layers: who can administer the gateway and who can use individual connections on that gateway. These are separate permission levels, and a gap in either one blocks a user from completing their data source mapping. In this scenario, the gateway and connection are functioning correctly — other authorized users can select the connection. The problem is isolated to one user: the report author. This points directly to a missing "Can use" permission on that specific connection. The gateway administrator must explicitly grant the report author permission to use the PostgreSQL connection (via the gateway's connection settings in the Power BI service), and then the author can map their semantic model to it. That's exactly what D describes, making it the correct answer. A is wrong because workspace administrator rights govern who can manage content in a workspace, not who can use gateway connections. Adding someone as a workspace admin wouldn't grant gateway connection access. B is a security and governance problem — swapping to the author's personal credentials changes the shared connection to personal credentials, breaks it for all other users, and doesn't address the permission gap at all. C is a misconception: transferring semantic model ownership doesn't bypass connection permission checks. Permissions are still evaluated at the gateway level regardless of who owns the semantic model. A useful study tip: on gateway questions, always distinguish between gateway administrator rights, connection-level "Can use" permissions, and workspace roles — Power BI evaluates all three independently, and exam questions often exploit confusion between them.

Question 8

An import-mode semantic model reads an on-premises CSV file from Z:\Finance\Rates.csv. The mapped Z: drive exists in the analyst's interactive Windows session. A standard gateway installed on a server is online, but refresh fails because the gateway cannot locate the file.

Which change is most likely to provide reliable scheduled refresh?

  1. Create the same Z: mapping while signed in interactively to the gateway server, and then sign out before refresh runs.
  2. Copy the CSV path into the gateway's display name so that Power BI can reconstruct the mapped drive automatically.
  3. Use a UNC path to the shared file and ensure the gateway connection's credentials can access that network location. (correct answer)
  4. Store the mapped-drive password in the semantic model parameters and keep the original Z: path in Power Query.
Explanation: When troubleshooting gateway refresh failures in Power BI, the core issue is almost always about how the gateway service account resolves file paths. The gateway runs as a Windows service in a non-interactive background session — it doesn't share your desktop environment, your mapped drives, or your interactive logon context. A mapped drive like Z: is a user-session-level construct. It only exists while a specific user is logged in interactively. The gateway service runs under its own service account, which has no knowledge of your Z: mapping. That's exactly why refresh fails. The fix is to use a UNC path (e.g., \\server\Finance\Rates.csv) instead, because UNC paths are resolved at the network level and don't depend on any user's interactive session. You also need to configure the gateway data source credentials so the gateway's service account can authenticate to that network share — making option C the correct and reliable solution. Option A fails because mapping a drive interactively on the gateway server and then signing out destroys the very mapping you just created; it won't persist into the background service session. Option B is nonsensical — the gateway's display name is a cosmetic label for the Power BI portal, not a mechanism that reconstructs drive mappings or changes path resolution. Option D stores credentials in model parameters but keeps the broken Z: path intact, so the gateway still can't locate the file regardless of what parameters are defined. As a study tip: whenever you see a question involving scheduled refresh and file paths on this exam, immediately ask yourself "Will the gateway's service account be able to resolve this path independently?" If the answer requires an interactive session, it's wrong.

Question 9

A standard on-premises data gateway is installed in a perimeter network. Its status in the Power BI service is Online because it can contact Microsoft endpoints. Scheduled refresh nevertheless fails when the semantic model queries an internal SQL Server. A network test confirms that the gateway computer cannot establish a connection to that SQL Server.

Which action addresses the underlying problem?

  1. Open an inbound connection from the Power BI service directly to SQL Server so that refresh can bypass the online gateway.
  2. Install Power BI Desktop on the gateway computer so that Desktop can relay each service query to SQL Server.
  3. Provide network routing from the gateway computer to SQL Server or relocate the gateway to a host that can reach both sides. (correct answer)
  4. Disable privacy-level checks in the semantic model because privacy settings determine whether the gateway can route IP traffic.
Explanation: When troubleshooting gateway-related refresh failures in Power BI, always separate two distinct network paths: the gateway-to-Microsoft-cloud path and the gateway-to-data-source path. A gateway shows "Online" only because it successfully contacts Microsoft's endpoints — that status says nothing about whether it can reach your internal data sources. In this scenario, the gateway is healthy from Power BI's perspective, but the real bottleneck is the missing network route between the gateway host and the SQL Server. The on-premises data gateway works by sitting inside your network, receiving queries from the Power BI service, and then forwarding them to the data source on Power BI's behalf. If that second leg — gateway to SQL Server — is broken, refresh fails regardless of gateway status. C is correct because it fixes the actual broken link: either add a network route so the gateway can reach SQL Server, or move the gateway to a machine that already has access to both the internet and the internal SQL Server. A is wrong because the gateway architecture intentionally avoids inbound connections from the cloud to your internal network. Power BI never connects directly to on-premises sources — that would defeat the security purpose of the gateway entirely. B is wrong because Power BI Desktop is an authoring tool, not a query relay service. Installing it on the gateway machine has no effect on how the gateway routes traffic. D is wrong because privacy levels control data mashup isolation in Power Query — they have no bearing on TCP/IP routing or whether a machine can reach a network host. For exam questions like this, remember: gateway "Online" status ≠ data source reachability. Always trace the full data path end-to-end.

Question 10

A Power BI Desktop file connects to an on-premises database by using the server value FINSQL and database value Ledger. The gateway administrator creates a SQL Server connection that uses finsql.contoso.com and Ledger. Both server names resolve to the same physical server, but the Power BI service does not offer the connection for the published semantic model.

What is the least disruptive action that should make the gateway connection available?

  1. Rename the gateway connection's display name to FINSQL while leaving its configured server value unchanged.
  2. Create a gateway connection whose configured server and database values match FINSQL and Ledger as used by the semantic model. (correct answer)
  3. Change the gateway Windows service account so that the service account name matches the SQL Server host alias.
  4. Add both server names to the semantic model's data source credentials and let Power BI select either endpoint.
Explanation: When Power BI tries to match a published semantic model to an available gateway connection, it performs an exact string match on the server and database values configured in the data source. There is no DNS resolution or alias lookup — if the strings don't match character-for-character, Power BI will not offer that connection, even if both names physically point to the same server. That's exactly the scenario here. The semantic model uses FINSQL and Ledger, but the existing gateway connection was created with finsql.contoso.com and Ledger. Because the server strings differ, Power BI treats them as entirely separate data sources and refuses to map them. The fix is straightforward: create a new gateway connection using exactly FINSQL and Ledger to match what the semantic model expects. This is answer B, and it's the least disruptive path because it adds a connection without modifying the original semantic model or breaking anything already working. A is a trap — the display name of a gateway connection is just a label for human readability. It has no effect on how Power BI matches data sources. Renaming it to FINSQL changes nothing functional. C is a red herring; the Windows service account controls permissions and authentication, not how data source strings are matched. Changing it would be disruptive and irrelevant to this problem. D describes a feature that doesn't exist in Power BI — you cannot supply multiple server endpoints for a single data source credential and let the service choose between them. Remember this rule for the exam: gateway matching is always exact string comparison on server and database values — DNS aliases, IP addresses, and display names are invisible to that process.