Refer to the Exhibit Practice Questions

Increase 'spark.dynamicAllocation.maxExecutors' to 20.

Why wrong: Increasing the maximum number of executors allows the job to scale out more, but it does not change the amount of memory available to any single executor. If a single task in a shuffle requires more than 4GB, adding more executors will not fix the OutOfMemoryError on that specific task.

Decrease 'spark.executor.cores' to 1.

Why wrong: Decreasing the cores would reduce the number of concurrent tasks per executor, which might indirectly reduce memory pressure. However, it is a sub-optimal solution that reduces parallelism and slows down the job. Increasing memory is the standard and more effective way to handle memory-intensive operations in Spark.

Set 'spark.dynamicAllocation.enabled' to 'false'.

Why wrong: Disabling dynamic allocation forces the job to use a fixed number of executors. This would likely make the problem worse or lead to inefficient resource usage, as it does not address the memory limit of the executors themselves, which is the root cause of the failure during the shuffle phase.

Increase the Fabric capacity SKU immediately

Why wrong: While upgrading the SKU provides more headroom, it is a costly reactive measure. Without first optimizing the underlying data processes that are causing the capacity spikes, the new capacity may eventually face the same throttling issues as the workloads continue to scale ineffectively.

Configure retry policies with exponential backoff

Why wrong: Implementing exponential backoff is a best practice for handling transient errors and throttling in distributed systems. However, this is a mitigation technique that handles the symptom rather than solving the underlying resource contention caused by poorly performing or overlapping data jobs.

Disable monitoring to reduce overhead

Why wrong: Disabling monitoring is never an appropriate solution, as it eliminates visibility into system health. Without logs and metrics, you would have no way of knowing when your pipelines are failing, and you would be unable to perform the necessary troubleshooting to resolve performance degradation.

The Lakehouse is only accessible from within a specific Azure VNET.

Why wrong: Managed Private Endpoints secure the connection *from* Fabric *to* an external data source (like Azure SQL or ADLS Gen2). They do not, by themselves, restrict how users access the Fabric workspace or Lakehouse from their own client machines or corporate networks, which is handled by different networking settings.

The Lakehouse has been shared with an external guest user.

Why wrong: The 'hasManagedPrivateEndpoint' property is strictly a networking and infrastructure configuration. It has no relationship with the sharing status of the item or the presence of B2B guest users. Sharing and external access are managed through the workspace permissions and Entra ID (formerly Azure AD) settings.

OneLake shortcuts are disabled for this specific Lakehouse.

Why wrong: The presence of a Managed Private Endpoint does not disable shortcuts. In fact, Managed Private Endpoints are often used *to enable* shortcuts to work securely with data sources that are otherwise unreachable due to network restrictions. They are complementary features rather than mutually exclusive configurations.

ALTER TABLE SalesData ADD COLUMN Location String

Why wrong: Adding a new column does not influence the physical layout or the storage performance of existing data. While it might be required for business logic, it has no impact on query optimization or performance bottlenecks related to filtering on the TransDate column.

DROP TABLE SalesData; CREATE TABLE SalesData ... CLUSTER BY (ID)

Why wrong: Clustering by ID is ineffective for queries that filter by TransDate. Data clustering should be aligned with the columns used in frequent predicates. Creating a cluster on the ID column would provide no benefit for date-based queries, failing to resolve the performance issue for the target users.

VACUUM SalesData

Why wrong: The VACUUM command is used for cleaning up historical files and maintaining storage hygiene, not for improving query execution speed. While it is important for cost and metadata management, it does not reorganize the data layout to facilitate efficient filtering or partition skipping during query execution.

The pipeline fails immediately.

Why wrong: The configuration explicitly defines a retry policy with a count of 3. Therefore, the pipeline will not fail immediately. It will wait for the specified interval and then attempt the operation again to recover from the transient failure detected during the first execution.

The pipeline retries indefinitely.

Why wrong: The retry count is explicitly set to 3. There is no configuration in the exhibit that would trigger an infinite loop or indefinite retries. The pipeline will stop retrying once the defined limit of 3 attempts is reached, after which it will report a final failure.

The pipeline executes the next activity immediately.

Why wrong: If the Copy activity fails and the retry policy is active, the pipeline engine pauses execution to perform the retry. It does not skip the current activity or proceed to downstream activities until all retry attempts are exhausted or the activity finally succeeds.

Increase the 'numExecutors' value to 10.

Why wrong: Increasing the number of executors actually increases the resource demand on the Fabric capacity. During periods of high utilization, requesting more executors is more likely to result in the job being queued or failing due to lack of available CUs, rather than helping it succeed during contention.

Change the 'runtimeVersion' to 1.3.

Why wrong: Upgrading the runtime version provides newer Spark features and library updates but does not directly address resource availability or transient failures caused by capacity throttling. Runtime versions are generally changed for compatibility or performance improvements within the Spark engine itself rather than for retry logic.

Change the 'driverSize' to 'Large'.

Why wrong: Selecting a larger driver size allocates more memory and CPU to the Spark driver node. While this helps with jobs handling large metadata or complex orchestrations, it does not help with retry logic or capacity-based failures; it actually consumes more Capacity Units, potentially worsening the contention issue.

The activity will append new rows to the existing table data.

Why wrong: For the activity to append data to the existing table, the tableAction property would need to be set to Append. The current Overwrite setting ensures that the existing rows are removed before the new data is committed, preventing the accumulation of historical data within the target table.

The pipeline will fail because the table already exists.

Why wrong: The activity will not fail if the table exists; instead, it will perform the action defined by the Overwrite property. Failures usually occur if there are schema mismatches that the engine cannot resolve or if the service principal lacks the necessary permissions to drop and recreate table data.

A new table with a timestamp suffix will be created.

Why wrong: While the activity will create the table if it does not already exist, the primary function of the Overwrite setting when a table is present is to replace the data. It does not create a new versioned table or a separate entity with a different name automatically.

The underlying data source is offline.

Why wrong: If the data source were offline, you would receive a connection timeout or a network error, not a '429 Too Many Requests' status. A 429 error is strictly related to capacity throttling, meaning the service is rejecting incoming requests because they exceed the resource limits.

The user does not have read permissions.

Why wrong: Lack of permissions results in a '403 Forbidden' or '401 Unauthorized' error code. The 429 error is specifically reserved for rate limiting and service throttling, which indicates the request is authenticated correctly but is blocked due to excessive resource utilization on the capacity.

The query contains a syntax error.

Why wrong: Syntax errors result in '400 Bad Request' or specific SQL engine errors during the compilation phase. A 429 error is generated by the load balancer or the service management layer, not by the SQL engine itself, regardless of the query content or its validity.

The RemoteScan is failing to find the Parquet files in OneLake.

Why wrong: If the RemoteScan failed to find files, the query would result in an error rather than just being slow. The query plan shows that the scan is a part of the execution, meaning the engine has successfully located the metadata and is proceeding to read the data from OneLake storage.

The HashJoin is using an unsupported data type for the join condition.

Why wrong: Unsupported data types would prevent the query from being compiled or executed by the SQL Analytics Endpoint. Since the plan shows a HashJoin operator, the engine has already validated the join condition and determined that a hash-based join is the most appropriate physical operation for the provided SQL.

OneLake storage is currently in a read-only state due to maintenance.

Why wrong: OneLake is designed for high availability and does not typically enter a 'read-only' state that would allow query planning but slow down execution. Any storage-level availability issues would manifest as connection errors or time-outs rather than a specific operator like a BroadcastExchange appearing in a query plan.

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.

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.

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.

Increase the cluster memory size.

Why wrong: Adding more memory does not resolve the inefficient practice of reading unnecessary data from storage. Even with more memory, the engine must still perform the I/O for all columns in the table, which is the primary source of the performance overhead in this scenario.

Add a clustered index to all columns.

Why wrong: Adding indexes to all columns would cause massive storage overhead and slow down write operations significantly. It does not address the inefficiency of the 'SELECT *' statement and is not a practical solution for optimizing a large-scale analytical query.

Enable query parallelism.

Why wrong: Query parallelism is already managed by the Fabric engine. Forcing it or assuming it is not active does not solve the fundamental issue of data volume. You must first reduce the data being scanned before parallelism can effectively accelerate the remaining, more optimized workload.

It enables encryption at rest for all Parquet files generated in the session.

Why wrong: The provided configuration is focused on performance optimization and data layout rather than security or encryption. Encryption in Fabric is handled at the service and storage levels (OneLake) automatically and is not toggled through these specific Spark SQL parameters. Confusing performance settings with security protocols can lead to incorrect assumptions about data protection strategies.

It forces the notebook to use a high-concurrency Spark pool for all users.

Why wrong: Session configurations set via '%%configure' affect the internal Spark engine settings and library paths, but they do not control the underlying pool selection or concurrency model. Pool assignment is typically managed at the workspace or environment level rather than through inline session JSON code. This configuration is about data format optimization, not resource scheduling or pool management.

It disables the creation of transaction logs to save storage space in OneLake.

Why wrong: Delta Lake relies on transaction logs for ACID compliance, and the exhibit does not contain any settings that would disable these logs. In fact, 'optimizeWrite' actually improves the management of the Delta log by ensuring the data files are written more efficiently. Disabling transaction logs would break the Delta table functionality and is not a standard practice in Fabric.

The extra column is automatically dropped.

Why wrong: Dropping columns automatically is characteristic of 'flexible' or 'permissive' schema mapping. The 'strict' validation flag explicitly forbids this behavior to ensure that the data landing in the sink is exactly as defined, preventing potential data loss or ingestion of unexpected fields into the analytical model.

The extra column is added to the destination schema.

Why wrong: Adding columns dynamically is a feature of 'schema evolution' or 'permissive' modes. Under 'strict' configuration, the Dataflow will not alter the target table schema. It will reject the incoming data packet because it violates the predefined contract between the source and the sink structure.

The extra column is logged as a warning.

Why wrong: Dataflow Gen2 strict validation does not default to logging warnings and continuing. It is designed to be a blocking operation to ensure compliance with data governance policies. Simply logging a warning would bypass the integrity checks that the 'strict' mode is intended to enforce.

It is used to store the schema definition.

Why wrong: Schema information is typically inferred or stored within the Delta transaction log, not in the checkpoint path. The checkpoint is specifically for managing the streaming state and progress, not for handling the schema definition of the data being ingested into the table.

It increases the throughput of the write operation.

Why wrong: Checkpointing actually adds a minor overhead to the streaming process, as metadata must be written to the checkpoint directory. Its primary purpose is correctness and fault tolerance, not performance improvement. The trade-off is necessary for maintaining reliable data pipelines, even if it does not boost raw ingestion speed.

It is required for overwriting existing tables.

Why wrong: Overwriting a table is a standard Delta operation that does not require streaming checkpoints. Checkpoints are strictly for stateful streaming jobs. If you are doing a batch write, you do not need to configure a checkpoint path, as it is irrelevant to standard batch ingestion tasks.

The recursive flag is set to true, causing the sink to attempt to merge multiple schemas.

Why wrong: Recursive flag simply tells the activity to look into subdirectories. It does not interfere with the initial schema inference logic itself. While recursive ingestion might lead to schema drift if files differ, it is not the primary cause of an immediate failure to infer the base schema.

AzureBlobFSReadSettings does not support schema inference from delimited files.

Why wrong: AzureBlobFSReadSettings is fully capable of reading delimited files and performing initial column discovery. The issue is not the read capability but rather how the sink interprets the output metadata during the table creation process when moving data between different storage formats in the Fabric environment.

The Copy activity requires an Execute Pipeline activity to initialize the sink.

Why wrong: A Copy activity is sufficient on its own to move data and create tables. There is no architectural requirement for an Execute Pipeline activity to initialize a sink. Adding unnecessary layers of orchestration does not resolve underlying configuration issues related to type mapping or schema definition.