PL-300 Power BI Scenarios You Should Be Ready to Solve

The PL-300 exam is easiest to misunderstand when candidates study Power BI as a collection of buttons. Microsoft’s current blueprint is built around the complete analytical workflow: prepare data, model it, create useful analysis, and manage and secure Power BI assets. The exam therefore rewards judgment about how those pieces fit together.

As of April 20, 2026, Microsoft weights the exam across four major areas: Prepare the data (25–30%), Model the data (25–30%), Visualize and analyze the data (25–30%), and Manage and secure Power BI (15–20%). Candidates are also expected to be comfortable with both Power Query and DAX.

The scenarios below are not recalled exam questions. They are representative study situations designed to exercise the same kinds of decisions a working Power BI data analyst must make. They are most useful when you explain why one approach fits the requirement rather than memorizing a one-line answer.

Scenario 1: Decide where data cleaning belongs

Imagine that a sales CSV contains inconsistent date formats, trailing spaces in customer names, several columns that are not needed for reporting, and numeric fields imported as text. The business refreshes the file every morning and expects the report to update without manual cleanup.

The key question is where to solve the problem. For repeatable source shaping, Power Query is the natural layer. You can remove unused columns, standardize text, set data types, handle errors, split or merge fields, and build a transformation sequence that reruns at refresh time.

The important exam skill is recognizing that transformation order matters. Changing a data type before fixing invalid values may create errors. Filtering rows too early can remove records that should first be corrected. Renaming columns before merges may break later references if you do not understand the applied steps.

A strong candidate can look at a transformation requirement and reason through the sequence rather than simply naming a Power Query command. That step-by-step logic is central to data preparation in Power BI, where transformation order can change the final result.

Scenario 2: Choose between a calculated column and a measure

Suppose a sales model needs to display revenue margin dynamically by product, region, and month. At first glance, both a calculated column and a measure may appear capable of performing arithmetic. The better choice depends on evaluation context and how the result will be used.

Calculated columns are evaluated row by row and stored in the model. Measures are evaluated at query time under the current filter context. A margin that must respond to slicers and visual grouping is generally a measure problem, because the calculation should adapt to the context in which the user is viewing it.

Now change the requirement: the business needs a fixed category stored for every customer so the category itself can be used on an axis or slicer. That may point toward a column rather than a measure, depending on how the category is derived.

PL-300 questions often test the consequence of the design decision, not merely the definition. Study DAX calculations and evaluation context until you can predict how a calculation behaves as filters change.

Scenario 3: Build a model that supports reliable analysis

A report contains a Sales table with millions of rows plus Customer, Product, Store, and Date tables. A common mistake is to flatten everything into one enormous table because it feels simpler. That can make the model harder to understand, less reusable, and less efficient.

PL-300 candidates should be comfortable recognizing a star-schema pattern: a central fact table holding events or transactions surrounded by dimension tables that describe those events. Relationships, cardinality, filter direction, and granularity all matter.

Consider a Date dimension related one-to-many to Sales. That structure makes time filtering predictable. If multiple date roles exist—Order Date and Ship Date, for example—the model may need an inactive relationship that is activated inside a measure when the alternate date is required.

The exam can present a model and ask which relationship change produces the required result with the least ambiguity. The best preparation is to build small models and deliberately test filter propagation. That same reasoning is central to Power BI data modeling, because relationship design determines how filters and calculations behave.

Scenario 4: Diagnose a DAX result that changes unexpectedly

A measure works correctly in a card but produces unexpected totals in a matrix. This is a classic sign that the candidate needs to reason about filter context rather than rewrite arithmetic blindly.

Functions such as CALCULATE, REMOVEFILTERS, KEEPFILTERS, and relationship-aware expressions can change the context in which a measure is evaluated. The same measure can legitimately return different results depending on row headers, slicers, page filters, and cross-filtering from another visual.

When studying, trace the filter context before evaluating the formula. Ask which table and column filters exist, which relationships propagate them, and what CALCULATE changes. This habit is more valuable than memorizing isolated function syntax because the exam often embeds DAX in business scenarios.

Also remember that “correct total” is a semantic requirement, not a visual formatting issue. If a ratio should be recomputed at the total level, summing row-level percentages is usually not the right answer. The measure must express the intended business logic at every context level.

Scenario 5: Select a visual based on the analytical question

A regional manager wants to compare monthly sales trends, identify whether performance is above target, and inspect which product categories contribute most to a shortfall. One report page may need several visuals, but each visual should answer a distinct question.

A line chart is effective for trend over time. A bar or column chart may be better for comparing categories. KPI-style presentation can emphasize performance against a target. A decomposition tree, scatter plot, or other analytical visual may be appropriate when the user needs to explore drivers rather than simply read a value.

The PL-300 skill is not remembering every icon in the Visualizations pane. It is choosing an appropriate encoding for the business question and avoiding visual clutter that makes interpretation harder.

Microsoft’s current blueprint also expects candidates to improve usability and storytelling. That includes thoughtful formatting, accessible design, conditional formatting where it adds meaning, report navigation, and interactions that help users explore without becoming confused.

Suppose selecting a region in one chart should filter the sales trend but should not change an executive benchmark card. Power BI’s default cross-filtering behavior may therefore need adjustment.

Using Edit interactions, the report designer can control whether one visual filters, highlights, or has no effect on another. The exam may describe a user-experience requirement and ask how to configure the page rather than asking for the definition of cross-filtering.

This is another reason practical rehearsal matters. Create a page with several visuals and deliberately alter the interactions. Then test how drill-through, tooltips, bookmarks, slicers, and synced slicers change user navigation. The more you understand the resulting behavior, the less these questions feel like trivia.

Scenario 7: Implement row-level security without duplicating reports

A national sales report must show each regional manager only the rows for that manager’s territory. Creating a separate report for every region would be difficult to maintain and could introduce inconsistent logic. Row-level security is designed for this class of requirement.

Static roles can work when the number of partitions is small and stable. Dynamic RLS is more scalable when user identity must map to data entitlements. Candidates should understand how security filters are defined, how relationships propagate those filters, and how to test roles before deployment.

Do not treat RLS as a visual filter. Security must be enforced at the semantic-model level so unauthorized rows are not simply hidden by a report design choice. Questions in this area often test that distinction.

Microsoft places manage-and-secure responsibilities in a smaller exam domain than data preparation or modeling, but the 15–20% weighting is still substantial enough that candidates cannot afford to skip workspace, deployment, permissions, refresh, and security topics.

Scenario 8: Decide how to manage a semantic model after publication

A report works in Desktop but must now be shared with a business team, refreshed from cloud and on-premises sources, and maintained by several analysts. The problem has moved from report authoring into asset management.

Candidates should know the purpose of workspaces, apps, semantic models, refresh configuration, gateways, permissions, endorsements, and related service features. The best answer is often the one that meets governance needs with the least unnecessary duplication.

For example, several reports may be able to reuse a trusted semantic model instead of each importing and transforming the same source data independently. That improves consistency and can reduce maintenance effort. The analyst must also understand who can build from, edit, reshare, or consume the content.

This operational layer is easy to under-study if most preparation happens only in Power BI Desktop. Microsoft’s current blueprint explicitly includes management and security, so spend time in the Power BI service rather than treating deployment as an afterthought.

A semantic model has grown large, refresh time is increasing, and several visuals take too long to render. Performance questions require candidates to think across the entire stack rather than immediately blaming DAX.

Unnecessary columns increase model size. Poor relationship design can create ambiguity. High-cardinality data can make compression less effective. Complex measures can be expensive. Too many visuals can generate excessive queries. Transformation choices may also prevent efficient query folding against supported sources.

A disciplined troubleshooting process isolates the bottleneck. Reduce unused data, check model design, inspect transformations, simplify expensive calculations where possible, and use appropriate performance tools to identify which visuals or queries are actually slow.

Optimization is important because a report that is analytically correct but painfully slow still fails users. PL-300 assesses a professional role, so performance should be understood as part of delivering usable analytical solutions.

Scenario 10: Turn business requirements into a Power BI design

The most realistic PL-300 scenario is also the broadest: a stakeholder says, “I need to understand which customers are becoming less profitable and why.” There is no single Power BI button that answers that request.

The analyst must clarify the business definition of profitability, identify required sources, clean and shape the data, design a model at the correct grain, create calculations, choose visuals, validate the results, and make the report understandable to its audience. Security and refresh requirements then determine how the solution is deployed.

This end-to-end thinking is what connects the four current exam domains. Preparing each domain separately is necessary, but the final stage of study should recombine them into complete analytical problems.

Use Microsoft’s current Power BI Data Analyst Associate requirements as the structural checklist, then rehearse with realistic tasks rather than relying only on multiple-choice recall.

Build exam readiness by explaining your decisions

A useful PL-300 study session should end with more than “I got 80% correct.” Review every uncertain question and explain the decision aloud: why Power Query rather than DAX, why a measure rather than a calculated column, why one relationship direction is safer, why a particular visual fits the requirement, or why a security rule belongs in the model.

That process exposes shallow knowledge quickly. It also mirrors the judgment required in real Power BI work, where analysts must justify design choices to stakeholders and teammates.

Near exam day, combine domain review with practical PL-300 preparation that forces you to apply skills across multiple domains. Exam-day strategy belongs in the final stage; timing techniques cannot compensate for weak technical understanding.

The goal is not to predict the exact questions you will see. It is to become comfortable solving the kinds of Power BI problems Microsoft says a certified data analyst should be able to handle.