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

On a locked-down network, gateway traffic reaches Power BI by using what?

Inbound HTTPS on port 443
Outbound to Azure Service Bus
A VPN tunnel to the tenant
Dynamic inbound port mapping
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Using Gateways

Practice Using 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 Using 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

On a locked-down network, gateway traffic reaches Power BI by using what?

  1. Inbound HTTPS on port 443
  2. Outbound to Azure Service Bus (correct answer)
  3. A VPN tunnel to the tenant
  4. Dynamic inbound port mapping
Explanation: The gateway keeps a long-lived outbound connection to Azure Service Bus, so data requests from Power BI travel over that already-established channel. You don't need to open inbound HTTPS on 443 because the gateway initiates all traffic; the tempting inbound-port option would require opening your firewall to outside connections, which a locked-down network won't allow.

Question 2

A gateway is installed. Before scheduling refresh, which gateway-side task is required?

  1. Set row-level security rules
  2. Choose an import storage mode
  3. Add source and credentials (correct answer)
  4. Define the refresh schedule
Explanation: Before the gateway can refresh anything, it must know which data source to connect to and with what credentials. Setting row-level security or storage mode happens on the dataset, not the gateway side. The tempting wrong answer is defining the refresh schedule, but that comes only after the gateway has the source and credentials configured.

Question 3

A coworker cannot see an analyst's personal-mode gateway in the service. Why?

  1. It cannot perform refresh
  2. It only supports cloud data
  3. It is bound to one account (correct answer)
  4. It must run in a cluster
Explanation: A personal-mode gateway is tied to the account that installed it, so the service only shows it to that analyst. Your coworker won't see it because it isn't shared or registered for their identity. The tempting option 'it only supports cloud data' is wrong because personal gateways handle on-premises sources; the real issue is account ownership.

Question 4

A dataset refreshes via a shared gateway. The author's laptop is off. What happens?

  1. Runs if the gateway is online (correct answer)
  2. Fails until the owner signs in
  3. Fails unless the laptop is on
  4. Runs only for DirectQuery data
Explanation: A shared gateway runs on its own server, not the author's laptop. The refresh job is executed by the Power BI service through the gateway, so the laptop being off doesn't matter as long as the gateway is online. The tempting error is assuming the refresh depends on the laptop that authored the report, but a shared gateway removes that dependency.

Question 5

A dataset blends a cloud CRM with on-prem Excel files. Which refresh path needs the gateway?

  1. Both sources in the dataset
  2. Only the cloud CRM source
  3. Neither after Desktop publish
  4. Only the on-prem Excel data (correct answer)
Explanation: Gateway bridges your Power BI service to data that isn't in the cloud. Only the on-prem Excel files reside on your local network, so they need the gateway to refresh. The cloud CRM already lives online and refreshes directly. The tempting mistake is choosing both sources, but that would drag a cloud source through unnecessary on-prem hardware.

Question 6

A financial analyst creates an import-mode semantic model by connecting Power BI Desktop to the on-premises SQL Server instance SQL01\FIN and database FinanceDW. The analyst publishes the model to the Power BI service. An administrator has already installed and registered a standard on-premises data gateway that can reach the SQL Server.

What should the administrator do next to enable scheduled refresh?

  1. Create a gateway connection for the same server and database, store valid source credentials, and associate the semantic model with that connection. (correct answer)
  2. Install another gateway directly on the SQL Server, publish the analyst's Windows credentials, and assign the gateway to the workspace.
  3. Configure the semantic model to use DirectQuery, copy the gateway recovery key into Desktop, and republish the report.
  4. Create a personal-mode gateway for the analyst, transfer ownership to the workspace, and remove the existing standard gateway.
Explanation: When you see a question about scheduled refresh in Power BI, think through the three-layer requirement: a gateway that can reach the source, a defined connection (server + database + credentials) within that gateway, and the semantic model linked to that connection. All three must be in place before refresh can run. Answer A is correct because it completes exactly those missing pieces. The gateway already exists and can reach SQL01\FIN, so the administrator's remaining work is to create a data source connection inside that gateway — specifying the same server name and database name that Power BI Desktop used — store valid credentials (SQL or Windows), and then map the published semantic model to that connection. Power BI matches the model's source metadata to the gateway connection, and scheduled refresh becomes available. Answer B is wrong on multiple counts: you don't need a second gateway installed on the SQL Server itself, and publishing a user's Windows credentials isn't a supported or secure configuration step. Assigning a gateway to a workspace is also not how gateway association works — it's done at the dataset level. Answer C conflates two unrelated concepts. Changing to DirectQuery is a fundamental modeling decision that affects how data is queried, not a prerequisite for refresh, and copying a recovery key into Desktop has no effect on enabling scheduled refresh for an import-mode model. Answer D describes personal-mode gateways, which are designed for individual users and can't be transferred to workspace ownership or replace a standard gateway — making this both procedurally wrong and architecturally unsound. Your study tip: memorize the three-step mantra — gateway installed → data source connection created → semantic model associated. Exam distractors almost always break one of these steps or swap in an unrelated concept like DirectQuery or personal gateways.

Question 7

A company uses one standard on-premises data gateway for several business-critical semantic models. The gateway is installed on a virtual machine that occasionally restarts for maintenance. The company wants refreshes to continue automatically during a single gateway-machine outage without reconfiguring each semantic model.

What should the company implement?

  1. Install another standard gateway as a member of the existing gateway cluster and configure it to reach the same data sources. (correct answer)
  2. Install an independent standard gateway and configure each semantic model to alternate between the two gateway names.
  3. Install personal-mode gateways for the model owners and use them whenever the standard gateway becomes unavailable.
  4. Export the gateway recovery key to each workspace so the Power BI service can recreate the gateway during an outage.
Explanation: When you see a question about gateway availability and automatic failover in Power BI, think about gateway clusters — this is the feature specifically designed to eliminate single points of failure without requiring manual reconfiguration. A standard gateway cluster lets you install multiple gateway members that Power BI treats as a single logical gateway. When one member goes offline, the service automatically routes refresh requests to another available member. This means all your semantic models stay pointed at the same gateway name — no reconfiguration needed. Option A is correct because adding a second standard gateway as a cluster member is exactly this mechanism: it provides transparent failover to the same data sources during a machine outage. Option B describes manually alternating between two independently named gateways. This requires reconfiguring each semantic model to switch gateways — precisely the scenario the company wants to avoid, and Power BI has no built-in "alternating" feature anyway. Option C introduces personal-mode gateways, which are single-user, non-clusterable, and cannot be shared across an organization's semantic models. They're meant for individual, ad hoc use — not enterprise reliability scenarios. Option D is a common distractor that misrepresents the recovery key's purpose. The recovery key is used to migrate or restore a gateway configuration to a new machine — it doesn't allow the Power BI service to auto-recreate a gateway during an outage. Study tip: On the PL-300/DA-100 exam, gateway clustering questions almost always revolve around high availability and zero-reconfiguration failover. Remember: clusters = same logical name, automatic routing — that's your signal to choose the cluster answer.

Question 8

An import-mode semantic model completes a scheduled refresh at 6:00 AM through an on-premises data gateway. At 8:00 AM, the gateway server loses power. At 9:00 AM, users open reports based only on that semantic model. The next scheduled refresh is at noon.

What should users and administrators expect before the noon refresh?

  1. Reports will fail immediately because every report interaction must reconnect through the gateway to the on-premises source.
  2. Reports will switch automatically to DirectQuery and retrieve current data by connecting around the unavailable gateway.
  3. Reports will display empty visuals because the Power BI service removes imported data when a gateway becomes unavailable.
  4. Reports will continue using the data imported at 6:00 AM, but the noon refresh will fail if the gateway remains unavailable. (correct answer)
Explanation: When you see a question about gateways and semantic models, the key distinction to keep in mind is what role the gateway actually plays at query time versus refresh time. The gateway is only needed to pull fresh data from the on-premises source — once data is imported into Power BI's cloud service, it lives there independently until the next refresh overwrites it. That's exactly why D is correct. The 6:00 AM refresh successfully completed before the gateway went offline at 8:00 AM, meaning a full snapshot of data is already stored in the Power BI service. When users open reports at 9:00 AM, they're querying that cached dataset in the cloud — no gateway required. Reports will load and function normally. However, when noon arrives and Power BI attempts to pull new data from the on-premises source, the gateway is the required bridge, and without it, that refresh will fail. Answer A describes DirectQuery behavior, not import mode. In DirectQuery, every interaction does require a live connection through the gateway — but import mode doesn't work that way. Answer B is doubly wrong: Power BI doesn't automatically switch storage modes, and even if it could, there's no gateway to connect through anyway. Answer C reflects a misunderstanding of how import mode stores data — the Power BI service doesn't purge imported data just because the gateway goes down; the data remains in the cloud until the next successful refresh replaces it. Your study tip: always ask yourself "when does the gateway matter?" For import mode, the answer is only during refresh — not during report consumption.

Question 9

A company uses DirectQuery through a standard gateway to an on-premises SQL Server. The gateway connection currently uses one stored database account. Security requires SQL Server to authorize and audit queries according to the identity of each report viewer rather than recording every query under the shared account.

Which gateway-related configuration most directly supports the requirement?

  1. Enable scheduled refresh so the gateway records each viewer's Power BI identity while importing rows into the semantic model.
  2. Configure supported Kerberos single sign-on through the gateway, including user principal name mapping when identities differ. (correct answer)
  3. Change the gateway Windows service account for each report session so SQL Server receives the current viewer's identity.
  4. Give every viewer gateway-administrator permission so the stored database connection executes under that viewer's credentials.
Explanation: When a question asks how to make SQL Server authorize and audit by individual user identity over a gateway connection, you should immediately think about single sign-on (SSO). The core problem is that a shared service account collapses all viewers into one identity — SSO is the mechanism that passes each viewer's actual identity through to the data source. Kerberos SSO through the Power BI gateway does exactly this. When configured correctly, the gateway impersonates each report viewer and forwards their identity to SQL Server via Kerberos delegation. SQL Server then sees — and can audit — each individual user's queries. UPN mapping handles cases where the Power BI identity (e.g., user@company.com) doesn't match the on-premises domain format, ensuring the delegation succeeds even in hybrid environments. Option B describes this precise, supported configuration. Option A is wrong because scheduled refresh is an import mode feature. It pulls data into Power BI's in-memory model on a schedule and has no mechanism for per-viewer identity passthrough — it always runs under a single service credential. Option C describes something that is operationally impossible and unsupported. The gateway Windows service account is a static configuration; you cannot swap it per report session. This would also break all concurrent connections. Option D conflates gateway-administrator permissions with data-source credentials. Making every viewer a gateway admin grants them infrastructure control over the gateway itself, not per-user SQL Server authentication. Your study tip: whenever you see per-user identity + DirectQuery + on-premises source, SSO (specifically Kerberos for Windows/SQL sources) is almost always the answer Power BI exam questions are looking for.

Question 10

Scheduled refreshes begin failing with an authentication error immediately after the password for a database account is rotated. The gateway remains online, and the gateway Windows service account has not changed. Several semantic models use the same gateway connection and all are affected.

What should an administrator update first?

  1. The credentials saved in each PBIX file, followed by republishing every report that uses the database account.
  2. The stored data-source credentials for the shared gateway connection used by the affected semantic models. (correct answer)
  3. The Windows service account running the gateway, using the new database password as its service password.
  4. The gateway recovery key, because it encrypts and authenticates every request sent to the database.
Explanation: When a scheduled refresh fails with an authentication error right after a password rotation, your first instinct should be to ask: where are those credentials stored? In Power BI, when multiple semantic models share a gateway data source, their credentials are stored centrally in the Power BI service — not inside individual PBIX files. That central credential store is exactly where the stale password lives. Updating the stored data-source credentials for the shared gateway connection (B) is the correct first action. Because all affected models point to the same gateway connection, a single credential update in the Power BI service fixes all of them simultaneously. The gateway itself is healthy — it's just passing along credentials that no longer match the rotated database password. Choice A is a trap rooted in a common misconception. Credentials for a gateway-based data source are not embedded in PBIX files; they live in the service. Re-publishing every report would waste time and fix nothing, because the underlying gateway connection credentials would remain stale. Choice C confuses two separate accounts. The Windows service account runs the gateway process itself — it has nothing to do with authenticating against a database. Changing its "password" to match the database password would break the gateway service and wouldn't resolve the authentication error. Choice D misrepresents the gateway recovery key. That key is used to back up and restore gateway configurations, not to authenticate database requests. Rotating it would not update credentials anywhere. Study tip: On Power BI exam questions, always distinguish between where credentials are stored (the service, not the file) and what the gateway service account controls (the gateway process, not database auth). This distinction appears frequently.

Question 11

An organization must retire the virtual machine hosting its standard gateway. Dozens of semantic models are mapped to connections on that gateway. The gateway administrator has the gateway name and recovery key and wants to avoid recreating all connections and model mappings.

Which migration procedure should the administrator use?

  1. Install the gateway on the replacement machine and use the migrate, restore, or takeover option with the existing gateway name and recovery key. (correct answer)
  2. Install a new gateway with a new name, import the recovery key as a data-source credential, and wait for mappings to synchronize.
  3. Copy the gateway installation directory to the replacement machine and register the copied Windows service with the Power BI workspace.
  4. Delete the existing gateway, install personal mode on the replacement machine, and transfer the semantic models to its owner.
Explanation: When migrating an on-premises data gateway to a new machine, the key concept to understand is that Power BI's gateway infrastructure is designed to support migration without losing existing connections or semantic model mappings — but only if you follow the correct procedure. The supported migration path, which makes A correct, is to install the gateway software on the replacement machine and, during setup, choose the migrate, restore, or takeover option. When you supply the original gateway name and recovery key, Power BI recognizes the gateway as the same logical entity. All existing data source connections and model mappings remain intact because the gateway identity is preserved, not recreated. B is wrong because importing a recovery key as a credential isn't a real feature — the recovery key is used during gateway setup to decrypt stored credentials, not imported separately afterward. Mappings also don't "synchronize" automatically to a brand-new gateway with a different name. C is wrong because the gateway isn't a portable installation. Simply copying files and reregistering a Windows service won't transfer the gateway's registered identity in the Power BI service. The gateway registration is cloud-side, not filesystem-side. D is wrong on multiple levels: deleting the gateway destroys all associated connections and mappings, and switching to personal mode is appropriate only for individual users, not organizational gateways serving dozens of shared semantic models. As a study tip, remember that for gateway questions on this exam, the recovery key is your signal — whenever it appears in a scenario, the answer almost certainly involves the migrate/restore/takeover flow during a fresh gateway installation.

Question 12

A department initially needs one analyst to refresh a private import-mode Power BI semantic model from an on-premises file. Six months later, several developers must manage shared connections, and a new report will use DirectQuery against an on-premises SQL Server.

Which gateway approach best satisfies both the current and anticipated requirements?

  1. Use personal mode and share the analyst's gateway credentials with the developers when the DirectQuery report is published.
  2. Use personal mode for the file and create a cloud connection without a gateway for the on-premises SQL Server.
  3. Use a standard on-premises data gateway so connections can be centrally managed and used for shared refresh and DirectQuery scenarios. (correct answer)
  4. Use separate personal-mode gateways for every developer and combine them into a gateway cluster for automatic failover.
Explanation: When a question describes a scenario that evolves from a single user's need to a team-wide, multi-scenario requirement, you should immediately think about scalability and centralized management — the core distinction between personal-mode and standard on-premises data gateways in Power BI. The standard on-premises data gateway (answer C) is the right fit here because it supports multiple users, allows centralized connection management by administrators, handles scheduled refresh for import-mode models, and — critically — supports DirectQuery against on-premises sources like SQL Server. It's designed exactly for organizational, shared workloads. Answer A fails on two fronts: personal-mode gateways cannot be shared between users, and credentials are tied to the individual who installed the gateway. Passing credentials around is both a security risk and technically unsupported — other developers cannot use someone else's personal gateway. Answer B contains a fundamental misunderstanding: on-premises SQL Server cannot be reached via a cloud connection. Cloud connections are for cloud-hosted data sources. Attempting DirectQuery against an on-premises SQL Server without a gateway simply won't work. Answer D is tempting if you know that standard gateways support clustering for high availability, but personal-mode gateways cannot be combined into a cluster. Clustering is a feature exclusive to standard mode gateways. This answer mixes a real feature with the wrong gateway type. As a study tip, remember the key dividing line: personal mode = one user, no DirectQuery, no sharing; standard mode = multiple users, DirectQuery supported, centrally managed. Any scenario mentioning teams or DirectQuery on-premises should immediately point you toward the standard gateway.

Question 13

A gateway server can query an on-premises database successfully, but the gateway is shown as offline in the Power BI service. A network security team allows internal database traffic but blocks nearly all Internet traffic. The team does not want to expose the gateway server to unsolicited Internet connections.

Which network change should be recommended?

  1. Open inbound SQL ports from the Power BI service to the gateway and forward those connections to the database server.
  2. Publish the database through a public endpoint so the Power BI service can bypass the gateway for refresh operations.
  3. Establish an inbound VPN initiated by the Power BI service and permit it to sign in with the gateway recovery key.
  4. Allow the gateway to initiate outbound connections to the required Microsoft endpoints and ports, without opening unsolicited inbound access. (correct answer)
Explanation: When troubleshooting an offline Power BI gateway, the key question to ask yourself is: who initiates the connection, and in which direction does traffic flow? The on-premises data gateway is deliberately designed as an outbound-only architecture. The gateway inside your network reaches out to Azure Service Bus relay endpoints — Microsoft never pushes inbound connections to it. This design exists precisely so organizations can support cloud connectivity without punching inbound holes in their firewall. Answer D is correct because it aligns with this architecture. Allowing the gateway to initiate outbound HTTPS/AMQP traffic to Microsoft's required endpoints (such as *.servicebus.windows.net on port 443 or 5671/5672) lets the gateway register itself as online and relay queries — all without exposing the server to unsolicited inbound Internet traffic. The security team's concern is fully respected. Answer A is wrong because it inverts the connection model. The Power BI service never initiates inbound SQL connections to your gateway; opening inbound SQL ports would also introduce a significant attack surface. Answer B is wrong because publishing a direct public database endpoint eliminates the entire purpose of the gateway and creates a far larger security exposure than the team would accept. Answer C describes a fictional mechanism — the Power BI service does not initiate VPN connections into customer networks, and the recovery key is used for restoring gateway configurations, not for authentication tunnels. As a study tip, remember this pattern for the exam: the on-premises data gateway is always the initiator of outbound connections. Any answer suggesting inbound connections from Microsoft's cloud to your network contradicts the gateway's fundamental design.

Question 14

A semantic model was developed using the SQL Server alias FinanceSQL and database Ledger. A gateway connection is configured with the physical server name SQL-PROD-07 and database Ledger. Both names resolve to the same server, but the Power BI service does not offer the connection for the semantic model. The PBIX file cannot currently be modified.

Which action is most likely to resolve the mapping problem with the least disruption?

  1. Add the analyst as a gateway administrator so the service can translate the server alias to the physical server name.
  2. Change the gateway Windows service account to the analyst's account so both source names share the same identity.
  3. Create a gateway connection that uses FinanceSQL and Ledger, ensuring that the gateway computer can resolve the alias. (correct answer)
  4. Create a second workspace in the gateway's region and move the semantic model there before configuring refresh.
Explanation: When the Power BI service tries to match a semantic model's data source to an available gateway connection, it performs an exact string match on the server name and database name. If your PBIX was built using the alias FinanceSQL but the only gateway connection lists SQL-PROD-07, Power BI sees two different strings and refuses to map them — even if both names resolve to the same physical server. Understanding this strict matching behavior is the key to solving gateway configuration problems like this one. The fix, as option C describes, is to create a new gateway connection that uses FinanceSQL as the server name and Ledger as the database. As long as the gateway machine can resolve FinanceSQL through DNS or a hosts file entry, it will reach the correct server. This mirrors the model's embedded connection string exactly, allowing Power BI to map them automatically — and requires no changes to the PBIX file. Option A is a trap: adding someone as a gateway administrator changes who can manage the gateway, not how source names are matched. Permissions don't affect string comparison logic. Option B is similarly off-base — the Windows service account controls what credentials the gateway uses to authenticate to the data source, not how connection strings are resolved or matched. Option D introduces unnecessary complexity; moving the semantic model to a different workspace doesn't change the data source string embedded in the model and solves nothing about the mismatch. As a study tip, remember: Power BI gateway matching is literal, not logical. Whenever you see a question about gateway configuration failures, immediately ask whether the server and database names in the connection string match the gateway data source entry character-for-character.

Question 15

During a common refresh window, a standard gateway server reaches very high CPU utilization while the on-premises databases remain responsive. Refreshes queue or time out. The organization wants to increase gateway processing capacity while preserving existing connection definitions and providing resilience if one host fails.

Which action best addresses the bottleneck?

  1. Move every semantic model to a larger Power BI workspace capacity because workspace capacity always performs the on-premises queries.
  2. Create an unrelated gateway for each semantic model so the Power BI service can discover and balance them automatically.
  3. Add appropriately sized gateway members to the existing cluster and enable distribution across active members where appropriate. (correct answer)
  4. Replace the standard gateway with personal mode because personal gateways dedicate one process to every scheduled refresh.
Explanation: When you see a gateway bottleneck question, focus on two goals: scaling capacity and preserving continuity. The on-premises data gateway cluster feature exists precisely for this scenario — you can add member nodes to an existing cluster, and the Power BI service will distribute refresh workloads across those members. This means CPU pressure is spread horizontally, existing connection definitions (which reference the cluster, not individual nodes) remain untouched, and if one node goes offline, others continue serving requests. That's exactly what C describes, making it the correct answer. A is wrong because workspace capacity (Premium or Fabric) handles in-cloud compute — it does not execute queries against on-premises sources. The gateway is still required for that leg of the query, so upgrading workspace capacity does nothing to relieve gateway CPU pressure. B describes creating entirely separate, unrelated gateways rather than a cluster. The Power BI service does not automatically discover and load-balance across independent gateways — each semantic model must be explicitly configured to use a specific gateway. You'd break existing connection definitions and gain no automatic failover. D is a trap for anyone who associates "dedicated process" with better performance. Personal mode gateways are designed for individual use, don't support enterprise scheduling across multiple users, and actually introduce more isolation — not shared cluster scaling. They cannot replace a standard gateway in a multi-model enterprise environment. Study tip: Remember that gateway clusters = horizontal scale + resilience + preserved connections. Any exam question combining "high load," "failover," and "no reconnection work" is pointing at cluster expansion.