Task 1.1: Configure Microsoft Fabric workspace settings

• AThe workspace admin turns on Customize compute configuration for items

  Incorrect

  That workspace toggle doesn't touch the capacity-level control that blocks creating custom pools.

• BThe workspace admin sets an environment with memory-optimized settings as the workspace default

  Incorrect

  An environment selects an existing pool and sizing; it can't create a custom pool the capacity forbids.

• CA capacity admin turns Customized workspace pools back on in the capacity settings

  Correct

  Custom pools need the capacity-level Customized workspace pools option, which a capacity admin controls.

• DA capacity admin moves the workspace to a larger capacity SKU

  Incorrect

  A larger SKU raises Spark limits, but custom pools stay unavailable while Customized workspace pools is off.

Workspace admins create custom Spark pools from the workspace's Spark settings, but only while the capacity allows it: the Customized workspace pools option in the capacity's Spark compute settings is on by default and a capacity admin can turn it off. Item-level compute customization, default environments and job admission settings work inside whatever the capacity permits.

• AA higher maximum node count for the starter pool in the workspace settings

  Incorrect

  Starter pools are best-effort and pre-warmed capacity isn't guaranteed; more nodes don't remove library install time either.

• BA custom Spark pool sized for the jobs, selected in the environment

  Incorrect

  A custom Spark pool provisions on demand, which takes about a minute or more per session start.

• CA custom live pool with a 06:00-08:00 schedule, attached to the environment

  Correct

  Live pools hydrate clusters for a scheduled window with the environment's libraries already installed, so sessions start in about five seconds.

• DHigh concurrency for pipelines, with each notebook joining a running session

  Incorrect

  Sharing helps only notebooks that meet the sharing conditions, and the first session still starts cold.

Starter pools are a best-effort optimization: when pre-warmed capacity isn't available, the session starts on demand, and environment libraries are installed at session start. A custom live pool keeps clusters hydrated during a schedule you define, with the attached environment's libraries baked in, and bills only while clusters are allocated in that window.

• AThe Spark session timeout in the Jobs tab of the workspace's Spark settings

  Correct

  Workspace admins set the session expiry for interactive notebook sessions here; the default is 20 minutes.

• BThe Set maximum job lifetime value in the workspace's Jobs settings

  Incorrect

  That job setting doesn't decide how long an idle interactive session stays alive.

• CThe high concurrency properties of the environment the notebooks use

  Incorrect

  High concurrency decides how notebooks share a session, not how long an idle interactive session stays alive.

• DThe autopause duration of the custom pool that hosts each session

  Incorrect

  A pool's autopause deallocates idle clusters; interactive notebook expiry is governed by the workspace session timeout.

In the workspace's Spark settings, the Jobs tab holds the Spark session timeout, which customizes the expiry of every interactive notebook session in the workspace (20 minutes by default). The other settings on that tab and in pools or environments don't extend an idle interactive session.

• AIn the workspace's high concurrency settings, turn on For notebooks

  Incorrect

  That setting covers interactive notebook sessions, not notebook sessions started by pipeline activities.

• BIn the workspace's high concurrency settings, turn on For pipeline running multiple notebooks

  Correct

  This setting packs notebook sessions that pipelines start into shared high concurrency sessions.

• CRemove the default lakehouse from the two LH_Curated notebooks

  Incorrect

  Notebooks without a default lakehouse share only with others that have none, so the two groups would still split.

• DTurn on Reserve maximum cores for the pipeline's Spark jobs

  Incorrect

  This changes how jobs are admitted to the capacity, not whether sessions are shared.

• EGive all four notebooks the same default lakehouse

  Correct

  Notebooks share a session only when they have the same default lakehouse, or none at all.

High concurrency for pipelines is a workspace setting (For pipeline running multiple notebooks). Among the sharing conditions, notebooks must have the same default lakehouse (or none), Spark compute configuration and library packages; inline installs in cells don't prevent sharing. Here the environment is shared, so the different default lakehouses are what still splits the sessions.

• AA four-hour Spark session timeout in the workspace's Jobs settings

  Incorrect

  A session timeout doesn't stop a job that's still busy, so the runaway run keeps going.

• BReserve maximum cores for active Spark jobs in the workspace's Jobs settings

  Incorrect

  Reserving cores changes admission; it doesn't stop a job that has already run for hours.

• CA custom pool with autoscale turned off and a fixed number of nodes

  Incorrect

  A fixed pool caps how much compute a job gets, not how long it can run.

• DA four-hour Set maximum job lifetime limit in the workspace's Jobs settings

  Correct

  It cancels user-submitted jobs that run past the limit and doesn't affect system-managed jobs such as table maintenance.

Set maximum job lifetime is a workspace guardrail: when it's on, Fabric cancels user-submitted jobs (interactive and scheduled notebook runs, pipeline-run notebooks, Spark job definitions and Livy sessions) that exceed the limit. System-managed jobs, including lakehouse table maintenance and materialized lake view refreshes, aren't affected.

• AFabric administrator

  Correct

  Creating a domain requires a Fabric admin.

• BDomain admin of an existing domain

  Incorrect

  Domain admins manage the domains they administer; they can't create new domains.

• CDomain contributor

  Incorrect

  Domain contributors can't create domains.

• DWorkspace admin of the marketing workspace

  Incorrect

  Workspace roles don't include creating domains.

To create a domain you must be a Fabric admin; you can name domain admins at creation or later. Domain admins and domain contributors work within domains that already exist.

• AThe payroll manager can be named on the Admins tab of the Payroll subdomain's settings

  Incorrect

  Subdomains currently have general settings only, with no Admins tab.

• BSubdomains have no admins of their own; the parent domain's admins manage Payroll

  Correct

  A subdomain's domain admins are the domain admins of its parent domain.

• CThe payroll manager must first be a Fabric admin to administer a subdomain

  Incorrect

  Fabric admin isn't a subdomain role; subdomains inherit the parent's admins.

• DPayroll needs its own default domain definition before it can have admins

  Incorrect

  Default domain settings don't create admins, and subdomains don't have that tab.

Fabric admins or domain admins can create subdomains to refine how data is grouped. Subdomains don't have their own domain admins: the parent domain's admins administer them, and subdomain settings currently include only the general settings.

• AMedium

  Correct

  Starter pools use medium nodes, with default and maximum node limits set by the capacity SKU.

• BSmall

  Incorrect

  Small is a node size you can choose for a custom pool, not the starter pool's size.

• CLarge

  Incorrect

  Large is a custom pool option; the starter pool uses medium nodes.

• DThe size chosen by the capacity admin

  Incorrect

  Capacity admins don't pick a starter pool node size; it's fixed at medium.

Starter pools are pre-warmed, medium-node pools created with each workspace. Workspace admins can adjust autoscale and dynamic executor allocation limits up to the maximum for the capacity SKU; other node sizes need a custom pool.

• AThe starter pool always starts in a stopped state and must be started by hand

  Incorrect

  The starter pool's startup is instantaneous; it doesn't need a manual start.

• BThe DAG waited for free nodes in the workspace's Spark starter pool

  Incorrect

  Apache Airflow jobs run on their own Airflow runtime pools, not on Spark pools.

• CAutoscale was off, and the capacity paused the pool

  Incorrect

  Autoscale is a custom pool option and doesn't control whether the starter pool pauses.

• DThe starter pool shut down after 20 idle minutes and had to resume

  Correct

  The starter pool deprovisions after 20 minutes of inactivity, and resuming takes up to about five minutes.

The Airflow starter pool offers an instant runtime that's automatically deprovisioned after 20 minutes of inactivity; resuming can take up to about five minutes.