Refer to the Exhibit Practice Questions

The user sees all rows in the Sales table.

Why it fails: Row-level security (RLS) is not a no-op; the role assigned to the user applies a filter predicate on the Region column. Because the role restricts rows to Region='US', the user cannot see rows for other regions (e.g., 'Canada' or 'Mexico') in the Sales table. Seeing all rows would require either no RLS role or a role definition without a filter, neither of which applies here. Thus this option is incorrect because it ignores the active role's filter.

The user sees all rows but the SalesAmount column is hidden.

Why it fails: RLS in Power BI is row-based, not column-based; it filters data rows using DAX predicates, whereas column visibility is controlled by object-level security (OLS) or by removing/reordering columns in the data model. Hiding a column would require an OLS rule or a model change, not an RLS role, and it would not alter which rows are returned. Since the role only defines a row filter on Region, the SalesAmount column remains visible for every row that passes the filter. Therefore, this option confuses RLS with column-level security.

The user sees all rows in all tables of the dataset.

Why it fails: RLS applies only to tables for which a filter predicate is defined in the active role, and it does not grant visibility into unrelated tables unless those tables are related and the filter propagates. Here the role's filter is explicitly on the Sales table's Region column, so only Sales rows with Region='US' are visible; the user does not see all rows in every table. Even if other tables are related, the filter will propagate through relationships to restrict related rows, not expand visibility. This option incorrectly asserts that RLS is bypassed or that all tables are unfiltered.

Change credential type to 'Service Principal' and provide the app ID and secret.

Why it fails: A Service Principal credential authenticates to Azure Blob Storage via Microsoft Entra ID, but the error states the container is private and requires authentication, not that the current identity lacks permissions. The anonymous credential is already failing because the container denies unauthenticated access, so switching to a Service Principal would provide authentication, but the question’s scenario does not specify that a Service Principal has been granted access to the container. It is tempting because Service Principals are commonly used for automated, non-interactive access to Azure resources, and would be correct if the container’s access control list (ACL) or Azure RBAC had already assigned the Service Principal the necessary Storage Blob Data Reader role.

Change credential type to 'Basic' and provide the storage account name and key.

Why it fails: Basic authentication sends a simple username/password payload that Azure Blob Storage does not accept; the Basic credential type is designed for SQL Server, MySQL, or other data sources that support user/password login challenges. Even if you supply the storage account name and the account key in the username and password fields, Power BI will not translate that into the Shared Key or SAS authorization scheme Azure Blob requires. For Azure Blob, Power BI expects Account Key, SAS, or Entra ID-based credential types, so selecting Basic will fail.

Change credential type to 'Windows' for the Azure Blob datasource.

Why it fails: Windows authentication relies on NTLM or Kerberos against a domain-joined environment, which is meaningful only for on-premises sources like SQL Server or file shares. Azure Blob Storage is a cloud service with no concept of Windows domain credentials, so Power BI will not even offer or accept Windows as a valid credential type for that data source. Even if it did, the storage service cannot verify a Windows user, making this option completely incompatible with the error at hand.

Organizational

Why it fails: The Organizational privacy level in Power BI permits data sharing among users within the same trusted tenant, but only when the source's configuration explicitly sets privacyLevel to Organizational. In the provided JSON, the stanza reads "privacyLevel": "Private", which directly contradicts any Organizational classification. Reading the literal key-value pair is mandatory because Power Query uses that exact token to enforce isolation rules; assuming Organizational would disregard the serialized value and misrepresent the data gateway's security posture.

None

Why it fails: The None privacy level, if it were valid in modern Power BI, would indicate that privacy checks are ignored, allowing unfettered data combination across sources. However, the configuration in question does not omit or default the property; it includes an explicit assignment to "Private". Since None cannot be reverse-engineered from the JSON and would require assuming an absence of enforcement, it is demonstrably incorrect. Modern Power BI no longer surfaces None as a selectable option, so this answer also conflicts with current product behavior.

Public

Why it fails: Public privacy level would classify the data as intentionally shareable with no restrictions, enabling Power Query to freely combine this source with any other public or organizational source. The JSON, however, explicitly overrides that by setting "privacyLevel": "Private", which imposes the opposite constraint—data must remain isolated. Thus, selecting Public directly contradicts the serialized configuration, which is the canonical source of truth for a data source defined in Power BI.

There is no relationship between Date and Product tables.

Why it fails: The absence of a relationship between Date and Product would not produce this specific error. SUMMARIZECOLUMNS can operate on any tables, and missing relationships would result in a cartesian product (if intentional) or a different evaluation behavior, but not a scalar measure failure. Relationship issues typically manifest as incorrect results or a 'related table not found' error, not this type of scalar mismatch. Therefore, this is not the most likely cause.

The SUMMARIZECOLUMNS function does not support multiple group-by columns.

Why it fails: This is not the cause because SUMMARIZECOLUMNS explicitly accepts multiple group-by columns; it is designed to return a table with one row per combination of the given columns. In fact, it accepts up to 76 columns in a single call, making multi-column grouping a core feature. The error occurs after the grouping is defined, during measure evaluation, so it is not about the number of group-by columns. The measure's inability to produce a scalar is the actual failure point.

The ORDER BY clause is not allowed in EVALUATE statements.

Why it fails: ORDER BY is a valid and commonly used clause in EVALUATE statements in DAX queries. The grammar for EVALUATE allows an optional ORDER BY clause that sorts the results based on expressions or columns, so it is fully supported in DAX. The error would occur before ordering is processed, because the measure is evaluated for each row in the result set. Thus, ORDER BY cannot be the cause of this error.

All workspace admins.

Why it fails: All workspace admins are not notified by the MailOnFailure setting, which is scoped to the dataset owner rather than the workspace's role-based membership. Workspace admins would only receive a refresh failure email if an explicit workspace admin notification checkbox were enabled separately in the dataset's refresh configuration. Since the exhibit only shows the MailOnFailure flag, the intended recipient is solely the dataset owner, and the workspace admin role does not inherit this notification.

The Power BI tenant admin.

Why it fails: A Power BI tenant admin does not receive refresh-failure emails from individual datasets because MailOnFailure only sends to the dataset owner's email address. Tenant admins can monitor refresh health through the admin portal or audit logs, but that requires proactive viewing and is not an automatic notification sent to the admin's inbox. To alert a tenant admin, one would have to explicitly add their email address as an additional contact in the dataset's email notification list, which is not indicated by the exhibit.

All users with access to the dataset.

Why it fails: Users with access to the dataset do not receive refresh-failure notifications, since MailOnFailure is not tied to dataset permissions such as Read or Build. Having access to view reports or build on top of the dataset does not enroll a user in the dataset's operational email notifications. Only the dataset owner and any explicitly configured additional contacts (such as workspace admins or specific emails) are in the recipient list, so users with access but no owner role are not included.

The SUM function ignores filters applied to the Sales table.

Why it fails: The SUM function in DAX is a scalar aggregation that operates within the current filter context; it does not ignore or discard any filters applied to the Sales table. Filters from slicers, page-level filters, report-level filters, or row/column context in a visual all restrict the rows that SUM sees. The confusion arises because CALCULATE, not SUM, is responsible for changing the filter context — SUM alone is faithful to whatever context it is called in.

The measure syntax is invalid and defaults to no filter.

Why it fails: The measure syntax is completely valid: CALCULATE accepts a scalar expression (SUM(Sales[Amount])) followed by one or more filter arguments written as boolean expressions or table filters. Using a simple predicate like Sales[Region] = "West" is a standard way to filter, and there is no requirement to use the FILTER function unless a more complex expression is needed. Therefore, the premise that the syntax is invalid is false, and the measure does not "default to no filter" — it evaluates with the filter explicitly applied.

The filter is applied to the entire Sales table, not just the Region column.

Why it fails: The filter argument in CALCULATE, when written as a boolean column predicate, does not filter the entire Sales table; it filters only the column referenced in the predicate. Specifically, the condition Sales[Region] = ... is evaluated for each row in the Sales table, and only rows that satisfy the condition on the Region column are retained in the filter context. This is not a table-level filter like a Row-Level Security rule; it is a column-level filter, and other columns in the Sales table remain unaffected unless the filter is propagated through relationships.

Yes, because User2 is a Contributor.

Why it fails: Contributors possess content editing capabilities within a Power BI workspace, such as creating and modifying reports and dashboards, but they are not granted the permission to manage workspace membership. The workspace Admin role is the only role that includes the 'Add member' or 'Assign users' permissions, so being a Contributor does not allow User2 to add a new user. Therefore, the statement is incorrect.

Yes, because User2 is a Member.

Why it fails: Members have more privileges than Contributors, including the ability to publish and edit content, but they still lack the authority to add or remove other users from the workspace. In Power BI's role-based access control, only the Admin role can modify the member list, change roles, or delete content. Since User2 holds only the Member role, they cannot add a new user, making the answer 'No' rather than 'Yes'.

No, because the Premium capacity does not allow adding users.

Why it fails: Premium capacity is a sales and licensing model that allocates dedicated resources and improved performance for Power BI content, and it does not govern who can manage workspace membership. Workspace membership management is controlled exclusively by the workspace role of the user, not by the capacity type (Premium, Shared, or Embedded). Therefore, the reason 'Premium capacity does not allow adding users' is false; even on Premium, only an Admin can add users.

The measure does not filter out returns

Why it fails: Returns reduce revenue but not the distinct customer count, so including them inflates the numerator while the denominator stays fixed, raising CLV. It is tempting because excluding returns is a legitimate revenue-recognition refinement, but it would lower rather than raise the values, contradicting the observed symptom.

The measure should use COUNTROWS instead of DISTINCTCOUNT

Why it fails: COUNTROWS counts rows, not distinct customers, so the denominator would grow with transaction volume and CLV would fall, not rise. It is tempting because COUNTROWS is the correct choice when counting events or line items rather than unique entities, which is not what CLV requires.

The measure is dividing by zero for categories with no customers

Why it fails: Division by zero yields blank or infinity in DAX, not an inflated value, so it cannot explain higher-than-expected CLV. It is tempting because guarding against zero denominators with DIVIDE is a genuine best practise, but it addresses error handling rather than the observed overstatement.

The SQL Server credentials are not correctly configured in the data source settings.

Why it fails: Misconfigured SQL Server credentials would produce an authentication failure, such as 'Login failed for user' or an ODBC login timeout, not a privacy-level error. Privacy-level errors are unrelated to credential validation; they are raised during the query-folding and data-combination phase when Power Query checks whether sources can be merged under the current privacy settings. Therefore, this option points to a completely different class of data-source configuration issue.

The privacy levels for the SQL Server data source are set inconsistently across the environment.

Why it fails: Inconsistent privacy levels for the same SQL Server data source across different environments do not cause a privacy-level error within a single Power Query execution. Privacy level is a per-source, per-user property in Power BI Desktop, and the engine evaluates the combination of sources in the current session using those stored levels. The error requires at least two distinct sources being combined with incompatible settings, not a mismatch of settings for one source across machines or users.

The query uses a CSV file from a local folder that has a privacy level set to 'Private'.

Why it fails: The CSV file's 'Private' privacy level is a necessary contributing factor, but it is not sufficient on its own to trigger a privacy-level error. Power Query raises this error only at the point where data from the CSV is combined with another source, such as SQL Server, and the two sources' privacy levels are incompatible. If the CSV were used in isolation, no privacy fault would occur, so this option incorrectly identifies the CSV alone as the root cause.

Increase the number of partitions to monthly

Why it fails: Simply increasing the number of partitions to monthly does not automatically improve refresh performance. In Power BI, partitions are primarily managed by the incremental refresh feature; manually creating monthly partitions through the XMLA endpoint adds complexity and metadata overhead, yet without an incremental refresh policy, a full refresh will still reprocess all data each time, canceling any potential benefit. Moreover, excessive partitioning can degrade query performance due to increased metadata management and maintenance tasks rather than optimizing it.

Remove all partitions and load data as a single table

Why it fails: Removing all partitions and loading the data as a single table forces Power BI to perform a full refresh of the entire dataset on every scheduled refresh. This dramatically increases refresh duration and data load because there is no mechanism to isolate recent changes or historical data, meaning every row is re-read and reprocessed. Even if the table is moderately large, the absence of partition pruning raises memory pressure and query latency, making this option counterproductive for any scenario requiring efficient refreshes.

Change the storage mode to DirectQuery

Why it fails: Changing the storage mode to DirectQuery does not improve refresh performance; it eliminates the need to refresh imported data but introduces major trade-offs. DirectQuery issues live queries to the underlying source, making query performance dependent on source-system indexing and network latency, and it loses the in-memory compression and highly optimized query engine that import mode provides. This option changes the data-access strategy entirely rather than addressing partition configuration, and it requires a stable source connection, making it unsuitable as a solution for optimizing scheduled data refreshes.

The query returns total sales for each year, ignoring category

Why it fails: This is incorrect because SUMMARIZECOLUMNS explicitly lists both Year and Category as grouping columns, so the query returns one row per unique Year-Category combination, not a yearly total that collapses categories. To ignore category, Category would need to be removed from the GROUP BY list, causing the grouping to be solely by Year. Moreover, the Amount > 100 filter is applied to sales rows, but it does not drop Category from the result; it only limits which rows feed the aggregation.

The query returns sales amounts only for products with Amount > 100

Why it fails: This is incorrect because the query does not return individual sales amounts; it returns aggregated totals for each Year and Category combination. The Amount > 100 condition is a filter on the sales rows that contribute to those totals, not a product attribute filter. The output granularity is Year-Category, not per-sale or per-product, so it cannot produce sales amounts for specific products.

The query returns total sales for each category, ignoring year

Why it fails: This is incorrect because Year is also a grouping column in the SUMMARIZECOLUMNS call, so the result retains a separate row for each year within every category rather than aggregating across all years. To ignore Year, the query would need to omit Year from the GROUP BY columns and possibly use CALCULATE to override the year filter context. Additionally, the Amount > 100 predicate restricts the underlying data, but it does not change the fact that Year remains part of the grouping granularity.

The refresh schedule uses UTC but the data source is in a different time zone.

Why it fails: The scheduled refresh time is expressed in UTC, and Power BI will accurately trigger the refresh at that moment regardless of the data source's local time zone. A time-zone mismatch only shifts the effective execution time relative to the source's clock; it does not affect connectivity or authentication. The error in this scenario is a credential failure, which is unrelated to time-zone conversion. Therefore, this option cannot explain the failed refresh.

The dataset has DirectQuery enabled, which prevents Import mode refresh.

Why it fails: This dataset is explicitly configured with Import mode and DirectQuery is disabled, as stated in the scenario. Even if DirectQuery were enabled, it would not 'prevent' Import mode for the whole dataset—Power BI supports a mixed storage mode where some tables use DirectQuery and others use Import. The process of scheduled refresh is only relevant to Import-mode tables, so DirectQuery's presence or absence is not the root cause. The actual problem is the unsupported SSPI credential type, not the storage mode.

The gateway ID is incorrect.

Why it fails: An invalid gateway ID would generate a distinct error such as 'Gateway not found' or 'The gateway is not configured' during the refresh attempt. In this case, the gateway ID is correctly provided, and the error message points to an authentication failure within the data source. The gateway's role is to broker the connection, but it cannot resolve an SSPI credential because that requires an interactive user. Hence, an incorrect gateway ID would not produce the specific SSPI-related error described.

All relationships are equally efficient

Why it fails: This is incorrect because relationship efficiency is directly affected by filter direction and cardinality. Unidirectional relationships are generally cheaper than bidirectional ones, which require the storage engine to propagate filters in both directions, raising query processing cost. Additionally, a relationship's status as active/inactive and its cardinality (one-to-many vs. many-to-many) further change performance. Therefore, the Product–Category bidirectional relationship is clearly less efficient than the unidirectional relationships in this model, disproving the idea that all relationships perform equally.

The relationship between Sales and Customer

Why it fails: The Sales-to-Customer relationship is a conventional many-to-one relationship with unidirectional cross-filtering, so filters flow only from Customer to Sales without any reverse propagation. This directionality is computationally efficient because the engine doesn't need to traverse back-reference paths or maintain extra join indexes. In normal reporting, there is no need for Sales to filter Customer, so this relationship doesn't introduce ambiguity or slowdown. Hence, it is not the relationship causing performance concerns in this scenario.

The relationship between Sales and Product

Why it fails: The Sales-to-Product relationship is unidirectional, meaning Product filters Sales but not the other way around, and that is the standard, efficient design. It doesn't directly cause performance issues because the engine only has to follow a simple many-to-one lookup path. The real bottleneck appears upstream, where the Product-to-Category relationship is bidirectional; that relationship causes filters to bounce back and forth and cascades into the Sales table. So even though Sales–Product participates in the filter chain, the inefficiency originates from the Product–Category relationship, making this option incorrect.

To add a calculated column to the Sales table

Why it fails: A calculated column is added to an existing table in the data model via the Data View or computed with CALCULATE/ADDCOLUMNS inside a table expression, but SUMMARIZE returns a brand-new standalone table in a DAX query. It does not modify the Sales table by adding a column; rather, it projects grouped columns and aggregates. The presence of SUM(Sales[Amount]) in the query might suggest a column, but it is an aggregation over a group, not a persistent column definition.

To add a new row for total sales per category

Why it fails: SUMMARIZE creates a new table object rather than inserting rows into the Sales table. The rows it generates represent each unique product category, not additional rows appended to an existing table with a 'Total' category for overall sales. While SUMMARIZE can include a grand total row if the query is written with ROLLUP, the basic pattern shown in the exhibit simply groups by Category and computes per-category totals, not an added summary row to the Sales table.

To filter the Sales table by Product Category

Why it fails: Filtering the Sales table by Product Category would narrow the rows being considered (e.g., via CALCULATE with a filter argument or a FILTER function) and preserve the original granularity. SUMMARIZE instead collapses the Sales table by grouping rows into categories and computing an aggregate (SUM of Amount) per group. It does not reduce the number of rows in the Sales table; it produces an entirely new summary table, so calling it a filtering operation misrepresents its purpose and output.

The notify option should be set to 'OnFailureOrSuccess' to get alerts.

Why it fails: Notification settings only control whether emails are sent on failure or success; they never influence whether the refresh itself executes. It tempts because alerts feel operationally relevant, but the correct cause lies in the data source credentials, gateway, or query timeout, not the notify toggle.

The refresh time is outside the allowed window for Premium capacities.

Why it fails: Premium capacities impose no restricted time window for scheduled refreshes; any time of day is permitted. This distracts candidates who assume capacity tiers throttle timing, yet the actual constraint is the dataset's data source credentials or gateway configuration, not the clock.

The dataset is in a Premium capacity, which does not support scheduled refresh.

Why it fails: Premium capacities fully support scheduled refresh, so this premise is false; the failure stems from a genuine configuration or credential issue. It tempts candidates who confuse Premium's capacity-based licensing with refresh capability, but Premium is precisely the tier that enables larger refresh limits and XMLA endpoints.