Microsoft Power BI Quiz: Desktop Vs Service Vs Mobile
10 questions · exam conditions
0:00
Desktop Vs Service Vs MobileQuestion 1 of 10

A report imports data from an on-premises SQL Server. The report was refreshed successfully in Power BI Desktop and then published. The analyst closes the laptop each evening, but the published semantic model must refresh overnight.

What should be configured?

A recurring refresh in Power BI Desktop, with the PBIX stored in a workspace that Power BI Mobile can reach overnight.
An on-premises data gateway on an available computer, plus credentials and scheduled refresh in the Power BI service.
A refresh schedule in Power BI Mobile, with the SQL credentials stored in the mobile application's local settings.
Automatic republishing from Power BI Desktop, with the analyst's laptop configured to reopen the PBIX before each refresh.
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Desktop Vs Service Vs Mobile

Practice Desktop Vs Service Vs Mobile 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 Desktop Vs Service Vs Mobile, 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 report imports data from an on-premises SQL Server. The report was refreshed successfully in Power BI Desktop and then published. The analyst closes the laptop each evening, but the published semantic model must refresh overnight.

What should be configured?

  1. A recurring refresh in Power BI Desktop, with the PBIX stored in a workspace that Power BI Mobile can reach overnight.
  2. An on-premises data gateway on an available computer, plus credentials and scheduled refresh in the Power BI service. (correct answer)
  3. A refresh schedule in Power BI Mobile, with the SQL credentials stored in the mobile application's local settings.
  4. Automatic republishing from Power BI Desktop, with the analyst's laptop configured to reopen the PBIX before each refresh.
Explanation: When a Power BI report connects to an on-premises data source like SQL Server, data cannot flow directly to the Power BI cloud service on its own — something must bridge the gap between the private network and the internet. That bridge is the on-premises data gateway. Whenever you see a question combining on-premises sources with scheduled cloud refresh, your first instinct should be: "A gateway is required." Option B is correct because it addresses every piece of the puzzle. Installing a gateway on a machine that stays powered on overnight keeps the connection available. Storing credentials in the Power BI service lets it authenticate against SQL Server, and configuring a scheduled refresh in the service triggers the refresh automatically — no analyst involvement needed. Option A is wrong because Power BI Desktop cannot run scheduled refreshes on its own, and storing a PBIX in a workspace doesn't enable cloud refresh. Power BI Mobile has nothing to do with orchestrating refresh jobs. Option C is wrong for similar reasons. Power BI Mobile is a consumption app for viewing reports — it has no mechanism to schedule dataset refreshes or store SQL credentials for server-side operations. Option D is wrong because Power BI Desktop republishing requires a human (or a complex automation outside Power BI's native tools) and does not solve the gateway requirement for on-premises connectivity. Reopening a PBIX on a laptop that's closed each evening is also physically impossible without additional IT infrastructure. Study tip: Memorize this rule — on-premises source + cloud refresh = on-premises data gateway, always. This combination appears frequently on the PL-300 exam and the answer almost always involves a gateway.

Question 2

A semantic model must restrict sales rows by region. A developer will write the role filter, an administrator will place users into the appropriate roles, and salespeople will view the report in browsers and on phones.

Which assignment of responsibilities correctly reflects the Power BI workflow?

  1. Define and test the roles in Power BI Desktop, assign users to the published roles in the Power BI service, and let Mobile enforce the service identity. (correct answer)
  2. Define the roles in Power BI Mobile, assign users in Power BI Desktop, and publish the phone-specific security rules to the service.
  3. Define and assign every role in Power BI Desktop, embed the user list in the PBIX, and have Mobile validate local device accounts.
  4. Define role membership in the Power BI service, download it into Desktop as DAX, and disable row filters for users of Power BI Mobile.
Explanation: When you see a question about Row-Level Security (RLS) in Power BI, think about the three-stage workflow: define → assign → consume. Each stage happens in a specific tool, and mixing them up is a common source of confusion. The correct workflow, captured in A, is that developers define and test RLS roles (including DAX filter expressions) inside Power BI Desktop before publishing. Once the report is published to the Power BI service, administrators assign users or groups to those roles through the service's security settings — Desktop has no mechanism for managing live user accounts. Finally, when salespeople access the report through browsers or Power BI Mobile, the service authenticates their identity and enforces the role automatically. Mobile doesn't apply separate or local security rules; it inherits everything from the service. B is wrong because roles cannot be defined in Power BI Mobile — Mobile is a read-only consumption app with no authoring or security configuration capability. C is wrong for two reasons: user assignment is never embedded inside a PBIX file (it would be a security nightmare to ship user lists inside a report file), and Mobile does not validate local device accounts independently. D reverses the workflow entirely — role membership is not defined in the service and downloaded as DAX into Desktop; the DAX filter expressions originate in Desktop and are published upward to the service. A good memory aid: think Desktop = design, Service = assign, Mobile = consume. On the exam, any answer that assigns authoring or user-management tasks to Mobile is almost certainly a distractor.

Question 3

A developer publishes a report from Power BI Desktop. The next day, the developer adds a measure and replaces one visual in the local PBIX but does not publish again. A scheduled refresh of the existing semantic model then succeeds in the Power BI service.

What will users see when they open the report in the service or Power BI Mobile?

  1. They will see the new measure and visual because scheduled refresh synchronizes both data and report definitions from Desktop.
  2. They will see the old data and old report because any local PBIX change prevents the service from refreshing the published model.
  3. They will see the new visual only in Mobile because Mobile retrieves the latest layout directly from the developer's PBIX.
  4. They will see refreshed data in the previously published report, but not the unpublished measure or visual changes. (correct answer)
Explanation: When working with Power BI, it's critical to understand the separation between the semantic model (dataset) in the Power BI service and the report definition stored in a PBIX file. These are independent artifacts once published. A scheduled refresh only updates the data within the already-published semantic model — it pulls fresh data from the source but has no awareness of anything sitting on a developer's local machine. That's exactly what makes D correct. The developer published the report once, establishing both a report and a semantic model in the service. The scheduled refresh successfully updated the underlying data in that published model. However, the new measure and replaced visual exist only in the local PBIX file, which was never republished. Users therefore see current, refreshed data — but inside the original report layout, without the new measure or visual. Choice A reflects a common misconception: that scheduled refresh is a full sync operation. It isn't — it only refreshes data, not report structure or metadata from Desktop. Choice B gets the refresh behavior exactly backwards; local unpublished changes have zero effect on the service, so the published model refreshes normally. The local file neither blocks nor triggers anything in the service. Choice C invents a feature that doesn't exist — Power BI Mobile renders the report as it lives in the service, not by reaching into a developer's local file system. A reliable study tip: think of "publish" as the only bridge between Desktop and the service. Until you publish, nothing you change locally crosses that bridge — not measures, not visuals, not anything.

Question 4

A company requires all report-definition changes to originate in its controlled PBIX files. A report looks acceptable on a desktop monitor, but phone users must see a simplified arrangement with fewer visuals and a vertical reading order.

Which workflow satisfies the requirement?

  1. Configure the phone layout in Power BI Desktop, publish the revised report to the service, and consume that layout in Power BI Mobile. (correct answer)
  2. Configure the phone layout in Power BI Mobile, export the mobile design to a PBIX, and republish it through the service.
  3. Create a dashboard in Power BI Desktop, mark its tiles as phone-only, and upload the dashboard file to Power BI Mobile.
  4. Change the browser zoom in the Power BI service, save it as the phone definition, and synchronize that definition to Desktop.
Explanation: When a question mentions that report changes must originate in PBIX files, you're being tested on Power BI's authoring boundaries — specifically, which tools own which design layers and where changes must be saved to be durable and compliant. Power BI Desktop is the authoritative source for report definitions, including phone layouts. Within Desktop, you can switch to the Phone Layout view, rearrange or hide visuals for a vertical mobile experience, and save everything into the PBIX file. When you publish that PBIX to the Power BI service, the phone layout travels with it. Power BI Mobile then automatically detects and renders the phone-optimized layout for mobile users. This is exactly the workflow in A — it satisfies the requirement because the change originates in the controlled PBIX file. B is wrong because phone layouts cannot be configured in Power BI Mobile, and there is no mechanism to export a mobile design back to a PBIX. Mobile is a consumption tool, not an authoring tool. C is wrong on two counts: dashboards are created in the Power BI service, not Desktop, and dashboards do not have a "phone-only tile" authoring feature that maps to this workflow. Dashboard phone layouts exist in the service, not in PBIX files. D is wrong because browser zoom is a local display setting with no connection to report definitions. The Power BI service cannot save a zoom level as a phone layout, and nothing synchronizes back to Desktop. Your study tip: whenever a question stresses that changes must live in a PBIX, trace the workflow back to Desktop — any answer that starts in the service or in Mobile is almost certainly wrong.

Question 5

A regional manager can open a report in Power BI Mobile but sees only the West region. The manager believes that installing Power BI Desktop and opening the published report there will reveal all regions. The report uses row-level security based on the signed-in user.

Which statement best explains the expected behavior?

  1. Desktop automatically bypasses service security, so connecting to the published report will expose every region to the manager.
  2. Mobile applies device-based security, while the service applies row-level security only when reports are opened in a browser.
  3. The service evaluates the manager's identity, so changing the consumption client does not by itself grant access to other regions. (correct answer)
  4. Mobile permanently removes unauthorized rows from the semantic model, so even workspace administrators can never retrieve those rows.
Explanation: Whenever you see a question about row-level security (RLS) in Power BI, anchor your thinking to where security is enforced: it lives in the Power BI service (or Analysis Services), tied to the signed-in user's identity — not in any particular client application. When RLS is configured on a published semantic model, the service filters data based on who is authenticated, regardless of whether that person opens the report in Power BI Mobile, a browser, or Power BI Desktop connected to the live published dataset. The manager is authenticated as themselves in every scenario, so they will always see only the West region. Switching the consumption client changes nothing about the identity the service evaluates. That's exactly what C captures: the service evaluates the manager's identity, and the client tool is irrelevant to that evaluation. A is a dangerous misconception. Power BI Desktop does not bypass service-level security when connecting to a published dataset via a live connection. The service still enforces RLS. Desktop can bypass RLS only in a very specific scenario: if the user is a workspace admin or dataset owner using the "View as" feature in Desktop to test RLS roles — and even then it's a deliberate, explicit action, not automatic. B is fabricated. Power BI Mobile does not use a separate "device-based security" system; it respects the same service-enforced RLS as any other client. D is also false. RLS filters data dynamically at query time — it never permanently deletes rows. Workspace admins can always adjust or test RLS rules. For exam questions involving RLS, remember: identity follows the user, not the device or app.

Question 6

A project team has separate development and production workspaces. Report authors use PBIX files, release managers control promotion, and executives consume only approved production content from their phones.

Which division of responsibilities is most appropriate?

  1. Authors create deployment stages in Desktop, release managers approve them in Mobile, and executives download production PBIX files to their phones.
  2. Authors develop reports in Mobile, release managers promote local PBIX files through Desktop, and executives consume the development workspace in the service.
  3. Authors develop reports in Desktop, release managers promote service content between stages, and executives consume the production content in Mobile. (correct answer)
  4. Authors model data in the service dashboard editor, release managers convert dashboards to PBIX files, and executives open those files in Mobile.
Explanation: When you see a question about Power BI workflows across a team, think about which tool is purpose-built for each role: Power BI Desktop is the authoring environment, the Power BI Service handles collaboration and deployment pipelines, and Mobile is strictly a consumption app for viewing published content. With that framework, option C maps perfectly onto real-world best practices. Authors use Desktop to build and refine PBIX reports locally, release managers use the Service's deployment pipelines to promote content between development and production stages (a feature that only exists in the Service), and executives consume finalized, approved reports through the Mobile app — exactly how a governed enterprise workflow should look. Option A fails because deployment stages are a Service feature, not something created inside Desktop, and release managers cannot "approve" pipeline stages from a Mobile app — Mobile has no pipeline management capabilities whatsoever. Option B reverses the tools entirely. Mobile is a read-only consumer app, not a development environment, and release managers don't manually move PBIX files through Desktop — promotion happens in the Service. Executives should never be pointed to a development workspace, which contains unapproved work-in-progress. Option D is built on a fundamental misunderstanding: the Service's dashboard editor cannot be used for data modeling. Dashboards are pinned-tile surfaces, not authoring canvases. Converting dashboards to PBIX files is not a supported or logical workflow. For the exam, remember this clean mental model: Desktop = build, Service = manage and promote, Mobile = consume. Any answer that puts authoring in Mobile or deployment management in Desktop is automatically wrong.

Question 7

Developers collaborate on reports, while 500 sales representatives should receive a stable, curated collection of content. The representatives must not be able to modify workspace items, and many will access the content from tablets.

Which distribution design is most appropriate?

  1. Store the PBIX files in a shared drive, grant representatives read access, and instruct them to open the files through Power BI Mobile.
  2. Copy each report into Power BI Mobile, lock the tablet layout, and use the mobile copies as the governed production version.
  3. Add every representative as a workspace Member, hide the editing commands, and distribute direct Desktop links to the reports.
  4. Publish the content to a service workspace, distribute a Power BI app to representatives, and let tablets consume the app through Power BI Mobile. (correct answer)
Explanation: When Power BI questions describe a large audience that needs stable, governed content without editing rights, you should immediately think about the workspace + app distribution model. This pattern separates the development environment (the workspace) from what end users consume (the app), which is exactly the right architectural split. Option D is the correct approach because it honors every requirement in the scenario. Developers collaborate freely inside the service workspace, while the published Power BI app gives the 500 representatives a curated, read-only view of that content — they cannot modify workspace items because they never interact with the workspace directly. Critically, Power BI Mobile on tablets renders apps natively, so the experience is optimized and consistent across devices without any extra steps. Option A fails because storing PBIX files on a shared drive means distributing raw development files — there's no governance layer, version control is messy, and opening files through Power BI Mobile this way isn't a supported or stable workflow for end users. Option B misrepresents how Power BI Mobile works; you cannot "copy reports into Power BI Mobile" and use those copies as a production version — mobile layout is a formatting layer, not a distribution mechanism. Option C is a significant trap: adding representatives as workspace Members grants them elevated permissions (they can edit), and "hiding editing commands" is not a security control — it doesn't actually prevent modification. Study tip: On Power BI exam questions, whenever you see "large audience + read-only + governed content," the answer almost always involves an app, not direct workspace access. Apps are the intended consumer-facing layer in Power BI's distribution model.

Question 8

An analyst must combine several local CSV files, create relationships and DAX measures, and distribute an interactive report to employees who will use browsers and phones. The data must refresh each morning without the analyst opening the authoring tool.

Which workflow best meets the requirements?

  1. Build the model in Power BI Desktop, save the PBIX to a shared folder, and have browser and phone users open that file directly.
  2. Build the model in Power BI Desktop, publish it to the Power BI service, and configure refresh and access in the service. (correct answer)
  3. Upload the CSV files through Power BI Mobile, create the relationships there, and share the resulting mobile report with the employees.
  4. Build the model in the Power BI service, export it to Desktop each morning, and distribute the refreshed PBIX through the mobile app.
Explanation: When a question lists multiple requirements — authoring, sharing, scheduled refresh, and multi-device access — your job is to match each requirement to the right tool in the Power BI ecosystem. The key insight is that no single component does everything; Power BI Desktop handles building, while the Power BI service handles sharing, scheduling, and consuming. The workflow in B hits every requirement cleanly. You use Desktop to import the CSVs, define relationships, and write DAX measures — tasks Desktop is purpose-built for. Publishing the PBIX to the Power BI service then unlocks scheduled refresh (configured in the service's dataset settings, no manual intervention needed each morning), browser-based report viewing, and Power BI Mobile access, all without the analyst touching Desktop again. A falls apart on two fronts: browser and phone users cannot open a PBIX file directly — they would need Desktop installed — and a file sitting in a shared folder has no automated refresh mechanism. C is a trap for students who conflate Power BI Mobile with an authoring tool. Mobile is a consumption app; you cannot import CSVs, build data models, or create relationships in it. D reverses the logical flow entirely. The service can host and refresh a published model, but you don't build models in the service and then export back to Desktop for distribution — that's not how the platform works, and the mobile app doesn't distribute PBIX files. As a study tip, memorize the three-role split: Desktop builds, Service publishes and refreshes, Mobile consumes. Any answer that assigns the wrong job to the wrong tool is a distractor.

Question 9

An analyst wants to build a new report using a governed semantic model that is already published in the Power BI service. The analyst must create report pages locally without importing another copy of the model's data.

Which action best meets the requirement?

  1. Connect Power BI Desktop to the published semantic model, build the report, and publish the resulting report to the service. (correct answer)
  2. Download the semantic model into Power BI Mobile, build the report pages there, and synchronize them back to the service.
  3. Export the existing report to CSV from the service, import that CSV into Desktop, and recreate the semantic model locally.
  4. Open the semantic model's workspace in Desktop, edit the service workspace directly, and save the report without publishing.
Explanation: When you see a question about working with existing published semantic models in Power BI, focus on two key requirements: (1) avoiding data duplication and (2) maintaining the governed, single source of truth. The feature designed exactly for this is Live Connection (also called connecting to a published dataset in the service). Answer A is correct because Power BI Desktop allows you to connect directly to a semantic model already published in the Power BI service — no data is imported, no copy is created. You author report pages locally against the live model, then publish only the report back to the service. The model stays exactly where it is, unchanged, and your report simply points to it. This workflow is the foundation of Power BI's "shared dataset" or "governed semantic model" strategy. Answer B is wrong because Power BI Mobile is a consumption tool — it's for viewing and interacting with reports, not building them. You cannot author report pages in Mobile and sync them back. Answer C is wrong because exporting to CSV and reimporting destroys the governed model entirely. You'd be creating a local, unconnected copy of raw data, which violates the requirement to avoid importing another copy of the model's data and abandons any governance controls like row-level security or certified measures. Answer D is wrong because you cannot directly edit a service workspace through Desktop as if it were a local file. Desktop publishes to the service; it doesn't open and save workspace content like a network drive. Study tip: On Power BI exam questions, when you see "governed model" + "no data copy," immediately think Live Connection to a published dataset — that's the pattern Power BI is built around for enterprise reporting.

Question 10

An executive wants one landing page containing selected metrics from three different reports. The executive also wants a notification when a displayed KPI exceeds a threshold and wants to review the landing page on a phone.

Which approach should the BI team use?

  1. Combine the report pages in Power BI Desktop, configure a DAX threshold notification, and open the PBIX through Power BI Mobile.
  2. Pin appropriate visuals to a dashboard in the Power BI service, configure supported tile alerts, and view the dashboard in Power BI Mobile. (correct answer)
  3. Create a dashboard directly in Power BI Mobile, import visuals from the PBIX files, and configure the threshold in the phone layout.
  4. Create three Desktop bookmarks as the landing page, publish the bookmarks separately, and configure alerts on the report-page visuals.
Explanation: When a question asks about combining visuals from multiple reports into a single landing page with alerts and mobile access, you should immediately think about dashboards in the Power BI service — not reports or Desktop files. These three requirements (aggregation, alerts, mobile) are precisely what dashboards are designed for. Pinning visuals from different reports to a single dashboard is a core Power BI service feature, allowing you to create exactly the kind of curated landing page the executive wants. Once tiles are pinned, you can configure data alerts on supported tile types (cards, KPI visuals, gauge visuals) to send notifications when a value crosses a threshold. Finally, dashboards render natively in Power BI Mobile with a responsive phone layout — making option B the complete, correct solution. Option A fails on two points: DAX expressions calculate values but cannot trigger push notifications, and opening a PBIX in Power BI Mobile gives you a report experience, not a consolidated landing page from multiple sources. Option C is a fabrication — you cannot create dashboards directly in Power BI Mobile or import visuals from PBIX files within the app; dashboards are built in the Power BI service. Option D confuses bookmarks (which capture a report's view state for navigation) with dashboards; bookmarks cannot aggregate content across reports, and alerts cannot be configured on report-page visuals — only on dashboard tiles. A useful rule of thumb: whenever an exam scenario mentions cross-report aggregation + alerts + mobile, the answer almost always points to a Power BI dashboard, not a report or Desktop feature.