Troubleshooting practice questions

You are auditing data access in a Microsoft Fabric workspace and notice unexpected 'Access Denied' errors in the OneLake logs for a service principal that should have read-only access. The service principal has the 'Viewer' role in the workspace. What is the most likely cause?

Trap 1: The service principal needs the 'Contributor' role to read data.

The 'Viewer' role is specifically designed for read-only access and should be sufficient for reading data from OneLake. Moving to 'Contributor' provides write permissions, which are unnecessary for simple data reading and would violate the principle of least privilege in a production analytics environment.

Trap 2: The service principal has exceeded its OneLake throughput quota.

Exceeding a throughput quota would typically result in a 'Throttling' or 'Too Many Requests' error (HTTP 429), not an 'Access Denied' error (HTTP 403). Access Denied is strictly related to authentication and authorization settings rather than the volume of data being read or the rate of requests.

Trap 3: OneLake does not support service principal authentication.

OneLake fully supports service principal authentication through standard Azure Active Directory (now Microsoft Entra ID) mechanisms. This is a common practice for automated pipelines and service-to-service communication within Fabric, making this explanation technically incorrect regarding the platform's capabilities and security architecture.

A
The service principal needs the 'Contributor' role to read data.
Why wrong: The 'Viewer' role is specifically designed for read-only access and should be sufficient for reading data from OneLake. Moving to 'Contributor' provides write permissions, which are unnecessary for simple data reading and would violate the principle of least privilege in a production analytics environment.
B
OneLake data access control (preview) is restricting specific folders.
When OneLake data access control is enabled, it allows for more granular security than workspace roles. Even with a 'Viewer' role, if the specific path or folder in the Lakehouse has been restricted via these granular permissions, the service principal will receive an 'Access Denied' error when attempting to read.
C
The service principal has exceeded its OneLake throughput quota.
Why wrong: Exceeding a throughput quota would typically result in a 'Throttling' or 'Too Many Requests' error (HTTP 429), not an 'Access Denied' error (HTTP 403). Access Denied is strictly related to authentication and authorization settings rather than the volume of data being read or the rate of requests.
D
OneLake does not support service principal authentication.
Why wrong: OneLake fully supports service principal authentication through standard Azure Active Directory (now Microsoft Entra ID) mechanisms. This is a common practice for automated pipelines and service-to-service communication within Fabric, making this explanation technically incorrect regarding the platform's capabilities and security architecture.

Question 2mediummultiple choice

You are troubleshooting a slow-running Power BI report connected to a Fabric Semantic Model. What is the most effective way to identify the bottleneck?

Trap 1: View the workspace storage metrics

Storage metrics provide information on how much data is consumed by items in a workspace but do not show query execution times or visual performance. They are useful for managing capacity footprint but irrelevant for troubleshooting slow report rendering or inefficient DAX code.

Trap 2: Check the Fabric capacity SKU settings

SKU settings define the compute limits for the entire capacity. While an undersized SKU can lead to throttling, it is unlikely to be the cause of a single report being slow while others function normally. The bottleneck is usually the report design, not the SKU.

Trap 3: Rebuild the semantic model from scratch

Rebuilding the model is a destructive and time-consuming process that does not guarantee improved performance. Without first identifying the root cause of the slowness using diagnostic tools, you may simply recreate the same performance issues in the new model.

A
Use the Power BI Performance Analyzer
Performance Analyzer records the time taken for each visual to refresh, including DAX query execution and visual rendering. It provides a detailed breakdown of where time is spent, making it the most effective tool for identifying bottlenecks within a report's specific components.
B
View the workspace storage metrics
Why wrong: Storage metrics provide information on how much data is consumed by items in a workspace but do not show query execution times or visual performance. They are useful for managing capacity footprint but irrelevant for troubleshooting slow report rendering or inefficient DAX code.
C
Check the Fabric capacity SKU settings
Why wrong: SKU settings define the compute limits for the entire capacity. While an undersized SKU can lead to throttling, it is unlikely to be the cause of a single report being slow while others function normally. The bottleneck is usually the report design, not the SKU.
D
Rebuild the semantic model from scratch
Why wrong: Rebuilding the model is a destructive and time-consuming process that does not guarantee improved performance. Without first identifying the root cause of the slowness using diagnostic tools, you may simply recreate the same performance issues in the new model.

Question 3hardmultiple choice

Refer to the exhibit. A data engineer is troubleshooting a Spark job that frequently fails with 'Out of Memory' (OOM) errors despite the configuration shown. The job processes a 500GB dataset with many wide transformations. What is the most effective configuration change to resolve the OOM errors?

Exhibit

{
  "executorMemory": "16g",
  "executorCores": 4,
  "dynamicAllocation": true,
  "maxExecutors": 20,
  "vorderEnabled": true
}

Trap 1: Set dynamicAllocation to false and use 50 static executors.

Disabling dynamic allocation and using static executors can lead to resource waste and does not solve the memory pressure within an individual executor. If one executor is running out of memory due to data skew or large partitions, adding more executors will not prevent that specific failure.

Trap 2: Increase the executorCores to 8 to allow more tasks to run.

Increasing the number of cores per executor while keeping memory constant actually reduces the amount of memory available to each individual task. This will likely worsen the Out of Memory situation because more tasks will be competing for the same 16GB of executor heap space.

Trap 3: Set vorderEnabled to false to reduce the memory overhead.

V-Order is an optimization for the write phase and does not significantly impact the memory consumption of Spark transformation tasks during the shuffle or execution phase. Disabling it would negatively impact the read performance of downstream applications without resolving the OOM errors in the current job.

A
Set dynamicAllocation to false and use 50 static executors.
Why wrong: Disabling dynamic allocation and using static executors can lead to resource waste and does not solve the memory pressure within an individual executor. If one executor is running out of memory due to data skew or large partitions, adding more executors will not prevent that specific failure.
B
Increase the executorCores to 8 to allow more tasks to run.
Why wrong: Increasing the number of cores per executor while keeping memory constant actually reduces the amount of memory available to each individual task. This will likely worsen the Out of Memory situation because more tasks will be competing for the same 16GB of executor heap space.
C
Increase executorMemory and decrease executorCores per executor.
By increasing memory and decreasing cores, you provide more memory to each individual task running on that executor. This is a standard approach for handling wide transformations or large shuffles where each task requires a significant amount of memory to store intermediate data structures without spilling to disk or crashing.
D
Set vorderEnabled to false to reduce the memory overhead.
Why wrong: V-Order is an optimization for the write phase and does not significantly impact the memory consumption of Spark transformation tasks during the shuffle or execution phase. Disabling it would negatively impact the read performance of downstream applications without resolving the OOM errors in the current job.

Question 4mediummultiple choice

You are monitoring a Data Factory pipeline. What is the best way to be notified when a pipeline fails during an execution?

Trap 1: Manually refresh the monitor tab

Manual monitoring is inefficient and reactive. It does not scale to handle complex enterprise environments with many pipelines. Relying on manual checks will lead to delayed problem detection and potential data quality issues, making it an inferior approach compared to automated, policy-driven alerting systems.

Trap 2: Check the SQL database logs

SQL logs only show database-level errors. Pipeline-level failures (like network timeout or orchestration errors) will not appear in the database logs. Relying on database logs provides an incomplete view of the pipeline's health, leading to missed errors and inaccurate reporting on the overall status of your integration.

Trap 3: Run a daily Notebook to check status

This approach is overly complex and introduces an extra dependency on a Notebook just to monitor status. It is slower than native alert mechanisms and does not provide real-time feedback. Alerting should be a native configuration of the pipeline platform, not a custom-coded task that requires maintenance.

A
Manually refresh the monitor tab
Why wrong: Manual monitoring is inefficient and reactive. It does not scale to handle complex enterprise environments with many pipelines. Relying on manual checks will lead to delayed problem detection and potential data quality issues, making it an inferior approach compared to automated, policy-driven alerting systems.
B
Use the alerts in the monitoring hub
The monitoring hub in Fabric provides built-in capabilities to set up alerts. By configuring these, you can receive notifications immediately upon failure. This proactive approach is the standard recommended practice for maintaining pipeline reliability and operational excellence in Microsoft Fabric, ensuring you stay informed without needing constant manual oversight.
C
Check the SQL database logs
Why wrong: SQL logs only show database-level errors. Pipeline-level failures (like network timeout or orchestration errors) will not appear in the database logs. Relying on database logs provides an incomplete view of the pipeline's health, leading to missed errors and inaccurate reporting on the overall status of your integration.
D
Run a daily Notebook to check status
Why wrong: This approach is overly complex and introduces an extra dependency on a Notebook just to monitor status. It is slower than native alert mechanisms and does not provide real-time feedback. Alerting should be a native configuration of the pipeline platform, not a custom-coded task that requires maintenance.

Question 5easymultiple choice

A Data Factory pipeline in Fabric fails during the execution of a Copy activity. You need to find the specific error message and the number of rows successfully written before the failure. Where should you look?

Trap 1: The Spark UI environment logs

Copy activities in Data Factory do not necessarily run on Spark unless specifically configured to use a Spark-based connector or notebook. Checking Spark logs for a standard Copy activity would likely yield no information, as the execution occurs within the Data Integration service rather than a Spark cluster.

Trap 2: The OneLake data access logs

OneLake data access logs show who accessed which files and when, but they do not contain the internal logic or failure details of a Data Factory pipeline. These logs are security-focused and lack the row-level telemetry or activity-specific error messages required for debugging a failed pipeline execution.

Trap 3: The Capacity Metrics 'Overages' view

The Overages view tracks compute usage against the capacity limit and would show if a pipeline was throttled, but it cannot provide the specific reason for a logic failure or row count statistics. Throttling and activity failures are distinct events that require different tools for proper analysis and resolution.

A
The Spark UI environment logs
Why wrong: Copy activities in Data Factory do not necessarily run on Spark unless specifically configured to use a Spark-based connector or notebook. Checking Spark logs for a standard Copy activity would likely yield no information, as the execution occurs within the Data Integration service rather than a Spark cluster.
B
The pipeline run details in the Monitoring Hub
The Monitoring Hub allows you to drill down into the specific pipeline run and then into the activity details. Clicking the 'output' icon for the failed Copy activity provides a JSON response containing the error message and the execution statistics, including the row counts for both source and destination.
C
The OneLake data access logs
Why wrong: OneLake data access logs show who accessed which files and when, but they do not contain the internal logic or failure details of a Data Factory pipeline. These logs are security-focused and lack the row-level telemetry or activity-specific error messages required for debugging a failed pipeline execution.
D
The Capacity Metrics 'Overages' view
Why wrong: The Overages view tracks compute usage against the capacity limit and would show if a pipeline was throttled, but it cannot provide the specific reason for a logic failure or row count statistics. Throttling and activity failures are distinct events that require different tools for proper analysis and resolution.