A data engineering team runs many small notebook jobs in a Microsoft Fabric workspace. Each job currently waits several minutes before its Spark session is ready, and the delay dominates the short run times. The team wants new sessions to start in a few seconds without permanently reserving compute. Which Spark workspace setting should they configure to meet this requirement?
- AKeep the starter pool enabled so pre-warmed nodes back the workspace, letting Spark sessions begin in seconds without reserving a dedicated cluster. Correct
- BRaise the default node size on the starter pool so each session has more memory and processing power available the moment it begins running.
- CEnable high concurrency for the workspace so several notebooks share one Spark session and a new notebook reuses the already-running session.
- DCreate a custom Spark pool with autoscale disabled and a fixed minimum node count so the cluster is always sized and ready for incoming jobs.
Why A is correct: The starter pool holds pre-allocated, pre-warmed nodes for the workspace, so a session attaches in a few seconds and the nodes are released when idle, which matches the need for fast starts without permanently reserved compute.
Why B is wrong: Larger nodes give each session more compute but do nothing about the cold-start delay; provisioning time is the stated problem, and bigger nodes can actually take longer to acquire rather than shortening startup.
Why C is wrong: High concurrency lets notebooks share a session and helps once a session exists, but the very first session in the workspace still pays the full provisioning cost, so it does not on its own deliver the few-second start the team wants.
Why D is wrong: A custom pool with a fixed floor would be ready, but a cold custom pool still provisions on demand and a permanent floor reserves compute continuously, which contradicts the requirement to avoid permanently reserving capacity.