Free PL-300 practice test

Option D breaks folding because Date.ToText is a non-foldable M function that converts a date to text; once applied, all subsequent steps lose foldability. Option E breaks folding because Remove Duplicates is a transformation that SQL Server cannot natively represent as a pushdown operation, so it breaks the fold chain. Option B is correct syntax that typically folds. Option A is the canonical incremental refresh pattern and folds correctly. Option C (renaming a column) does fold in most SQL connectors because it translates to a column alias in the SELECT clause.

The correct approach is to reference the [Region] parameter in the table navigation step (e.g., Source{[Schema=Region,Item="Sales"]}[Data]), which dynamically selects the correct schema. This also preserves query folding. Option A is wrong because native SQL string concatenation using the & operator in M does not fold to SQL and may produce errors; also, using Value.NativeQuery or similar would be needed for native SQL. Option D is wrong because a Filter Rows step only filters rows within a table — it cannot switch database schemas. Option B is wrong because the parameter changes the server name, not the schema, which would point to a completely different server rather than a different schema on the same server.

Dual is correct because a table in Dual mode is cached like an Import table but can also be queried directly from the source when participating in a DirectQuery relationship. This allows [DimDate] to act as an Import table for most queries (fast, cached) and as a DirectQuery table when the engine determines it needs live source data alongside [FactSales]. Import alone would work for caching but would not allow the table to participate transparently in DirectQuery cross-source scenarios requiring source-side execution. DirectQuery would query [DimDate] live every time, negating the performance benefit of a small dimension table. Live connection is a connection mode for an entire model (e.g., Analysis Services), not a per-table storage mode setting.

A Power BI dataflow is correct: it allows IT to define and maintain M-based data preparation transformations centrally in Power BI service, refresh the output on a schedule, and expose the resulting entities as a reusable data source that multiple .pbix developers can connect to via the Power BI dataflows connector. A .pbit template is wrong: it packages a report structure but each developer still performs independent refreshes against raw sources; there is no shared, centrally refreshed transformation layer. A shared parameter file is wrong: Power Query parameters control values (e.g., server names) but do not encapsulate transformation logic or provide a shared refreshable output. A paginated report dataset is wrong: paginated reports use RDL datasets for rendering, not a reusable transformation layer for Power BI Desktop models.

RangeStart and RangeEnd must be Date/Time parameters — this is a hard requirement enforced by Power BI; using any other data type will cause the incremental refresh configuration to fail. The filter using these parameters must be query-foldable so that Power BI can pass the date range to the source system and retrieve only the relevant partition of data efficiently; if folding breaks, incremental refresh cannot partition data at the source. Option C is wrong — the policy is configured in Power BI Desktop and takes effect after publishing to the Power BI Service, not before publishing. Option D is wrong — incremental refresh is designed for Import mode tables (it would be redundant for DirectQuery, which always queries live). Option E is partially related but is not a standalone requirement separate from A; the parameter types (A) already enforce compatible date handling.

Merge Queries is correct because it performs a join between two tables on one or more key columns (here [OrderID]), combining columns from both tables horizontally—equivalent to a SQL JOIN. Append Queries is wrong because it stacks rows from two tables vertically (union), requiring the same schema; it does not join on a key column. Group By is wrong because it aggregates rows within a single table; it does not combine two separate tables. Pivot Column is wrong because it rotates distinct row values into column headers within a single table; it does not join tables.

TOTALYTD accepts an optional year-end date argument (as a string in MM/DD format). For a fiscal year ending March 31, specifying '3/31' correctly calculates the year-to-date total from April 1 through the current date in context. Option A is wrong — DATESYTD without the year-end argument defaults to December 31, which would produce a calendar YTD, not a fiscal YTD starting April 1. Option C is wrong — hardcoding January 1 calculates a calendar YTD and does not respect the fiscal year boundary. Option B is wrong — SAMEPERIODLASTYEAR shifts dates back one year and is used for year-over-year comparisons, not YTD calculations.

B is correct: adding a measure such as [Sales Count] = COUNTROWS(Sales) and applying a visual-level filter (keep rows where Sales Count > 0) is the safest, most controlled approach to show only categories with sales. It avoids the performance and ambiguity risks of bidirectional filtering. A is wrong: enabling bidirectional cross-filtering would allow the Sales table to filter the Products table, which would indeed hide categories with no sales — but bidirectional filtering can cause ambiguity, unexpected results in other visuals, and performance degradation; it is not the recommended approach for this scenario. C is wrong: creating an inactive relationship and activating it via USERELATIONSHIP affects measure calculations, not visual filtering of dimension rows. D is wrong: there is no 'mark as dimension table' setting in Power BI Desktop that affects cross-filter behavior or row visibility. E is wrong: RELATED is used in calculated columns to look up values across a relationship in row context; pulling Category from Sales would break the data model logic, as Category belongs in Products, not Sales.

Correct: USERELATIONSHIP() inside CALCULATE activates an otherwise inactive relationship for the duration of that calculation, directing filter context through Sales[ShipDateKey] → Date[DateKey] instead of the active OrderDateKey relationship. Option B (CROSSFILTER) changes the cross-filter direction of a relationship but does not activate an inactive one. Option C (TREATAS) propagates a filter by treating a column as if it had a relationship to another column, but here the inactive relationship already exists, making USERELATIONSHIP the cleaner and intended solution. Option D (SUMX/RELATEDTABLE) doesn't address relationship activation at all.

Correct (E): Removing the column entirely in Power Query is the most effective action — if the column is not needed, it should not be loaded into the model at all. This eliminates its memory consumption completely. Correct (B): VertiPaq uses run-length encoding (RLE) compression, which works best when consecutive values are identical or sorted. Sorting a high-cardinality column by a lower-cardinality column can group similar values together, improving RLE efficiency and reducing memory usage. | Wrong (A): GUIDs are unique strings and will have the same cardinality regardless of data type; converting to Whole Number is not valid for GUIDs and would cause errors or data loss. | Wrong (D): Aggregation tables help query performance but do not reduce the memory footprint of the detail column — the underlying column still exists in VertiPaq. | Wrong (C): Disabling summarization changes how the column behaves in visuals (preventing implicit aggregation) but has no effect on VertiPaq memory consumption — the column is still stored.

Option D is correct: PREVIOUSQUARTER returns a table of dates for the entire previous calendar quarter relative to the last date in the current filter context. This is the most direct and semantically correct function for retrieving the prior full quarter. Option A is incorrect — DATEADD shifts dates by a specified interval but returns the same number of days offset rather than a full quarter boundary; it does not align to calendar quarter starts/ends. Option B is incorrect — PARALLELPERIOD also shifts by a full quarter but returns the full quarter that is N quarters away from the current selection; while similar, PREVIOUSQUARTER is specifically designed for this use case and handles partial-period selections more predictably. Option C is incorrect — SAMEPERIODLASTYEAR shifts the date range back exactly one year, not one quarter.

The Q&A visual allows users to type natural language questions and receive dynamically generated visual answers based on the data model. Smart Narrative generates automated text summaries but does not accept user-typed questions. Key Influencers analyzes factors that drive a specific metric but does not support free-text queries. Decomposition Tree is used to drill into hierarchical breakdowns of a measure but is not a natural-language query interface.

A Field parameter (introduced in Power BI) creates a parameter table that allows users to select which measure (or field) to display in a visual, dynamically changing what is plotted. This is the most efficient, purpose-built approach. Using bookmarks with three hidden visuals works but is cumbersome to maintain and scales poorly. Adding all three measures as grouped bars displays all values simultaneously rather than switching between them. A What-if parameter is for numeric value inputs (e.g., scenarios), not for selecting between existing model measures.

In the Decomposition Tree, fields added to the 'Explain by' well can be set to expand using AI splits (High value / Low value) or left as user-chosen splits. When the split type is 'Choose' (manual), a '+' button appears at each node and users select which dimension to expand next — supporting interactive, user-directed exploration. 'High value' AI splits automatically pick the best dimension, removing user choice. There is no 'Axis' field well or 'User-driven drill' toggle in the Decomposition Tree — that language comes from other visuals. 'Low value' AI splits automatically highlight the smallest contributors, also removing user choice.

Drillthrough (B) is designed for exactly this scenario: a target page is configured with a drillthrough field (Shipment ID), and right-clicking a value in a source visual passes that value as context to the detail page automatically. Drill down (A) navigates through a hierarchy within the same visual (e.g., Year → Quarter → Month) and does not navigate to a separate report page. Bookmarks (C) capture a static state of a page and do not dynamically pass row-level context values. Page navigation buttons (D) jump to a page without passing any data context to filter it.

The Smart narrative visual (C) auto-generates dynamic text summaries that describe key trends, outliers, and statistics in the data; it updates automatically when report filters change. The Q&A visual (A) responds to user-typed natural language questions rather than generating narrative summaries automatically. Key Influencers (B) identifies statistical drivers of a metric but does not produce written sentence summaries. Decomposition tree (D) provides an interactive breakdown of a measure across dimensions but does not generate narrative text.

The correct three-step process is: (1) Access the semantic model's Security settings via 'More options > Security' in the workspace — this is the correct service-side entry point for RLS testing. (2) In the RLS test interface, enter Ana's UPN to simulate her view and verify the data returned matches only West region records. (3) Confirm that Ana's UPN is actually a member of the correct RLS role, since the test will only work correctly if her membership is properly configured. Option D describes Power BI Desktop's 'View as' feature, which is for design-time testing and cannot test with a specific user's UPN in the service. Option B conflates two steps inaccurately — you select the role AND enter the user; entering only the user (via 'Test as role') in the service will impersonate them and automatically apply their assigned roles. Option C is incorrect and unnecessary; you do not need to change Ana's workspace role to test RLS — in fact, testing RLS is done by the semantic model owner/admin, not by Ana herself.

Fabric capacity workspaces (like Premium capacity) allow free-license users to consume published apps (Option A is correct). Semantic models well beyond 1 GB are supported—up to the capacity's memory limits (Option B is correct). Deployment pipelines are a Premium/Fabric capacity feature and are available on Fabric capacity (Option C is correct). Option D is incorrect—free users can consume content but cannot edit or publish reports; they still need at least a Pro or PPU license to author content. Option E, while the refresh limit is indeed increased on Fabric/Premium capacity (from 8 to 48 refreshes per day), this is a true benefit but the question asks which of the three stated requirements are met, and this was not one of them—however, all three correct answers (A, B, C) map directly to the three stated requirements. Option F is incorrect—on-premises data gateways are still required to connect to on-premises data sources regardless of capacity type.

Lineage view in the Power BI service provides a visual end-to-end map of data flow from data sources → dataflows → semantic models → reports → dashboards within a workspace, allowing the manager to see all upstream and downstream dependencies. Usage metrics report shows who is viewing content and how frequently — it does not show data dependencies or lineage. The Workspace monitoring workbook (Admin portal) provides audit log and activity data across the tenant but does not show artifact-level lineage. Impact analysis (also accessible from the semantic model's context menu) shows downstream dependents of a specific artifact and is a valid partial answer, but lineage view shows both upstream (dataflows) AND downstream dependencies in a single visual, making it the more complete answer for the full requirement described.

Power BI apps support multiple audiences, allowing the app publisher to create distinct navigation experiences for different user groups within the same app. Each audience sees only the reports and dashboards assigned to it. Option D is correct. Option B (two separate apps) works but is unnecessarily complex and doesn't leverage the single-app, multi-audience capability. Option A (RLS only) would restrict data within a report but doesn't hide entire reports from an audience—users would still see all reports in the app navigation. Option C (workspace Viewer role) bypasses the app entirely and grants direct workspace access, which is a different permission model and doesn't control which reports each group sees.