All questions
Question 1
A report contains a card visual showing the current number of unresolved incidents. An operations manager wants Power BI to notify them when the refreshed value exceeds 100. The notification does not need to be sent to other dashboard viewers.
Which configuration should you use?
- Pin the card to a dashboard and create a data alert for the resulting tile (correct answer)
- Pin the report page as a live tile and configure a page-level alert
- Subscribe to the report and set the subscription threshold to 100 incidents
- Add a report filter for values above 100 and enable automatic notifications
Explanation: When you see a question about proactive monitoring and threshold-based notifications in Power BI, think about where alerts actually live in the service — and the answer is always dashboard tiles, not reports.
Power BI data alerts are a dashboard-only feature. To use them, you must first pin a card visual to a dashboard, which creates a tile. From that tile, you can configure an alert to trigger when the underlying value crosses a threshold — in this case, 100 incidents. Critically, alerts are personal by default: only the person who sets them up receives the notification. This perfectly matches the scenario, where only the operations manager needs to be notified. Answer A is correct.
Answer B is a trap because pinning a live report page creates a tile, but Power BI does not support "page-level alerts" — that feature simply doesn't exist. Live page tiles also don't support data alerts at all, only single card/KPI/gauge tiles do.
Answer C misrepresents what report subscriptions do. Subscriptions send scheduled email snapshots of a report page at set intervals — they don't monitor thresholds or fire conditionally when a value exceeds a number. There is no "subscription threshold" setting in Power BI.
Answer D describes a workflow that doesn't exist in Power BI. Report filters refine what data is displayed visually; they have no built-in notification mechanism tied to them.
Your study tip: remember the rule — alerts live on dashboard tiles, not reports. If a question involves a threshold notification, the path is always: pin to dashboard → configure alert on the tile.
Question 2
Selecting a pinned dashboard tile currently opens its source report. For one tile, users must instead be sent to an external incident-management website. The tile's displayed value must continue to come from the Power BI report.
What should you configure?
- Edit the tile details and specify the external website as a custom link (correct answer)
- Replace the source visual with a report text box containing the website address
- Change the report's web URL data category to the external website address
- Publish the dashboard to the web and redirect the generated public URL
Explanation: When working with Power BI dashboards, it's important to understand that tiles and their source reports are separate layers — and dashboard tiles have their own configurable properties independent of the underlying report visuals.
Each pinned dashboard tile has an Edit details panel where you can override the default click behavior. By specifying a custom link, you redirect users to any URL — including an external site — when they click the tile, while the tile's displayed value continues to pull from the original report visual. This is exactly what the scenario requires: the data stays live from Power BI, but the navigation goes elsewhere. Option A is the correct approach.
Option B is a distractor that confuses display with navigation. Replacing the visual with a text box would break the live data value entirely — text boxes are static, so the tile would no longer reflect real report data. Option C misunderstands the Web URL data category, which is used to make a column's URL values clickable inside table or matrix visuals, not to control dashboard tile navigation. It has no effect on where a tile click leads. Option D goes in the wrong direction entirely — publishing to the web creates a publicly embeddable report link for broad distribution, which has nothing to do with redirecting individual tile clicks and raises unnecessary security concerns.
The study tip here: on Power BI exam questions involving dashboards, always distinguish between tile behavior (configured in Edit tile details) and report behavior (configured inside the report itself). These are separate settings, and confusing them is a common trap.
Question 3
A dashboard contains sales tiles sourced from a report whose semantic model uses row-level security. Regional managers must use the same dashboard but see only the rows permitted for their assigned regions.
Which approach should you use?
- Assign the managers to the appropriate RLS roles and share the dashboard with its related content (correct answer)
- Create one dashboard per region because pinned tiles do not honor row-level security
- Export each regional report page as an image and add the images to separate dashboards
- Grant managers Build permission so that row-level security is applied when they view tiles
Explanation: When you see a question about row-level security (RLS) and dashboards in Power BI, the core concept to understand is how security propagates from the semantic model through reports and into dashboard tiles.
In Power BI, RLS is defined at the semantic model level and flows automatically to any content built on top of it — including pinned tiles on dashboards. When a user views a dashboard tile that was pinned from a report connected to an RLS-enabled model, Power BI evaluates that user's identity against the defined roles and filters the data accordingly. This means a single shared dashboard can display different data to different users based on their assigned RLS roles. Answer A is correct: you simply assign each regional manager to the appropriate RLS role in the semantic model, then share the dashboard with its related content. Each manager will see only their permitted data without needing separate dashboards.
Answer B is a common misconception and a deliberate trap. Pinned tiles do honor RLS — this is a foundational behavior of Power BI's security model, and believing otherwise would lead to unnecessary duplication of work. Answer C is similarly flawed; exporting report pages as static images strips away all dynamic security entirely, leaving sensitive data permanently exposed in a fixed image. This approach would be a security failure, not a solution. Answer D misidentifies the purpose of Build permission. Build permission allows users to create new content from a dataset — it does not control or enforce row-level security filtering when viewing tiles.
A useful study habit: remember that in Power BI, RLS lives on the dataset, not the visual — so wherever that dataset is consumed, the security travels with it.
Question 4
A dashboard needs a short set of usage instructions positioned beside its pinned KPI tiles. The instructions do not exist in a report, and the dashboard owner does not want to modify any report.
What should the dashboard owner do?
- Add the instructions to a semantic model description and refresh the dashboard
- Create a report tooltip page and pin the tooltip to the dashboard
- Add a text box tile directly to the dashboard (correct answer)
- Create a report bookmark containing the instructions and pin the bookmark
Explanation: When working with Power BI dashboards, it helps to distinguish between what belongs to a report versus what belongs to a dashboard directly. Dashboards support several native tile types — including visuals pinned from reports, streaming data tiles, web content, images, and standalone text boxes — all manageable without touching any underlying report.
Since the instructions don't exist in a report and the owner wants to avoid modifying one, the cleanest solution is to add a text box tile directly to the dashboard. You can do this by selecting Edit → Add a tile → Text box in the dashboard's edit mode. This lets you type formatted text — headings, bullet points, hyperlinks — right onto the canvas, positioned exactly where you need it beside the KPI tiles. C is the correct answer.
Option A is a trap: a semantic model description is metadata for documentation purposes inside Power BI Desktop or the service, and it has no mechanism to display content on a dashboard tile. Refreshing the dataset changes nothing visible on the canvas.
Option B misunderstands report tooltips. Tooltip pages are hover-based contextual overlays tied to report visuals — they can't be "pinned" as standalone tiles to a dashboard, and creating one requires editing a report anyway, which violates the scenario's constraint.
Option D confuses bookmarks with shareable content. Bookmarks capture a report's visual state (filters, selections, visibility) and can be linked, but they don't contain freestanding instructional text and cannot be pinned as a tile.
Study tip: On Power BI exam questions, any scenario that says "without modifying a report" is pointing you toward native dashboard features — text boxes, images, or web content tiles are your go-to options.
Question 5
A dashboard is arranged appropriately for desktop browsers, but its tiles appear in an inconvenient order on phones. The desktop arrangement must remain unchanged, and no source report pages should be redesigned.
What should you configure?
- A dashboard theme that reduces the dimensions of every tile
- The phone layout of every source report in Power BI Desktop
- A second dashboard with smaller copies of all existing tiles
- The dashboard's mobile layout in the Power BI service (correct answer)
Explanation: When Power BI questions involve mobile optimization, you need to distinguish between two separate layers of layout control: report page layouts (in Power BI Desktop) and dashboard layouts (in the Power BI service). Keeping this separation clear will guide you to the right answer.
The Power BI service lets you configure a mobile layout specifically for dashboards without touching the desktop view. This dedicated phone layout lets you reorder, resize, and hide tiles exclusively for mobile viewers — the desktop arrangement stays completely intact. That's exactly what the scenario requires, making D the correct answer.
A is a trap because dashboard themes control visual styling (colors, fonts, backgrounds) — not tile arrangement or ordering. Reducing tile dimensions wouldn't reorder them for phone screens in any useful way.
B is tempting because Power BI Desktop does have a mobile layout view for report pages. However, the scenario explicitly states that source report pages must not be redesigned. More importantly, report mobile layouts affect how report pages appear, not how dashboard tiles are ordered — these are different objects entirely.
C describes creating a duplicate dashboard with smaller tiles, which is a manual workaround that introduces maintenance overhead and doesn't use any built-in mobile optimization feature. Power BI's native phone layout exists precisely so you don't need to do this.
Study tip: On Power BI exam questions, watch for the distinction between reports and dashboards — they have separate mobile layout tools in separate places (Desktop vs. the service). If the question mentions a dashboard and mobile ordering, always think "Power BI service mobile layout" first.
Question 6
Executives want a one-page summary of key metrics from several reports. Analysts must also be able to select a summary item and continue to multi-page detail, use report slicers, and perform drillthrough analysis.
Which design best meets both requirements?
- Use separate dashboard tiles as replacements for all report pages and drillthrough targets
- Move every report page onto one dashboard and replace slicers with dashboard-level filters
- Use only a multi-page report because dashboards cannot provide links to report content
- Use a dashboard for the summary and retain the reports as the destinations for detailed analysis (correct answer)
Explanation: When Power BI exam questions describe a scenario with both executive summaries and analyst workflows, you need to match each tool to what it does best — dashboards excel at high-level monitoring, while reports handle interactivity and navigation.
A Power BI dashboard is purpose-built for at-a-glance visibility: it pins key visuals from multiple reports onto a single canvas, giving executives exactly the one-page summary they need. Critically, dashboard tiles act as hyperlinks — clicking a tile navigates directly back to the underlying report page. This means D satisfies both requirements elegantly: executives get their summary view on the dashboard, and analysts can click through to full multi-page reports that support slicers, drillthrough, and all standard report interactions.
A fails because dashboards cannot replace drillthrough targets. Drillthrough is a report-level feature that requires navigating between report pages — it simply doesn't exist on dashboards. Pinning tiles as substitutes would break the analyst workflow entirely. B compounds the same mistake and introduces another: dashboards don't support slicers. Dashboard-level "filters" (Q&A filtering) are far more limited than report slicers, so replacing slicers with them would cripple the analyst experience. C states that dashboards cannot link to report content — this is factually wrong. Clicking a dashboard tile navigates directly to the source report, making dashboards and reports naturally complementary, not mutually exclusive.
As a study tip, remember this clean division: dashboards = monitoring and pinning; reports = interactivity and navigation. When a question mentions slicers, drillthrough, or page navigation, those features live in reports, not dashboards. Keep that boundary clear and these questions become straightforward.
Question 7
A semantic model supports Power BI Q&A. A dashboard author needs a tile that displays the result of the natural-language question, "total margin by fiscal quarter." The existing reports must not be edited.
Which action should the author take?
- Create a Q&A visual in Power BI Desktop, republish the report, and pin its page
- Use Q&A from the dashboard, generate the visual, and pin the result to the dashboard (correct answer)
- Enter the question in the dashboard title and bind the title to the semantic model
- Create a report subscription whose subject contains the natural-language question
Explanation: When working with Power BI Q&A, you need to understand the two surfaces where Q&A can be used: within reports (via a Q&A visual in Desktop) and directly from a dashboard. The key constraint here is that existing reports must not be edited, which immediately narrows your options.
The right move is B: from any dashboard, you can click the Q&A question box, type your natural-language query ("total margin by fiscal quarter"), and Power BI generates a visual on the spot. You then pin that visual directly to the dashboard as a tile — no report modification required. This is a core, purpose-built workflow for dashboard authors who need quick, flexible visualizations without touching underlying reports.
A fails because it requires opening and republishing a report in Power BI Desktop — a direct violation of the constraint that existing reports must not be edited. Even if republishing were allowed, this workflow adds unnecessary complexity for a task the dashboard Q&A experience handles natively.
C is a misconception about dashboard functionality. Dashboard titles are static text elements used for labeling and organization; they cannot execute natural-language queries or bind dynamically to a semantic model to generate visuals.
D confuses report subscriptions with interactive Q&A. Subscriptions deliver scheduled email snapshots of report pages — they have no mechanism for interpreting natural-language questions or generating new dashboard tiles.
Study tip: On Power BI exam questions, whenever you see the phrase "existing reports must not be edited," immediately look for solutions that work at the dashboard or service layer rather than in Desktop — Q&A pinning is a classic example of this pattern.
Question 8
A sales executive wants a single Power BI canvas that displays a revenue card from a Sales report, an inventory chart from an Operations report, and a customer-satisfaction KPI from a Support report. The reports use separate semantic models, and the existing models must not be modified.
- A dashboard containing tiles pinned from each of the three reports (correct answer)
- A report containing copied visuals from each of the three reports
- A paginated report connected directly to each of the three reports
- A report bookmark that captures the required visuals across the reports
Explanation: When you see a question about combining visuals from multiple separate reports with different semantic models, focus on what Power BI feature can pull content from different sources without touching the underlying data models.
A dashboard in Power BI is designed exactly for this scenario. You can pin individual tiles — cards, charts, KPIs — from any published report, regardless of which semantic model that report uses. The tiles live on one canvas, giving the executive a unified view without ever modifying the source reports or their models. Answer A is correct for precisely this reason.
Answer B is tempting but flawed. Copying visuals between reports doesn't actually move the data connection — a visual is tied to its semantic model. You cannot paste a visual from a Sales report into a different report and have it remain connected to the Sales model. You'd need to import or duplicate the model, which violates the constraint.
Answer C misrepresents paginated reports. Paginated reports are optimized for pixel-perfect, printable output (think invoices or financial statements). They don't "connect directly to other reports" — they connect to data sources or semantic models, and mixing three separate models still doesn't solve the single-canvas problem cleanly.
Answer D misunderstands bookmarks entirely. A bookmark captures the state of visuals (filters, visibility, scroll position) within a single report. Bookmarks cannot span across multiple reports.
Study tip: Remember this distinction — a report lives within one semantic model, while a dashboard is model-agnostic and aggregates tiles across many reports. Any question asking you to unify content from separate models without modification points to a dashboard.
Question 9
A report page contains four visuals and a slicer. Users must view the entire page on a dashboard, change the slicer selection from the dashboard, and automatically see later report-page design changes without repinning every visual.
How should you add the content to the dashboard?
- Pin each visual separately, and then create an additional tile for the slicer
- Pin the entire report page as a live page tile (correct answer)
- Export the report page to an image, and add the image as a tile
- Create a dashboard tile for each visual, and configure a dashboard-level filter
Explanation: When you see a dashboard requirement that combines interactivity, automatic updates, and multi-visual display, think about live page tiles — one of Power BI's most powerful but often overlooked dashboard features.
Pinning a report page as a live page tile (option B) is the right approach here because it satisfies all three requirements at once. The entire page — including all four visuals and the slicer — appears as a single tile. Users can interact with the slicer directly from the dashboard, and because it's a live connection to the report page, any design changes you make to the report automatically reflect on the dashboard without repinning anything.
Option A fails on two fronts: pinning visuals individually means you'd need to repin whenever the design changes, and more critically, standard tiles pinned from a report are static snapshots — slicers cannot be pinned as interactive tiles in this way. Option C is even more limiting; exporting to an image creates a completely static, non-interactive picture. No slicer interaction, no live updates — it's essentially a screenshot. Option D misunderstands how dashboard filters work. Dashboard-level filters don't replicate the slicer functionality described, and you'd still face the repinning problem whenever the report layout changes.
A useful pattern to remember: whenever a Power BI question mentions needing interactivity + automatic updates + full-page display, the live page tile is almost always the answer. The key phrase to watch for is "automatically see later design changes without repinning" — that's the telltale signal that static individual pins won't work.
Question 10
A line chart from a report was pinned to a dashboard as an individual visual tile. The semantic model refreshes nightly. A report author later changes the source visual from a line chart to a clustered column chart, but the dashboard must also display the new visual type.
What should the report author do?
- Wait for the next semantic model refresh to change the dashboard tile automatically
- Refresh the browser because visual-type changes are stored only in the local cache
- Remove the existing tile and pin the modified report visual again (correct answer)
- Edit the dashboard theme so the tile adopts the source visual's new type
Explanation: When working with Power BI dashboards, it helps to understand the relationship between report visuals and dashboard tiles. A dashboard tile is essentially a snapshot pinned from a report at a specific point in time — it captures not just the data, but also the visual type (line chart, bar chart, etc.) at the moment of pinning. After that, the tile and the source visual live somewhat independently.
When a report author changes a line chart to a clustered column chart, that change updates the report visual, but the existing dashboard tile has no automatic mechanism to detect or inherit visual-type modifications. The tile only reflects the original pinned configuration. To surface the new chart type on the dashboard, the author must remove the old tile and re-pin the updated visual — exactly what option C describes. This creates a fresh tile that captures the new visual type correctly.
Option A is wrong because semantic model refreshes update the data flowing into tiles, not their visual formatting or chart type. Waiting overnight won't change what kind of chart appears. Option B is wrong because visual-type changes aren't a browser caching issue — refreshing the browser affects only the local rendering session, not the dashboard tile's definition stored in the Power BI service. Option D is wrong because dashboard themes control cosmetic styling (colors, fonts, backgrounds), not whether a tile displays as a line chart versus a column chart.
A useful rule of thumb: in Power BI, data follows the refresh schedule, but visual structure follows the pin. Whenever a source visual's type changes, always re-pin to keep the dashboard in sync.