Maintain a Data Analytics Solution practice questions

Enable the 'Auto-commit' feature in the Fabric workspace settings for the main branch.

Why wrong: Enabling automatic commits directly to the main branch removes the opportunity for code review and peer validation. This practice increases the risk of deploying bugs or breaking changes into the primary codebase. It also fails to resolve conflicts effectively when multiple developers are working on overlapping items within the same Fabric workspace environment.

Grant all developers 'Admin' permissions on the production workspace to resolve sync conflicts.

Why wrong: Providing administrative access to production workspaces for all developers violates the principle of least privilege and introduces significant security risks. Conflict resolution should occur within the Git repository using standard merge tools rather than through workspace permissions. Excessive permissions can lead to accidental deletions or unauthorized configuration changes in the live environment.

Use a single shared workspace for all developers and perform manual exports of .pbip files.

Why wrong: Relying on a single shared workspace leads to frequent item locking and versioning conflicts between developers. Manual exports are inefficient, prone to human error, and bypass the automated benefits of Fabric's native Git integration. This approach lacks the scalability required for professional analytics teams and fails to provide a robust mechanism for tracking historical changes.

GET https://api.fabric.microsoft.com/v1/workspaces/{id}/items/{id}/status

Why wrong: The GET method on the status endpoint is used to retrieve the current state of an item, such as whether it is currently refreshing or if the last run succeeded. It does not initiate a new refresh action. While essential for monitoring the progress of a refresh, it cannot be used to trigger the start of the process itself.

POST https://api.fabric.microsoft.com/v1/workspaces/{id}/lakehouses/{id}/tables/refresh

Why wrong: Lakehouse tables do not have a 'refresh' endpoint in the same way semantic models do, as they are updated through Spark jobs or Data Factory pipelines. This endpoint is syntactically incorrect for the Fabric API. To update data in a Lakehouse, you would typically run a notebook or a dataflow, rather than calling a table refresh API.

PATCH https://api.fabric.microsoft.com/v1/workspaces/{id}/semanticModels/{id}

Why wrong: The PATCH method is typically used to update the metadata or properties of an existing object, such as changing its name or description. It is not used for operational tasks like triggering a data refresh. Using the wrong HTTP verb will result in an error, as the API expects a POST request for action-oriented operations like refreshing data.

Decrease the 'Archive period' to cover only the last 30 days of data.

Why wrong: Decreasing the 'Archive period' (or 'Store rows') would result in the loss of historical data. If you need to keep three years of data available for reporting, the archive period must remain at three years. This setting controls data retention, not the volume of data that is processed during an individual incremental refresh operation.

Enable the 'Only refresh complete days' toggle in the incremental refresh policy.

Why wrong: The 'Only refresh complete days' setting ensures that partial days at the end of a period are not included in the refresh until they are finished. While useful for data consistency, it does not solve the problem of refreshing too many years of historical data. It is a setting for precision rather than for limiting the total refresh window.

Change the 'Polling query' to return the maximum ID instead of a date timestamp.

Why wrong: A polling query is used with the 'Detect data changes' feature to determine if a refresh is needed at all. While it can prevent unnecessary refreshes when no data has changed, it does not limit the amount of data processed once a refresh is triggered. It is an optimization for frequency, not for the scope of the data window.

Enable the 'Allow service principals to use Power BI APIs' setting in the tenant admin portal.

Why wrong: While this tenant-level setting is a prerequisite for any service principal activity, the error message indicates the principal is already attempting the call but failing due to specific resource access. If the tenant setting were disabled, the error would likely occur earlier in the authentication process or be a broader 'Feature Not Enabled' type of exception.

Generate a new client secret for the Service Principal as the current one has expired.

Why wrong: An expired client secret would result in an authentication failure (401 Unauthorized) when the script first tries to get an access token from Entra ID. The exhibit shows a specific PowerBI/Fabric error message, which means the token was successfully acquired and sent, but the Fabric service itself rejected the principal's authorization to the workspace.

Assign the Service Principal the 'Contributor' role in the Azure subscription.

Why wrong: Azure subscription roles (RBAC) are separate from Fabric workspace permissions. Having 'Contributor' access to the subscription does not grant any rights inside the Fabric service or its workspaces. Maintenance of Fabric security must be performed within the Fabric portal or via Fabric-specific APIs, not through the general Azure resource management layer or subscription settings.

Create a manual checklist for all users to follow when creating a new workspace.

Why wrong: Manual checklists are unreliable and difficult to enforce as the number of users and workspaces grows. They rely on human diligence, which inevitably leads to inconsistencies and configuration drift. Automation and centralized policy enforcement are much more effective maintenance strategies for enterprise environments where security and standardization are top priorities for the organization.

Use the 'Workspace settings' menu in each individual workspace after creation.

Why wrong: Individually configuring every workspace is a repetitive and time-consuming task that is prone to errors. It does not provide any way to ensure that settings remain consistent over time or to apply changes globally when corporate policies evolve. This decentralized approach makes long-term maintenance and auditing significantly more difficult for the IT administration team.

Develop a custom Power App that replaces the standard Fabric workspace creation UI.

Why wrong: While possible via APIs, building a custom UI for workspace creation is a complex undertaking that requires significant development and ongoing maintenance. It is usually unnecessary because Fabric's native tenant settings and administrative APIs provide the required controls. Relying on a custom app can also break if Microsoft updates the underlying Fabric service architecture or APIs.

The total number of guest users invited to the Fabric tenant.

Why wrong: While important for security auditing, the number of guest users does not directly correlate with capacity performance or query rejection. A single guest user could run a massive query that consumes significant resources, or a hundred guest users could perform minimal activity. Capacity maintenance should focus on actual resource utilization rather than the count of specific user types.

The storage size of all Delta tables across all Lakehouses in the capacity.

Why wrong: Storage size is a separate metric from compute capacity (CUs). While large tables can impact costs and query speed, they do not directly cause 'Throttling' or 'Rejection' unless they are being actively queried or processed. Capacity maintenance for performance focuses on the compute power required to handle the workload, rather than the static volume of data stored.

Workspace permissions

Why wrong: Workspace permissions control who can view, edit, or manage items within a specific environment but do not influence data source configuration. While necessary for security, they cannot automate the redirection of connection strings between stages. Relying on permissions alone would require manual updates to the underlying dataset.

Git integration settings

Why wrong: Git integration is primarily used for version control and synchronizing item definitions with a remote repository. While it tracks changes to the model, it does not provide the environment-specific parameter mapping logic found in deployment pipelines. Using Git for this purpose would require complex branching and manual file edits.

Sensitivity labels

Why wrong: Sensitivity labels are used for data classification and protection, ensuring that sensitive information is handled according to corporate policy. They do not have the technical capability to modify connection strings or parameters during deployment. Labels persist across stages to maintain security but do not facilitate environment configuration.

The 'Storage' tab sorted by 'Workspace Name'.

Why wrong: The Storage tab focuses on the volume of data stored in OneLake and does not reflect the compute power used for queries or processing. While storage costs are important, they are separate from the compute capacity that causes operation delays. High storage usage does not directly result in compute throttling.

The 'Throttling' tab showing the 'Rejection' graph.

Why wrong: The Throttling tab shows when the capacity has exceeded its limits and is actively rejecting new requests. While this indicates a problem exists, it does not provide the item-level detail needed to identify the cause of the consumption. It is a symptom indicator rather than a diagnostic tool for specific items.

The 'Users' tab filtered by 'Active Sessions'.

Why wrong: The Users tab helps identify who is using the system but doesn't correlate directly to the computational load of individual operations. A single user could run a very expensive query, or many users could run very cheap ones. It is not the most effective way to identify resource-heavy items.

Verifying the last refresh time for individual tables in the model.

Why wrong: The storage table column chunks DMV focuses on physical storage metrics rather than processing metadata. To find refresh times, an engineer would typically use the DISCOVER_STORAGE_TABLES DMV or check the model properties. This query is too granular for simple refresh monitoring and focuses on data distribution instead.

Monitoring active user sessions and their current DAX queries.

Why wrong: User sessions are monitored using the DISCOVER_SESSIONS or DISCOVER_COMMANDS DMVs. The column chunks DMV is static regarding user activity and only describes the state of the data on disk/in-memory. It cannot provide real-time information about who is connected or what queries are currently being executed.

Checking for broken relationships between fact and dimension tables.

Why wrong: Relationship integrity is typically checked via the model view in Power BI Desktop or by querying the TMSL metadata. While storage chunks relate to the data, they do not describe the logical connections or referential integrity between tables. This query would not reveal if a relationship is missing or incorrectly configured.

Set the 'Sync-Mode' parameter to 'True' in the initial POST request body.

Why wrong: Most Fabric deployment and management APIs do not support a 'Sync-Mode' parameter to force synchronous behavior for long-running tasks. Forcing synchronous execution would lead to frequent timeout errors in the calling application. The asynchronous pattern is the architected way to handle these operations within the platform.

Increase the timeout value of the HTTP client to 3600 seconds.

Why wrong: Increasing the client timeout does not change the fact that the server returns a response immediately after accepting the task. The connection would simply sit idle while the server processes the task in the background. This is an inefficient use of resources and does not provide status updates during the process.

Use a 'Wait' command with a fixed duration of 10 minutes between API calls.

Why wrong: Fixed wait times are unreliable because operation durations vary based on system load and item complexity. A wait that is too short causes failures, while a wait that is too long makes the deployment pipeline unnecessarily slow. Dynamic polling is always preferred for professional maintenance and automation workflows.

Power BI Reports

Why wrong: Power BI reports are supported, allowing the visual layer of the analytics solution to be version-controlled. This enables teams to track changes to report layouts and visuals, revert to previous versions if errors are introduced, and use pull requests to review UI changes before they are deployed to production.

Reflex (Data Activator) items

Why wrong: Data Activator items are relatively new and are not currently supported for Git synchronization within Fabric. Maintaining these items requires manual configuration and monitoring within the workspace. Engineers should check the latest documentation frequently as the platform adds Git support for more item types over time.

Storage Accounts (External)

Why wrong: External storage accounts are infrastructure components and are not 'items' within a Fabric workspace that can be synchronized via Git integration. While they can be linked via Shortcuts, the configuration of the external account itself happens outside of the Fabric workspace management and Git sync flow.

The SQL Endpoint metadata has not finished synchronizing with the OneLake Delta tables.

Why wrong: The SQL Endpoint automatically discovers new data in the Lakehouse, but there can be a slight delay in this metadata sync. If the semantic model refreshes before the SQL Endpoint sees the new data, it will pull the old state. Ensuring the upstream data processing is fully finalized is key.

The user does not have the 'Viewer' role on the production workspace.

Why wrong: If the user lacked the 'Viewer' role, they would not be able to see the report at all, rather than seeing stale data. Access issues usually result in 'Access Denied' errors. Since the report is visible but the data is old, the problem is related to the data pipeline, not permissions.

The capacity is currently throttled due to high background activity.

Why wrong: Throttling would cause the refresh to fail or be delayed, but the question states the refresh was 'successful'. A successful refresh means the data was pulled into the model. Throttling affects the ability to perform work, not the 'staleness' of the data inside a successfully completed operation.

Increase the 'Max Parallelism' setting in the Fabric workspace properties.

Why wrong: Max Parallelism in the workspace usually refers to report settings or capacity settings, not the specific timeout of a Data Factory activity. Increasing parallelism during a timeout might actually worsen the problem by putting even more pressure on the already struggling gateway or source SQL Server, leading to more failures.

Convert the SQL Server table to a Delta table before the copy activity.

Why wrong: The 'Copy Data' activity is the tool used to perform the conversion/movement to the cloud. You cannot convert the on-premises SQL table to Delta format 'before' the copy activity within the context of a Fabric pipeline. This suggestion misrepresents the sequence of operations in a standard data ingestion workflow.

Switch the authentication method from 'Basic' to 'OAuth2'.

Why wrong: Authentication methods typically cause 'Unauthorized' or 'Forbidden' errors, not timeouts. A timeout means the connection was established but the data didn't move fast enough or the request took too long to process. Changing the credential type will not resolve an underlying performance or throughput issue in the data path.

Switch the storage mode to Import for all tables.

Why wrong: Switching to Import mode would require a full data ingestion process that defeats the purpose of the DirectLake capability. This would significantly increase management overhead and latency, failing to address the specific performance bottlenecks that occur within real-time direct queries against the OneLake delta parquet files.

Enable Query Caching in the semantic model settings.

Why wrong: Query caching only stores the results of previous executions and does not optimize the underlying data access pattern. In a DirectLake scenario, the performance issue usually lies in the engine fetching excessive data from Parquet files; caching does not solve the root cause of high memory pressure.

Increase the workspace capacity SKU level.

Why wrong: While upgrading the SKU provides more memory, it is a reactive and costly solution to a design-based performance issue. You should always optimize the model architecture first by removing unnecessary data points before resorting to scaling up your compute resources in the Microsoft Fabric environment.

The dataflow is missing the required compute capacity.

Why wrong: Dataflow Gen2 handles compute dynamically within the workspace. While capacity limits can cause performance issues, they rarely cause a complete access failure to the destination lakehouse. Access errors are almost always related to authentication credentials or authorization policies rather than the total amount of available computing power.

The gateway connection string is incorrectly formatted.

Why wrong: Dataflow Gen2 in Microsoft Fabric does not rely on traditional on-premises gateways for lakehouse destinations. It uses native Fabric connectivity. Pointing to a gateway configuration is likely a misunderstanding of the architecture; the issue is more likely related to the identity used to authorize the data write.

The source data is too large for the dataflow to process.

Why wrong: While processing large datasets might cause a timeout, it would typically present as a 'timeout' error rather than an 'inaccessible destination' error. An accessibility error specifically points to a failure in the handoff between the dataflow execution engine and the storage layer, not the data volume.

Use an M-query to filter data by the current date.

Why wrong: A simple date filter in M-query does not allow the Power BI service to perform partition management. Without specific RangeStart and RangeEnd parameters, the engine cannot distinguish between historical data and new data, leading to full refreshes that are inefficient and prone to performance issues with large datasets.

Set the refresh policy to 'Full' every time.

Why wrong: Setting the policy to 'Full' defeats the purpose of incremental refresh. It forces the system to re-import the entire dataset, which consumes excessive resources and increases the duration of the refresh job. This approach is not scalable and contradicts the goal of optimizing data analytics solutions in Fabric.

Use a custom SQL query in the Power Query editor.

Why wrong: While you can use custom SQL, it must still be integrated with the RangeStart and RangeEnd parameters to be effective for incremental refresh. A raw SQL query without parameterization will not allow the engine to perform the necessary partition-based filtering required for efficient data loading and management.

Define the RLS in each individual Power BI report.

Why wrong: Defining RLS within individual reports is prone to errors, hard to maintain, and difficult to audit. If you have multiple reports connected to the same model, the security logic would need to be replicated in each one, creating significant overhead and increasing the risk of inconsistent security application.

Define the RLS in the workspace security settings.

Why wrong: Workspace security controls access to the items, not the data within the semantic model. Attempting to manage RLS through workspace roles is impossible because workspace permissions are designed for administrative tasks and collaboration, not for granular filtering of specific data rows for different users within a dataset.

Define the RLS at the SQL endpoint of the Lakehouse.

Why wrong: While you can technically apply security at the SQL level, it is not the standard practice for Power BI reports. RLS in the semantic model is specifically optimized for Power BI's DAX engine, providing better performance and native integration with the user identity context when the report is rendered.

The reports will automatically switch to Import mode.

Why wrong: DirectLake does not automatically switch to Import mode during a capacity migration. If the new capacity is incompatible or insufficient, the report will simply fail to load or refresh because the engine cannot perform the necessary high-speed memory access required for the DirectLake storage mode to function properly.

The operation is seamless and has no impact on report performance.

Why wrong: Capacity migration involves changing the underlying compute power. Different capacities have different performance characteristics, memory limits, and SKU features. Assuming it is seamless ignores the potential for performance degradation or service interruption if the new capacity lacks the necessary resources to handle the current workload's demand for DirectLake.

The reports will be deleted and must be recreated.

Why wrong: Capacity migration does not delete the report items. The workspace metadata, reports, and semantic models remain intact. The primary risk is not data loss, but rather a change in the runtime environment's performance capabilities, which might necessitate performance tuning after the move is completed to restore previous performance levels.

The Power BI 'Performance Analyzer'.

Why wrong: The Performance Analyzer is specifically designed for Power BI report visuals, not for monitoring the compute or memory consumption of backend notebooks. It measures the duration of visual rendering and DAX queries, not the infrastructure resource utilization of data engineering processes like Spark notebooks in Fabric.

The Azure Monitor Log Analytics.

Why wrong: While Azure Monitor is powerful, the native Fabric Capacity Metrics app is the specialized, purpose-built tool for Fabric resource monitoring. Log Analytics requires additional configuration and might not provide the same integrated, out-of-the-box view of Fabric item performance that the Capacity Metrics app provides for administrators.

The 'Manage Gateways' interface.

Why wrong: The 'Manage Gateways' interface is used for configuring connections to on-premises data sources. It has no capability to monitor or report on the memory usage of Fabric notebooks or any other cloud-based compute activities within the Microsoft Fabric workspace environment, making it irrelevant for this task.

RLS only works for users in the Guest role.

Why wrong: RLS is designed to work for all users, regardless of their role. If it is correctly implemented in the semantic model, it should enforce row-level filters for any authenticated user. If users are bypassing it, the issue is not the user's role but rather the set of permissions they possess.

The data is cached in the browser.

Why wrong: Browser caching does not override RLS. If the data was secured via RLS in the model, the model itself is the gatekeeper. The browser only stores what it was permitted to see; it cannot retrieve unauthorized data that the semantic model filters out during the query execution process.

The Lakehouse has public access enabled.

Why wrong: Public access on the Lakehouse would be a security risk, but it does not directly explain why users are bypassing RLS in a report. RLS is a logic-based constraint within the semantic model, and the primary cause of users bypassing it is almost always excessive permission levels within the model.