- Which action addresses the underlying problem?
Answer: Provide network routing from the gateway computer to SQL Server or relocate the gateway to a host that can reach both sides.
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.
- What is the least disruptive action that should make the gateway connection available?
Answer: Create a gateway connection whose configured server and database values match FINSQL and Ledger as used by the semantic model.
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.
- Which network change is generally required for the gateway to communicate with the Power BI service?
Answer: Permit the gateway's required outbound connections to Microsoft endpoints without creating an unsolicited inbound route.
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.
- Which configuration correctly supports the requirement?
Answer: Use a standard gateway that remains online whenever reports can issue DirectQuery requests to the on-premises database.
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.
- What should the gateway administrator do?
Answer: Grant the report author permission to use the PostgreSQL gateway connection and then configure the semantic model mapping.
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.
- What should the administrator do?
Answer: Install another standard gateway and add it to the existing gateway cluster by using the cluster's recovery key.
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."
- What should the administrator do to restore the scheduled refresh?
Answer: Update and validate the stored credentials for the affected gateway connection in the Power BI service.
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.
- Which gateway deployment should the team use?
Answer: Install a standard-mode gateway on an always-on computer and grant the appropriate users access to its Oracle connection.
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.
- Which gateway configuration meets the requirement with the least on-premises infrastructure?
Answer: Install one standard on-premises data gateway for the corporate SQL Server model and use a cloud connection for the Azure SQL model.
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.
- Which change is most likely to provide reliable scheduled refresh?
Answer: Use a UNC path to the shared file and ensure the gateway connection's credentials can access that network location.
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.
