Select Two (Multi-Select) Questions

The DAX query plan for the most expensive visuals in a report.

Why wrong: Lineage view is a high-level metadata map and does not provide deep technical diagnostics like DAX query plans. For query optimization, engineers should use tools like DAX Studio or the Power BI Performance Analyzer. Lineage focuses on the 'where' and 'how' of data flow, not the 'how fast' of calculations.

A list of individual users who have viewed a specific report in the last 30 days.

Why wrong: Usage information is found in the 'Usage Metrics' reports, not the Lineage view. Lineage view is concerned with the structural relationships between technical items, while usage metrics are concerned with user engagement and consumption patterns. Both are important for maintenance but serve different analytical purposes.

The physical storage location of the Delta files in OneLake.

Why wrong: While Lineage view shows the Lakehouse item, it does not provide the low-level file path or folder structure of the underlying Delta tables in OneLake. That information is accessed through the Lakehouse explorer or OneLake File Explorer. Lineage view remains at the item level of the Fabric ecosystem.

Automatically convert a Power BI report into a Paginated report during the deployment.

Why wrong: Deployment pipelines are designed to move and configure items, not to change their fundamental type or internal structure. Power BI reports and Paginated reports use different file formats and rendering engines. Converting between these types requires manual redesign and cannot be handled by the deployment automation process provided by Fabric pipelines.

Restore a deleted workspace by reverting to a previous pipeline deployment stage.

Why wrong: Pipelines manage the content within workspaces but do not act as a backup and restore mechanism for the workspaces themselves. If a workspace is deleted, it must be recovered through the Microsoft 365 admin center or recreated. Pipelines can redeploy content to a new workspace, but they cannot restore the original workspace object.

Encrypt individual columns in a Lakehouse table using a custom key during the sync.

Why wrong: Deployment pipelines do not modify the internal data or schema of Lakehouse tables, such as applying column-level encryption. Security configurations like encryption at rest are handled at the capacity or storage level, not through the deployment pipeline interface. The pipeline's role is focused on the movement and metadata configuration of the workspace items.

Enable 'DirectQuery' for all semantic models to reduce memory load.

Why wrong: DirectQuery can actually increase the load on both the capacity and the source systems because it generates queries for every visual interaction. While it saves memory, it significantly increases the CPU usage required to translate and execute those queries. This often worsens interactive delays rather than mitigating them.

Increase the 'Refresh Frequency' of all reports to ensure data freshness.

Why wrong: Increasing refresh frequency directly increases the total capacity units consumed by background operations. This would likely lead to more frequent throttling and delays. Maintenance should focus on finding the right balance between data freshness and available resources, rather than maximizing refresh cycles without considering the impact.

Disable the 'Smoothing' feature in the Fabric Admin portal.

Why wrong: Smoothing is a built-in architectural feature of Fabric capacity that cannot be disabled by users. It is designed to help handle spikes in demand by spreading the cost of operations over time. Attempting to change this (if it were possible) would likely make performance even more volatile.

Convert all calculated columns in the semantic model to Power Query M columns.

Why wrong: While moving logic upstream is generally good practice, converting calculated columns specifically to M does not address the core performance issues of Direct Lake. Direct Lake models actually perform best when logic is handled in the Lakehouse via Spark or SQL before the data reaches the model, as calculated columns in the model can trigger a fallback.

Increase the 'Max Intermediate Rows' setting in the Power BI capacity settings.

Why wrong: Adjusting the maximum intermediate rows is a capacity-level setting that limits the size of result sets during query processing. While it might prevent some queries from failing, it does not optimize the performance of the model itself. It is a safety threshold rather than an optimization technique for improving the speed of Direct Lake data retrieval.

Assign individual user permissions to each item within the workspace for granular control.

Why wrong: Assigning permissions at the item level to individual users is a maintenance nightmare that leads to 'permission bloat' and security gaps. It makes it extremely difficult to audit who has access to what and to revoke access when users change roles. This approach is not scalable and increases the administrative burden on the IT team.

Create a separate capacity for every workspace to isolate resource consumption.

Why wrong: Creating a separate capacity for every workspace is cost-prohibitive and inefficient. Microsoft Fabric capacities are designed to be shared across multiple workspaces, with the system managing resource allocation dynamically. A better approach is to monitor capacity usage and group related workspaces together on a capacity that matches their combined resource requirements and performance needs.

Disable the 'Tenant settings' for all users except for one global administrator.

Why wrong: While tenant settings should be restricted, disabling them for all but one person creates a single point of failure and administrative bottleneck. Maintenance is better served by having a small group of trained Fabric Administrators who can manage settings. This ensures that critical updates and governance policies can be applied promptly even if one administrator is unavailable.

Delete the conflicting items from the workspace and re-import them.

Why wrong: Deleting items is a destructive action that can break downstream dependencies and lineage. It also loses the version history associated with those specific items within the Fabric environment. This approach is inefficient and circumvents the proper Git workflow intended for collaborative development and safe maintenance of data assets.

Use the 'Undo changes' command in the Source Control side pane.

Why wrong: The 'Undo changes' command reverts local workspace modifications to match the current state of the connected branch. While this resolves the conflict status, it does so by discarding all uncommitted work in the workspace. This is not a resolution strategy but rather a complete surrender of local progress.

Change the workspace connection to a new empty branch.

Why wrong: Switching to a new branch avoids the immediate conflict but does not resolve the underlying issue in the original branch. This fragments the development process and makes it difficult to consolidate work later. It is a temporary workaround that complicates the long-term maintenance of the data analytics solution.

Data Pipelines

Why wrong: Data pipelines are typically considered upstream or lateral processes that move data into the Lakehouse. While they are part of the lineage, impact analysis specifically focuses on the downstream consumers that would be 'broken' by a change. Pipelines would need to be checked separately for logic compatibility.

Gateway connections

Why wrong: Gateway connections are infrastructure components used to reach on-premises data sources. They are not data items themselves and do not appear in the impact analysis of a Lakehouse table. Changing a table schema in the cloud does not impact the configuration or status of an on-premises gateway.

Delete the Lakehouse and recreate it with the new schema to ensure all metadata is refreshed.

Why wrong: Deleting and recreating a Lakehouse is an extreme measure that would cause significant downtime and likely break all existing connections and permissions. It is not a standard maintenance procedure for a simple column rename. Schema evolution should be handled using ALTER TABLE commands or Spark transformations to preserve the object's identity.

Change the workspace name to include 'DEPRECATED' until the column rename is completed.

Why wrong: Renaming a workspace does not provide any technical benefit or impact analysis for a schema change. It may confuse users and does not address the underlying dependencies in the data models or reports. Maintenance should be handled through proper version control and the built-in impact analysis tools provided by Microsoft Fabric.

The number of users logged into the workspace.

Why wrong: While user concurrency is relevant to overall load, it is not a direct metric for identifying specific long-running queries. A single, poorly written query can consume more resources than hundreds of simple queries, making user counts a poor proxy for diagnosing individual query performance bottlenecks and code efficiency.

The number of files in the OneLake delta table.

Why wrong: While file count can influence scan performance, it is a secondary metadata metric rather than a direct query performance indicator. Monitoring the query itself is far more effective for optimization, as it tells you exactly what the engine is struggling to process during the execution phase.

The number of dashboards generated.

Why wrong: The number of dashboards created by users has no direct impact on the performance of the underlying SQL endpoint. Monitoring the output (dashboards) is irrelevant to diagnosing the performance of the data engine; you must monitor the input processes and the execution of the queries themselves.

The dataflow must use a Fabric Notebook as a destination.

Why wrong: Notebooks are not valid destinations for Dataflows Gen2; instead, dataflows output to Lakehouses, Warehouses, Azure SQL databases, or KQL Databases. Fast Copy is independent of the final destination type and is focused on the efficiency of the ingestion and transformation path within the Dataflow architecture.

A Premium Capacity (P1 or higher) must be assigned to the workspace.

Why wrong: While Fabric features require a capacity, Fast Copy is not restricted to specific Premium 'P' SKUs; it is available in Fabric capacities generally. The performance benefit is derived from the architectural bypass and staging settings rather than the specific tier of the capacity assigned to the workspace.

The source SQL Server must have the 'V-Order' property enabled.

Why wrong: V-Order is a Microsoft Fabric-specific optimization for Parquet and Delta files within a Lakehouse or Warehouse environment. It is not a feature or setting available on on-premises SQL Server instances, which use different storage engines and formats like B-tree indexes and Columnstore for performance.

Grant the user the Contributor role in the workspace.

Why wrong: The Contributor role provides broad access to create and manage items, including the ability to interact with data assets directly. Granting this level of access violates security best practices when users only require report consumption capabilities, as it provides far more permissions than the user actually needs.

Grant the user access to the Lakehouse folder via OneLake.

Why wrong: Granting folder-level access in OneLake exposes the raw files to the user, contradicting the requirement to prevent access to the underlying Lakehouse files. This action effectively bypasses the semantic model layer and exposes the Parquet files to the user for direct download and manipulation.

Add the user to the workspace Admin role.

Why wrong: The Admin role provides full control over all items, including the ability to delete assets and modify security settings. This level of access is highly excessive for a user who only needs to view a report and poses a significant security risk to the entire analytics solution.

Increase the number of small files in the table.

Why wrong: Creating many small files is a major performance anti-pattern. It increases metadata overhead and slows down the scan operations, as the engine must open and close numerous files instead of reading contiguous data blocks. This is a primary cause of poor performance in Lakehouse architectures.

Convert all tables to CSV format.

Why wrong: CSV is a text-based, row-oriented format that is extremely inefficient for analytical queries compared to the columnar Parquet format used in Delta tables. Converting to CSV would lead to massive performance degradation, as the engine would need to read the entire file instead of specific columns.