PL-300 Study Guide 2026: The Complete Power BI Data Analyst Certification Guide

What Is the PL-300?

The PL-300 is Microsoft's certification for Power BI Data Analysts. It validates that you can take raw, messy business data and turn it into clean models, meaningful DAX calculations, and reports that people actually use to make decisions.

Passing it earns you the Microsoft Certified: Power BI Data Analyst Associate credential — one of the most in-demand data certifications on the job market. Employers, recruiters, and clients treat it as proof you can do real Power BI work, not just follow tutorials.

Exam at a Glance

The Four Exam Domains

Microsoft weights the exam across four skill areas. Know these cold — every study decision flows from them:

1. Prepare the data (25–30%) — Connect, profile, clean, transform, and load data with Power Query
2. Model the data (25–30%) — Design star schemas, write DAX, optimise model performance
3. Visualise and analyse the data (25–30%) — Build reports, dashboards, and paginated reports; apply AI visuals
4. Manage and secure Power BI (15–20%) — Row-level security, workspaces, deployment pipelines, sensitivity labels

This guide walks through each domain in exam depth: what Microsoft tests, the concepts that trip people up, and how each topic shows up on test day.

Domain 1: Prepare the Data (25–30%)

This is where every Power BI project starts — and where the exam starts. Microsoft wants to know you can connect to real-world data sources, assess data quality, and shape messy data into something a model can use.

1.1 Connecting to Data Sources

Power BI connects to 100+ data sources, but the exam focuses on the patterns, not the list. Know these cold:

Import vs DirectQuery vs Dual vs Live Connection

This is one of the most-tested concepts in the entire exam. Get it tattooed on your brain:

• Import mode stores a compressed copy of the data inside the PBIX file. Fast queries, full Power Query and DAX support, but limited by dataset size and refresh schedules. Use it when data fits in memory and doesn't need real-time freshness. This is the default and the most common choice.

• DirectQuery sends every visual interaction as a live query back to the source database. No data stored in Power BI. Always current, but slower, and many Power Query transformations and DAX functions are restricted. Use it for very large datasets or when real-time data is non-negotiable.

• Dual mode lets a table act as both Import and DirectQuery depending on context. Power BI chooses the fastest path. Useful in composite models where some tables are small (import) and others are huge (DirectQuery).

• Live Connection connects to an already-published tabular model (Analysis Services or a Power BI dataset). You build visuals on someone else's model — no data modelling on your end at all.

Exam trap: Questions love asking "which storage mode" for a scenario. The decision tree is: Does the data need to be real-time? → DirectQuery. Is the dataset enormous (won't fit in memory)? → DirectQuery or composite. Otherwise → Import.

Composite models combine Import and DirectQuery tables in one dataset. The exam tests that you know composite models enable Dual storage mode and that relationships between DirectQuery tables have restrictions (limited to many-to-one, single direction).

1.2 Data Profiling in Power Query

Before you transform anything, you profile. Power Query Editor has three profiling tools under the View tab:

• Column quality — Shows the percentage of valid, error, and empty values per column as a coloured bar. Your first-glance data health check.
• Column distribution — Shows distinct vs unique value counts. Distinct = number of different values. Unique = values that appear exactly once. The exam loves testing that you know the difference.
• Column profile — Shows a histogram plus min, max, average, count statistics for the selected column.

Why the exam cares: Scenario questions describe dirty data ("the customer table has blank emails and duplicate IDs") and ask which profiling feature you'd use first. Answer: column quality to find the blanks, column distribution to find the duplicates.

1.3 Cleaning and Transforming Data

Power Query (M language) is the ETL engine. The exam doesn't make you write M from scratch, but you must know what each transformation does and when to use it.

Essential transformations:

• Remove duplicates — Operates on selected columns or entire rows. Critical: removing duplicates on the wrong column combination silently deletes valid data. Always check row counts before and after.

• Replace values vs replace errors — Replace values swaps specific text. Replace errors catches error values (like division-by-zero results) and substitutes something clean. Different operations, different menu items.

• Split column — By delimiter, by number of characters, or by positions. Splitting "John Smith" into first/last name is the classic example. The exam tests the "split into rows" variant for denormalising data.

• Merge queries — Power Query's version of a SQL JOIN. Left outer, inner, right outer, full outer, left anti, right anti. Know what each returns. Left anti (rows in left NOT in right) is the exam favourite for "find customers with no orders" scenarios.

• Append queries — Stacks tables vertically (UNION). Columns match by name. Use when combining same-structured data (e.g., monthly sales files).

• Pivot / Unpivot — Pivot turns row values into columns (long to wide). Unpivot does the reverse (wide to long). The exam tests unpivot heavily because real-world exports come pivoted and Power BI models need unpivoted data.

• Group By — Aggregates rows (sum, count, average, min, max, all rows). The "All Rows" operation creates a nested table per group — powerful and frequently tested.

Data types matter enormously. Power Query assigns types (Text, Number, Date, True/False, etc.). Wrong types cause silent errors — dates stored as text won't sort correctly, numbers stored as text won't sum. Always verify types after loading. The exam includes questions where the "bug" is a wrong data type.

Query folding is the concept that Power Query translates your steps into native source queries (SQL, for example) instead of pulling all data and processing locally. It only works for certain sources and certain transformations. Steps that break folding (like adding a custom column with complex logic early) force Power BI to import everything first — slow. The exam tests that you know to check folding by right-clicking steps and looking for "View Native Query" (greyed out = folding broke).

1.4 Advanced Power Query Concepts

Parameters let you make queries dynamic — a parameter for "start date" means one query serves many scenarios. The exam tests parameters in the context of data source flexibility (switching between dev/prod servers without editing queries).

Custom functions in M let you reuse transformation logic. Invoke a custom function as a new column to apply the same logic row by row.

Handling errors: Beyond replace errors, know how to filter error rows, and that errors in a column propagate through downstream steps until handled.

Domain 2: Model the Data (25–30%)

This is the heart of the PL-300 and the domain most candidates underestimate. Good models make everything else easy. Bad models make DAX a nightmare.

2.1 Star Schema Design

The exam is built on the assumption that you design star schemas. Know this pattern perfectly:

• Fact tables contain measurable events: sales transactions, orders, website visits. Long and narrow. Connected to dimensions via foreign keys. Contains the numbers you aggregate.

• Dimension tables contain descriptive attributes: customers, products, dates, stores. Short and wide. Connected to facts via primary keys. Contains the labels you slice by.

• A star schema has one fact table surrounded by dimension tables with single-direction relationships flowing from dimensions to the fact. Clean, fast, and DAX-friendly.

• A snowflake schema normalises dimensions further (product → product category → product subcategory as separate tables). The exam wants you to know snowflakes are *valid but slower* — denormalise into star when performance matters.

Exam scenarios describe a business ("a retailer tracks daily sales by store, product, and salesperson") and ask you to identify facts vs dimensions or to spot a modelling anti-pattern (like a fact table with customer names embedded instead of a customer dimension).

2.2 Relationships

Cardinality — the exam tests all four, but focuses on when each is correct:

• Many-to-one (*:1) — The standard. Many sales rows link to one customer. This is what you want.
• One-to-one (1:1) — Rare. Only when two tables describe the same entity at the same grain.
• One-to-many (1:*) — Same as many-to-one, viewed from the dimension side.
• Many-to-many (*:*) — A red flag. Usually means a missing bridge table or a modelling error. Power BI supports it but performance suffers and DAX gets confusing. The exam wants you to *fix* many-to-many, not celebrate it.

Cross-filter direction:

• Single — Filters flow from the dimension (one side) to the fact (many side). The default. Predictable.
• Both — Filters flow in both directions. Enables certain calculations but risks ambiguity and performance hits. The exam tests that you know bidirectional filtering can create ambiguous filter paths.

Active vs inactive relationships: Only one active relationship can exist between two tables. Others are inactive (dotted line) and must be activated selectively with USERELATIONSHIP() in DAX. Classic exam scenario: an Orders table with both OrderDate and ShipDate linking to a Date table. One is active; the other needs USERELATIONSHIP.

2.3 DAX — The Make-or-Break Topic

DAX is where exams are won and lost. You don't need to be a DAX master, but you need rock-solid fundamentals.

Evaluation context — the single most important DAX concept:

• Row context — "The current row." Created by calculated columns and iterator functions (SUMX, FILTER, ADDCOLUMNS). In row context, you can reference column values directly: Sales[Quantity] * Sales[Price].

• Filter context — "The current filters." Created by visuals, slicers, and CALCULATE. Determines which rows are visible to an aggregation. A card visual showing total sales for 2024 has a filter context of Year = 2024.

• Context transition — When a DAX expression in row context calls CALCULATE, the row's values become filters. This is the #1 source of confusion and the #1 source of exam questions. If you see CALCULATE inside an iterator, think context transition.

Essential DAX functions (know what each does and when to use it):

*Aggregation:*

• SUM(), AVERAGE(), MIN(), MAX(), COUNT(), COUNTROWS(), DISTINCTCOUNT() — The basics. DISTINCTCOUNT is slower; use it only when needed.

*Filter manipulation:*

• CALCULATE(<expression>, <filters>) — The most powerful DAX function. Modifies filter context, then evaluates. Every time intelligence calculation uses it.
• FILTER(<table>, <condition>) — Returns a filtered table. Use inside CALCULATE, not as a visual-level filter.
• ALL() — Removes filters. ALL(Sales) ignores all filters on Sales. ALL(Date[Year]) removes only the Year filter.
• ALLEXCEPT() — Removes all filters except specified columns. Great for "percent of category total" calculations.
• KEEPFILTERS() — Preserves existing filters when CALCULATE would otherwise override them.

*Time intelligence (heavily tested):*

• SAMEPERIODLASTYEAR() — Same dates, previous year. Needs a proper date table.
• DATEADD() — Shifts dates by intervals (days, months, quarters, years).
• DATESYTD(), DATESMTD(), DATESQTD() — Year/month/quarter to date.
• TOTALYTD(), TOTALMTD() — Shorthand for CALCULATE(SUM(), DATESYTD()).
• Critical: Time intelligence requires a marked date table with contiguous dates. No gaps. The exam *will* test this.

*Logical and iterator functions:*

• IF(), SWITCH() — SWITCH(TRUE(), ...) is the DAX-preferred pattern for multiple conditions.
• SUMX(), AVERAGEX(), MAXX(), MINX() — Iterators: row-by-row calculation then aggregate. SUMX(Sales, Sales[Qty] * Sales[Price]) is the textbook example.
• RANKX() — Ranking. Know the difference between dense and skip ranking.
• RELATED() — Pulls a value from the one-side of a relationship (use in the many-side table). RELATEDVALUE() is the newer alternative.

Measures vs calculated columns vs calculated tables:

• Measures — Calculated on demand, in filter context. Stored nowhere. Always prefer measures for aggregations. This is the exam's golden rule.
• Calculated columns — Computed at refresh time, in row context, stored in the model (increases file size). Use only when you need a static value per row for slicing or as a relationship key.
• Calculated tables — Created with DAX, useful for disconnected parameter tables or intermediate logic.

Exam trap: "Where should this calculation go?" If it aggregates → measure. If it's a fixed label per row → calculated column. If in doubt → measure.

Variables (VAR): Use VAR to store intermediate results. Makes DAX readable, avoids recalculation, and — critically — VAR is evaluated once in its original context. The exam tests VAR scoping.

2.4 Model Optimisation

Reduce cardinality: High-cardinality columns (unique IDs, timestamps, free-text) bloat models. Remove unnecessary columns, round timestamps, split datetime into date + time.

VertiPaq compression loves low-cardinality, sorted columns. The exam tests that you know *why* star schemas compress well (repetitive dimension keys).

Aggregations (for large datasets): Create pre-aggregated tables at higher grain. Power BI automatically uses them when possible, falling back to detail for drill-through. Tested in the context of DirectQuery performance.

Performance Analyzer in Power BI Desktop shows DAX query time, visual display time, and "other" time per visual. Use it to find slow visuals. The exam describes symptoms and asks which tool diagnoses them.

Domain 3: Visualise and Analyse the Data (25–30%)

3.1 Choosing the Right Visual

The exam doesn't just test *how* to build visuals — it tests *which* visual fits the analytical question:

• Card / Multi-row card — Single headline numbers (total revenue, order count).
• Bar / Column charts — Comparing categories. Clustered for side-by-side, stacked for part-of-whole.
• Line chart — Trends over time. Never use for categorical comparisons.
• Area chart — Like a line chart but emphasises volume.
• Donut / Pie — Part-of-whole with few categories (max 4-5 slices or it becomes unreadable).
• Treemap — Hierarchical part-of-whole (category → subcategory rectangles).
• Matrix — Pivot-table style with row/column headers and drill-down. The exam favourite for hierarchical data.
• Scatter chart — Correlation between two measures, with bubble size as a third dimension.
• Waterfall — Cumulative effect of sequential changes (profit bridge: starting revenue → additions → subtractions → ending profit).
• Funnel — Sequential stages with drop-off (sales pipeline, conversion funnel).
• Gauge / KPI — Progress toward a target.
• Decomposition tree — AI-driven root-cause analysis. Let users drill into dimensions to explain a metric.
• Key influencers — AI visual that finds which factors drive a metric up or down.
• Q&A — Natural language queries ("show me sales by region last quarter").

Exam scenarios describe an analytical need and ask for the best visual. Think about what the user is trying to *see*: comparison → bar, trend → line, composition → donut/treemap, flow → funnel/waterfall, single number → card.

3.2 Formatting and Interactivity

Conditional formatting applies rules to colours, icons, or data bars based on values. Available on tables, matrices, and some chart elements. The exam tests the "rules vs gradient vs field value" options.

Slicers filter the report page. Sync slicers across pages from the Sync Slicers pane. Hierarchical slicers need the hierarchy in the field well.

Drill-through lets users right-click a data point and jump to a detail page filtered to that context. Set up drill-through filters on the target page. Cross-report drill-through extends this across different reports (requires same dataset or shared credentials).

Drill up/down navigates hierarchies within a visual. Expand shows the next level for all categories; drill down focuses on one.

Buttons and bookmarks: Bookmarks capture the state of a page (filters, slicer selections, visual visibility). Buttons trigger bookmarks, page navigation, drill-through, or Q&A. Together they build guided navigation experiences. The Selection pane controls layering and visibility — essential for bookmark-driven show/hide logic.

Tooltips: Default tooltips show the visual's values. Report page tooltips let you design a custom tooltip page that appears on hover — richer context without cluttering the main visual.

Sorting: Sort by any column, including a hidden sort column (e.g., sort month names by month number using "Sort by Column" in the Data view).

3.3 Hierarchies and Groups

Date hierarchies are auto-created (Year → Quarter → Month → Day) but depend on the auto date/time setting. For production models, build your own date table and hierarchy.

Binning groups numeric data into ranges (age groups, price bands). Right-click a numeric field → New Group → Bin.

3.4 Paginated Reports (Report Builder)

The exam includes paginated reports — pixel-perfect, printable, multi-page reports built in Power BI Report Builder (not Desktop):

• Designed for printing and PDF export — invoices, operational statements, regulatory filings.
• Use tables, matrices, and charts in a freeform layout (unlike Desktop's canvas grid).
• Support parameters for user input, subreports, and precise page headers/footers.
• Data sources and datasets are defined in Report Builder, separate from Desktop models.
• Published to the Power BI service; need Premium capacity or PPU for distribution.

Exam distinction: "The finance team needs a pixel-perfect monthly statement exported to PDF" → paginated report. "The sales team needs an interactive dashboard" → Power BI Desktop report.

3.5 Dashboards vs Reports

• Reports (PBIX) — Multi-page, built in Desktop, full interactivity, based on one dataset.
• Dashboards (service only) — Single-page, pin tiles from multiple reports and datasets, limited interactivity. Built for at-a-glance monitoring.

The exam tests that dashboards are a *service* feature and that you pin *tiles* (not visuals) from reports.

3.6 Analyse in Excel and Export

Analyse in Excel creates a live-connected pivot table from a Power BI dataset. Requires the right permissions and is governed by RLS. The exam tests the prerequisites (Excel version, dataset permissions).

Domain 4: Manage and Secure Power BI (15–20%)

4.1 Row-Level Security (RLS)

RLS restricts which rows a user can see. This is heavily tested — know the full implementation:

Static RLS:

1. In Power BI Desktop: Modelling → Manage Roles → create roles with DAX filters (e.g., [Region] = "East").
2. Validate with "View as" to preview each role.
3. Publish. In the service: dataset → Security → assign users/groups to roles.

Dynamic RLS uses USERPRINCIPALNAME() to filter based on who's logged in:

[Email] = USERPRINCIPALNAME()

This requires a mapping table linking users to their allowed data (e.g., salesperson → territory). One role serves everyone — the DAX does the filtering dynamically.

Exam traps:

• RLS roles are defined in Desktop but *assigned* in the service. Both steps are required.
• "View as" tests roles but doesn't enforce them — enforcement happens in the service.
• RLS doesn't apply to dataset owners/admins by default (they see everything unless you test specifically).
• Object-level security (OLS) hides entire tables/columns (via Tabular Editor, not native Desktop). Don't confuse with RLS.

4.2 Workspaces and Apps

Workspace roles (Admin, Member, Contributor, Viewer) control what users can do. Viewers can't edit; Contributors can create content; Admins manage everything including access.

Apps package dashboards, reports, and datasets for distribution. Update the app after changing content — workspace changes don't auto-push to the app. Audiences in apps let you show different navigation to different user groups.

4.3 Sharing and Distribution

• Share a report/dashboard directly — recipients need a Pro license (or content in Premium capacity).
• Publish to web — Public embed. Anyone with the link can view. Never use for sensitive data. The exam loves "what's wrong with this approach" questions where the answer is publish-to-web on confidential data.
• Embed options: SharePoint, Teams, secure embed (for portals, requires authentication).

4.4 Deployment Pipelines

Three stages: Development → Test → Production. Deploy content forward through stages with one click. Rules can remap data sources and parameters per stage (dev database → prod database automatically). The exam tests the stage order and that deployment is one-directional (with selective reverse deploy for specific items).

4.5 Data Governance

• Sensitivity labels (from Microsoft Purview) classify data (Public, Confidential, etc.). They persist through exports to Excel and PowerPoint. The exam tests that labels travel with the data.
• Endorsement: Promote or Certify datasets to signal trustworthiness. Certified > Promoted > neither.
• Lineage view shows data flow from source through dataflows and datasets to reports. Essential for impact analysis ("if I change this dataset, what breaks?").
• Data alerts notify users when a KPI crosses a threshold (service feature, on cards/gauges/KPIs).

4.6 Refresh and Gateways

Scheduled refresh (Import mode): Up to 8x daily on Pro, 48x on Premium. Configure in dataset settings in the service.

On-premises data gateway bridges cloud Power BI to on-premises data sources (SQL Server on a local network, file shares, etc.):

• Standard mode — Multiple users, multiple sources. The enterprise choice.
• Personal mode — Single user, Power BI Desktop only. Deprecated for most scenarios.
• The exam tests *when* you need a gateway: any on-premises source + scheduled refresh in the service = gateway required. Cloud sources (Azure SQL, SharePoint Online) don't need one.

Incremental refresh partitions large tables by date range. Only new/changed partitions refresh. Requires Premium/PPU and parameters (RangeStart, RangeEnd) in Power Query. Dramatically reduces refresh time for large fact tables.

The 15 Mistakes That Fail the PL-300 (And How to Avoid Them)

After working through hundreds of practice questions and helping analysts prepare, these are the traps that catch even experienced Power BI users:

Data Preparation Mistakes

1. Choosing DirectQuery when Import would work. The exam loves scenarios with "10 million rows that update nightly." Candidates pick DirectQuery because the data is "large." But 10M rows imports fine, and nightly updates don't need real-time. Unless the scenario says real-time or the data genuinely won't fit in memory, Import is the answer.

2. Confusing merge with append. Merge = JOIN (combines columns based on matching keys). Append = UNION (stacks rows). When the question says "combine monthly files with the same columns," that's append. When it says "bring customer names into the sales table," that's merge.

3. Forgetting to check data types after loading. A date column loaded as text will sort alphabetically (April before January). A number stored as text won't aggregate. The exam buries this as the root cause in "the visual isn't working correctly" scenarios.

4. Not understanding query folding implications. If a question mentions slow refresh and asks what to check, the answer is often about steps that break folding. Transformations like "add column from examples" or complex custom logic early in the query force full data loads.

Modelling Mistakes

5. Building measures as calculated columns. If the question asks where to put a "total sales by region" calculation and you pick calculated column, you've added unnecessary model bloat. Aggregations that respond to filters = measures. Always.

6. Misunderstanding filter context in CALCULATE. CALCULATE(SUM(Sales[Amount]), Sales[Region] = "East") — candidates forget this *replaces* any existing Region filter rather than adding to it. If you need to preserve existing filters, wrap with KEEPFILTERS.

7. Using bidirectional filtering as a default. It seems convenient until filter ambiguity creates wrong totals. The exam expects single-direction as the default and bidirectional only when specifically needed (e.g., for certain many-to-many scenarios or specific DAX patterns).

8. Forgetting the date table requirement for time intelligence. SAMEPERIODLASTYEAR, DATESYTD, and friends silently return wrong results without a proper date table — contiguous dates, no gaps, marked as date table. The exam *will* include a scenario where time intelligence "isn't working" and the root cause is a missing or incomplete date table.

9. Not knowing the difference between DISTINCTCOUNT and COUNT. COUNT counts non-blank values. DISTINCTCOUNT counts unique non-blank values. COUNTROWS counts all rows including blanks. Mixing these up in a scenario about "unique customers" vs "total orders" is a classic fail.

10. Ignoring context transition. When CALCULATE appears inside an iterator like SUMX or FILTER, each row's values become filters. Candidates who don't recognise this misdiagnose why a measure returns unexpected results. If you see CALCULATE nested inside row iteration, think context transition immediately.

Visualisation Mistakes

11. Picking the wrong visual for the question. The exam doesn't ask "how do you create a bar chart" — it describes an analytical need. "Show how profit changed step by step from revenue through costs" is a waterfall, not a bar chart. "Show which factors drive customer churn" is key influencers, not a scatter plot. Match the visual to the *question being asked*.

12. Confusing reports with dashboards. Reports are multi-page, built in Desktop, based on one dataset. Dashboards are single-page, service-only, pin tiles from multiple sources. When the scenario says "executives want one page pulling KPIs from three different reports," that's a dashboard.

13. Forgetting paginated reports exist. Any scenario mentioning "pixel-perfect," "print-ready," "multi-page invoice," or "regulatory filing" is pointing at paginated reports (Report Builder), not Power BI Desktop.

Security and Management Mistakes

14. Defining RLS roles but forgetting service assignment. Roles are created in Desktop. Users are assigned in the service. Doing only the first step means no actual security. The exam tests this two-step process explicitly.

15. Using "Publish to web" for sensitive data. It's tempting for easy sharing, but it makes the report publicly accessible to anyone with the link. The exam includes "what's wrong with this solution" questions where publish-to-web on confidential data is the trap.

Frequently Asked Questions

How long should I study for the PL-300?

With existing Power BI experience: 4–6 weeks of focused study (1–2 hours/day). Starting from scratch: 8–12 weeks. The biggest time sink is DAX — budget half your study time for Domain 2.

Is the PL-300 hard?

It's moderately difficult. The pass rate isn't published, but the challenge isn't memorisation — it's *judgment*. Scenario questions ask you to pick the best approach from plausible options. Hands-on practice matters more than reading.

Do I need to know M (Power Query language)?

You need to understand what M transformations do and recognise M patterns, but you won't write M from scratch. Focus on the *effects* of transformations (what merge/append/pivot/unpivot produce) rather than syntax.

How much DAX do I really need?

More than you think, less than a DAX master. You need: evaluation context (row vs filter), CALCULATE, FILTER, ALL/ALLEXCEPT, time intelligence functions, iterators (SUMX), and the measure vs calculated column distinction. You don't need advanced DAX patterns like complex virtual tables.

Can I use the Power BI interface during the exam?

No. It's a proctored exam with multiple choice, drag-and-drop, case studies, and hotspot questions. But many questions show screenshots of the Power BI interface — familiarity with where things are (Modelling tab, View tab, etc.) helps enormously.

Does the PL-300 expire?

Microsoft certifications are valid for one year. You renew annually with a free online assessment. The renewal focuses on what's changed — much easier than the initial exam.

PL-300 vs DA-100 — what's the difference?

DA-100 was the predecessor. PL-300 replaced it in 2022 with updated content reflecting the modern Power BI service (deployment pipelines, sensitivity labels, etc.). If you studied DA-100 materials, most concepts transfer but check for updated service features.

What jobs does the PL-300 qualify me for?

Power BI Developer, Data Analyst, BI Analyst, Reporting Analyst. It's also valuable for consultants, accountants, and operations managers who want to formalise their Power BI skills. Many of our clients specifically ask for PL-300-certified analysts.

Exam-Day Strategy

Question Types You'll See

1. Multiple choice — Standard. Eliminate obviously wrong answers first.
2. Drag and drop — Order steps or match concepts. Read all options before placing any.
3. Case studies — A business scenario with 4-6 related questions. Read the case once carefully, then answer. Don't re-read for every question.
4. Build list — Put steps in the correct order. Think about dependencies (you can't create a relationship before both tables exist).
5. Hot area — Click the right part of a screenshot. Familiarise yourself with the Power BI interface.

Time Management

• ~100 minutes for 40-60 questions = roughly 2 minutes per question.
• Flag hard questions and move on. Case study questions are worth the same as quick ones.
• Leave 10 minutes at the end for flagged questions.

The Night Before

• Review DAX evaluation context one more time (it's the highest-value topic).
• Skim the four domain weightings and make sure you have no blank spots.
• Sleep. Cramming DAX at 2 AM has never saved anyone.

During the Exam

• For scenario questions, identify the *domain* first (is this a modelling question or a visualisation question?). It narrows your options.
• Microsoft's "best" answer usually means the most scalable, maintainable, or secure option — not the quickest hack.
• When two answers seem right, pick the one that follows Microsoft best practices.

Topic Checklist — Final Review

Run through this list. If you can't explain each one in two sentences, study it more:

Prepare the data:

Model the data:

Visualise and analyse:

Manage and secure:

Quick-Reference DAX Cheat Sheet

About This Guide

This guide was written by the team at Nexera Technology and Consultancy — we build Power BI dashboards, Excel automations, and websites for small businesses across Mississauga, Toronto, and the GTA. We've taken these concepts from exam theory into real client work: the DAX patterns above run in production dashboards, the RLS setups protect real business data, and the modelling principles come from untangling actual messy spreadsheets.

Want the practice quiz? Take our free 30-question PL-300 practice test with instant scoring and detailed explanations.

Need Power BI help for your business? Book a free 30-minute strategy call — we'll look at your data and show you 2–3 quick wins, whether or not you hire us.

*Study smart. The PL-300 doesn't test memorisation — it tests whether you think like a data analyst. Every scenario question is asking: given this business problem, what's the right Power BI approach? If you can answer that confidently across all four domains, you're ready.*