Configure Microsoft Fabric workspace settings

A notebook keeps running out of memory, a Finance analyst cannot find the sales lakehouse, and an Apache Airflow job stops running overnight. All three happen inside a workspace where you can already create notebooks, lakehouses, and pipelines, which is why they look like one product misbehaving. They are actually three different pages of workspace settings, and no single toggle fixes more than one of them. Routing a symptom to the right setting group, and knowing which admin role can change it, is what this objective measures.

Everything on this page is configured by a workspace admin, which means a user holding the Admin role in that workspace rather than a tenant-wide administrator. Changing the Apache Spark settings for a workspace requires exactly that role, as the workspace administration settings documentation^[1] states. Some of the four setting groups also depend on somebody else having unlocked them first, which the sections below call out where it matters.

The four setting groups

Setting group	Where the workspace admin opens it	The question it answers
Spark settings	Data Engineering/Science section of workspace settings	What compute runs notebooks and Spark job definitions?
Domain assignment	Workspace settings, or the Domains tab of the admin portal	Which business area do this workspace's items belong to?
OneLake outbound access protection	Network security settings for the workspace	May items in this workspace connect outward, and to what?
Apache Airflow runtime settings	Data Factory section of workspace settings	Which Airflow pool runs this workspace's DAGs?

A few terms recur throughout, so they are worth pinning down once. A lakehouse is the Fabric item that stores tables and files in OneLake, the single tenant-wide data lake underneath every Fabric workspace. A Spark job definition is a Fabric item that runs a Spark application non-interactively, the batch counterpart to a notebook. A DAG (directed acyclic graph) is the Python-defined workflow that Apache Airflow executes. Each of those is a thing the settings on this page act upon, not a setting itself.

Where this page stops

The sibling pages in this domain pick up where the settings end. Configure security and governance covers who may read an item once it exists, including workspace roles, item permissions, and sensitivity labels. Implement lifecycle management in Fabric covers version control and moving items between workspaces. Orchestrate processes covers scheduling and triggering the work that runs on the compute configured here. This page covers only the workspace-level settings themselves, and it treats permissions as something the settings do not change.

The takeaway to carry into the rest of the page: read the scenario for the noun it complains about. Compute and libraries point at Spark settings, discovery and classification point at domains, an outward connection points at outbound access protection, and a DAG runtime points at Airflow settings.

You attach a notebook to a workspace and select run. What happens in the next few seconds depends in part on which of three pool types the workspace default points at. Choose between them by how much you care about start latency against how much you need to control the hardware.

One naming trap first, because it bites later on this page: Apache Airflow jobs also have a "starter pool" and "custom pools", and they are a completely separate resource. A Spark pool never runs a DAG and an Airflow pool never runs a notebook. Everything in this section means the Spark kind.

Starter pool. Every workspace gets one automatically. It uses prewarmed Medium nodes, and a session with no extra library dependencies or custom Spark properties typically starts in 5 to 10 seconds^[2]. That speed is a Microsoft-managed, best-effort optimization rather than a guarantee: when prewarmed capacity is unavailable, Fabric falls back to on-demand capacity and the start takes 2 to 5 minutes. Starter pools support the Medium node size only, so selecting any other size also drops you onto on-demand startup. Tenant private links or managed virtual networks on the workspace disable starter pools entirely.

Custom Spark pool. A workspace admin creates one to set the node size, the autoscale bounds, and whether executors are dynamically allocated. Sessions start in about three minutes because Spark must acquire the nodes from Azure first. Creating the pool requires the workspace Admin role, and the capacity admin must have enabled Customized workspace pools in the Spark Compute section of capacity settings, a control that is enabled by default at the capacity level^[1].

Custom live pool. This is a custom Spark pool whose clusters stay hydrated during an active window you schedule, meaning they are already started with the environment library snapshot installed on them. Sessions inside that window start in approximately five seconds. It is the option for latency-sensitive scheduled work that cannot depend on best-effort starter capacity.

The figure below traces those three outcomes as two questions.

Node sizes and how many nodes you get

Size	vCore	Memory
Small	4	32 GB
Medium	8	64 GB
Large	16	128 GB
X-Large	32	256 GB
XX-Large	64	512 GB

X-Large and XX-Large are available on non-trial Fabric SKUs only. Capacity and pool limits both constrain node count: one capacity unit buys two Apache Spark vCores, and a 3x burst multiplier applies on top, so an F64 capacity yields 384 Spark vCores and therefore up to 96 Small nodes or 6 XX-Large nodes. A pool can also be a single node, by setting the minimum node count to one, in which case the driver and the executor share that node with their resources halved.

Autoscale and dynamic allocation are not the same knob

These two options sit next to each other in the pool creation dialog and are easy to conflate, so it is worth separating them at first sight. Autoscale changes how many nodes the pool holds, between a minimum and a maximum you set. Dynamic allocation changes how many executors one Spark application is granted within the nodes the pool already has, requesting more when tasks exceed the current executors and releasing them when the application goes idle. Neither one changes node size: size is a property of the pool that you can alter after creation, though the active session has to restart for the change to take effect. In Fabric the node-to-executor ratio is always one to one, which is why adding executors beyond the pool's nodes is not a thing you can ask for.

For custom live pools, billing follows cluster allocation, not just an active session. For a custom Spark pool that is not configured as a live pool, billing applies only while compute is actively used.

In short: starter pool unless you need specific hardware, custom Spark pool when you do, and custom live pool when a schedule makes the wait unacceptable.

Adding a Python package by resizing a pool does not work, because libraries and runtime versions are not pool properties. They belong to an Environment, a Fabric item that holds compute properties, a runtime version, and library package dependencies together.

A workspace admin selects an Environment as the workspace default on the Environment tab of the Spark settings, after which notebooks and Spark job definitions in that workspace inherit it. If the default Environment option is disabled instead, the admin picks a Fabric runtime version directly from a dropdown of the available versions. An inherited Environment and a bare runtime selection are the two alternatives here: you get one or the other, never both at once.

Sitting across both is the Customize compute configuration for items switch. When a workspace admin leaves it on, item authors can adjust session-level properties such as driver and executor cores and memory through an Environment. When it is turned off, the default pool and its compute configuration are used for every Environment in the workspace. The figure below shows that inheritance and what the switch collapses.

Which runtime you are on

Component	Runtime 1.3	Runtime 2.0
Release stage	GA	GA
Apache Spark	3.5.5	4.1
Java	11	21
Scala	2.12.17	2.13.16
Python	3.11	3.13
Delta Lake	3.2	4.2

New workspaces currently default to Runtime 1.3^[3], and the runtime version is selected either at the workspace level under Workspace settings, Data Engineering/Science, Spark settings, Environment tab, or on an individual Environment item.

What a runtime change does to a running workspace

Changing the workspace runtime does not disturb work already in flight. A notebook with an existing Spark session continues on the old runtime, and the newly selected version applies from the next session or job onward. Two migration behaviours are worth remembering because they fail in different ways. Spark settings are all migrated, but any setting the system finds incompatible with the new runtime is skipped with a warning rather than applied. Libraries are also migrated, including custom ones, and they generally keep working when the Python and R versions are unchanged; JAR files have a significant chance of breaking because Scala, Java, Spark, and operating system versions all move between runtimes. If the new runtime already contains a library you had defined yourself, the library management system tries to build a compatible dependency and the build fails on a conflict, naming the offending libraries in the error log.

Library publishing mode changes your start time

The Environment's publishing mode decides how much time libraries add to session startup. Quick mode installs libraries at session start, adding 30 seconds to 5 minutes depending on how many and how large they are. Full mode deploys an environment snapshot at session start, typically adding 1 to 3 minutes. Full mode on a custom live pool preinstalls that snapshot on the hydrated cluster, which is why sessions there still start in roughly five seconds. Inline installs such as %pip install and the notebook Resources folder are per-session and always run during the active session regardless of publishing mode.

Put together: pool settings answer how much hardware, Environment settings answer which software, and only the Environment travels with your code.

One notebook has been running for six hours, a second sits idle holding a live session, and a third cannot get admitted at all. Those three symptoms map to the three independent guardrails on the Jobs tab, and a scenario usually names exactly one of them: job admission, session timeout, and maximum job lifetime.

Job admission. Every workspace is enabled with Optimistic Job Admission by default, which lets Fabric admit jobs without reserving their maximum core allocation up front. Enabling Reserve maximum cores for active Spark jobs turns that optimistic approach off and reserves the maximum cores for active jobs instead, as described in the workspace administration settings^[1]. It is a throughput-versus-certainty trade, not a per-job limit.

Spark session timeout. This sets the expiry for notebook interactive sessions, and the default expiry is 20 minutes. A Spark pool is deallocated two minutes after the session it was serving expires.

Set maximum job lifetime. This is the guardrail against a runaway job holding capacity indefinitely. Turn it on, give a value and a time unit, and Fabric cancels any eligible job that runs past it.

Those last two both end a Spark session, so it is worth stating plainly where the line falls: session timeout expires an idle interactive session after a period with no work, while maximum job lifetime cancels a running job that has been working too long. One reclaims an abandoned notebook, the other stops a job that is busy doing the wrong thing.

What the lifetime limit can and cannot cancel

The maximum job lifetime applies only to user-submitted jobs, meaning jobs a user explicitly starts that run with the user's identity. Those include interactive and scheduled notebook runs, notebook runs orchestrated through a pipeline, Spark job definition runs submitted directly or on a schedule or through a pipeline, and Livy batch and interactive sessions including high concurrency sessions, among others. Livy is the service the Spark head node runs for submitting sessions and batches^[2], so a Livy session is simply a Spark session opened outside the notebook interface.

System-managed jobs are not affected and continue to completion. Those include lakehouse table maintenance operations such as optimize and vacuum, materialized lake view refreshes, and platform operations such as security and policy enforcement, among other Fabric-triggered work. The distinction exists so that a governance limit on user workloads never interrupts the background maintenance that keeps the data healthy.

Set the limit above your longest legitimate job. Fabric cancels at the boundary without asking, and a nightly load that occasionally runs long will simply stop.

High concurrency mode lets several notebooks share one running Spark session instead of each starting its own, but only when three conditions all hold. Sessions must be within a single-user boundary, use the same default lakehouse configuration, and use the same Spark compute settings^[4]. If any one of those differs, Fabric starts a separate session.

The single-user boundary is the part readers most often misread, so it is worth saying directly at first mention: high concurrency never shares a session between two different users. It is a way for one person, or one identity running a set of pipeline activities, to stop paying the session startup cost repeatedly.

Underneath, one Spark application hosts multiple workloads by giving each its own REPL (read-eval-print loop) core. Each REPL core isolates execution state, so a local variable in one notebook cannot overwrite a variable in another. As workloads join, executors are allocated across those REPL cores with FAIR scheduling to reduce the risk of one workload starving the others.

Billing follows the initiator. Only the notebook or pipeline activity that starts the shared Spark application is billed, and the sessions that join it are not billed separately. Capacity Metrics reports the usage against that initiating item, which is why a single notebook can appear to consume far more than its own work.

Raising the notebook density per session

By default a high concurrency session supports up to five notebooks. The limit is not a workspace setting: you change it in the Environment that the notebooks or pipeline-triggered notebooks use, under Spark Properties.

Spark property that raises the session sharing limit

# Environment item > Spark Properties, then Save and Publish
# Accepted range is 2 through 50; unset means the default of 5
spark.highConcurrency.max = 20

spark.highConcurrency.max is the property named in the listing above. Every notebook and pipeline activity that uses that Environment inherits the new limit automatically once the Environment is published. Raising it packs more notebooks into one session, which cuts session fragmentation and speeds up session acquisition at peak; keeping it at five or lower is the right call for workloads with strict isolation requirements.

So: high concurrency is a cost and latency optimization inside one user's boundary, and the Environment, not the workspace, is where its density is tuned.

Assigning a workspace to a domain changes metadata and nothing else. That single sentence resolves most exam questions on this topic.

A domain in Fabric is a way of logically grouping all the data in an organization that is relevant to one area or field, most commonly a business department. It has nothing to do with a DNS domain or a Microsoft Entra domain, which share the word and mean something entirely different. You group data by associating workspaces with domains: when a workspace is associated with a domain, all the items in that workspace are also associated with it^[5] and receive a domain attribute as part of their metadata. The practical payoff is discovery. Users can filter content by domain in the OneLake catalog to find what is relevant to them, and a domain image themes the catalog while that filter is active.

What it does not do is grant anything. Domain assignment does not affect item visibility or accessibility for tenant users; discovery, visibility, and access depend on workspace role and item permissions, which the security and governance page covers. In the same spirit, every user in a tenant can see every domain defined in the tenant regardless of their domain roles, so seeing "Finance" in the catalog filter says nothing about being able to open a Finance report.

Subdomains

A subdomain refines the grouping one level further, and a Fabric admin or a domain admin can create one under a domain. Subdomains do not have their own domain admins: the domain admins of the parent domain administer them. Subdomains also currently expose general settings only, so the delegated settings described in the next section are a parent-domain concern.

Default domains

Defining a domain as the default domain for named users or security groups triggers a scan of the organization's workspaces, and the result depends on what it finds. A workspace whose admin is one of those users and which already has a domain assignment keeps that assignment: the default domain does not override it. A workspace that is unassigned is assigned to the default domain. From then on, any new workspace created by one of those users is assigned to the default domain as well, and the specified users generally become domain contributors of the workspaces assigned this way. The figure below separates those three cases.

Assignment from the admin portal behaves differently from the default-domain scan. A Fabric admin or domain admin assigning workspaces by name, by workspace admin, or by capacity sees a warning when a workspace already belongs to another domain, and can override it only when the Allow tenant and domain admins to override workspace assignments (preview) tenant setting is enabled. Assigning by workspace admin or by capacity affects existing workspaces only and excludes My workspaces.

The one line to remember: a default domain fills gaps, an admin assignment can overwrite, and neither one hands out access.

A workspace admin asks to move their workspace into the Finance domain and is told no. Which of three domain roles they hold, and whether they also hold the Admin role in that workspace, decides the answer, so the roles are worth separating carefully.

A Fabric admin can create and edit domains, specify domain admins and domain contributors, and associate workspaces with domains. Fabric admins see every domain in the tenant on the Domains tab of the admin portal and can edit and delete them.

A domain admin is typically the business owner of the area. Domain admins reach the Domains tab too, but see and edit only the domains they administer. They can update the domain description, define and update domain contributors, associate workspaces with the domain, set the domain image, and override tenant settings that the tenant admin has delegated to the domain level. They cannot delete the domain, change its name, or add and remove other domain admins.

A domain contributor is a workspace admin whom a domain or Fabric admin has authorized to assign the workspaces they administer. Two constraints define the role. A domain contributor performs the assignment in the settings of the workspace itself and has no access to the Domains tab of the admin portal. And to assign a workspace to a domain at all, a domain contributor must be a workspace admin^[5], holding the Admin role in that workspace. Granting somebody the domain contributor role alone does not let them classify workspaces they do not administer.

What "delegated" actually bounds

Federated governance in Fabric means some tenant-level settings can be pushed down for domain-specific configuration, and a domain admin can override only the settings that were delegated. Everything else stays a tenant decision. Two delegated settings appear in the domain settings pane today:

• A domain-level default sensitivity label, applied by default to items in workspaces assigned to the domain, when the feature is enabled for the organization.
• Certification settings, which let the domain enable or disable certification for its items, name certifiers who are experts in the domain, and supply a documentation URL. Overriding these requires selecting the Override tenant admin selection checkbox in the certification section.

Sensitivity labels and endorsement are taught in depth on the security and governance page; here they matter only as the two things a domain admin is allowed to set differently from the tenant.

Read every domain-role question twice: the answer is almost always the intersection of a domain role and a workspace role, not either one alone.

Turn on workspace outbound access protection and everything outbound stops. That is the design: when the feature is enabled for a workspace, all outbound connections from the workspace are blocked by default^[6], and the workspace admin then creates exceptions for the destinations that are actually needed. It is a deny-first control over data leaving the workspace, and it is separate from private links, which protect traffic coming in.

Two exception mechanisms exist, and which one applies is decided by the workload rather than by preference.

• Managed private endpoints are network connections that link workspace items to supported external data sources over private virtual networks, and they can also target another workspace in the same tenant when the Private Link service is enabled there. They are the mechanism for Data Engineering items (lakehouses, notebooks, Spark job definitions, and Environments) and for OneLake shortcuts.
• Data connection rules are policies that allow workspace items to reach external services through specific cloud or gateway connections, with the admin explicitly allowing or blocking connectors. They are the mechanism for Data Factory items, mirrored databases, Real-Time Intelligence items, and semantic models, among others.

A workspace admin creates a managed private endpoint from workspace settings by giving the resource ID of the data source, identifying the target subresource, and providing a justification for the request; Fabric creates and manages the endpoint from there. Managed private endpoints are supported for Fabric trial capacity and all Fabric F SKU capacities^[7].

Chained shortcuts approve one hop at a time

When a shortcut links to another shortcut, outbound restrictions are evaluated sequentially at each shortcut^[8]. If a shortcut in Workspace A points to a shortcut in Workspace B that points to data in Workspace C, you must approve the A-to-B connection and the B-to-C connection for the chain to resolve. Approving A to C is not required and does not stand in for the two hops that actually happen. The figure below traces exactly that chain.

Limitations worth knowing

These are the ones that turn up in scenarios, among others:

• OneLake shortcuts do not yet support connections to Azure Data Lake Storage Gen2 (ADLS Gen2) storage accounts or Azure Blob Storage accounts using managed private endpoints. Allow those targets with a data connection rule for the matching connector instead, and match the endpoint form to the connector: the .dfs endpoint for the Azure Data Lake Storage connector, the .blob endpoint for the Azure Blob Storage connector.
• Outbound access protection supports workspaces on Fabric SKUs only, and the Microsoft.Network feature must be re-registered on the subscription.
• A workspace containing unsupported artifacts cannot have the feature enabled until those artifacts are removed, and once enabled, unsupported artifacts cannot be added.
• Querying warehouse file paths from notebooks using the dbo schema is not supported in a protected workspace; query the warehouse with the T-SQL option instead.
• The feature is not currently compatible with OneLake Diagnostics or with Fabric external data sharing, and cross-tenant allow lists are not supported.

One direction catches people out. Copying data out of a protected workspace to an external Azure Storage account is an inbound call to the workspace, because the destination account makes the outbound call to the source. Outbound access protection therefore does not block it, and inbound protection is what you need for that case.

The rule to carry away: outbound access protection controls where a workspace's items may reach, per hop, and never who may reach into them.

Your team's DAG runs at six every morning and nobody touches Apache Airflow overnight. Whether it fires on time depends on which pool the workspace points at, because the Apache Airflow starter pool and custom pool differ mainly in what happens when nobody is using them. A starter pool deprovisions; a custom pool waits.

An Apache Airflow job is the Fabric Data Factory item that runs Python-defined DAGs as a managed service, and it is the successor to Azure Data Factory's Workflow Orchestration Manager. Its runtime settings live in workspace settings under the Data Factory section, as Apache Airflow Runtime Settings. The same pattern as Spark applies here: if the setting for customizing compute configurations for items is disabled, the starter pool is used for all environments in the workspace^[9]. One word to keep straight in that sentence: an Airflow environment here means one running Airflow instance, not the Fabric Environment item that carries Spark libraries and runtimes.

Property	Starter pool (default)	Custom pool
Size	Compute node size Large	Configurable compute node size, extra nodes, autoscale
Startup latency	Instantaneous	Starts in the stopped stage
Resume latency	Up to 5 minutes	Up to 5 minutes
Uptime behaviour	Shuts down after 20 minutes of inactivity on the Airflow environment	Always on until manually paused
Suggested environment	Developer	Production

Creating a custom Airflow pool means choosing four things: a name, a compute node size of Large for complex or production DAGs or Small for simpler ones, whether to enable autoscale so the pool scales nodes up and down as needed, and how many extra nodes to add. Extra nodes are what let the pool run more DAGs concurrently, and each node provides the capacity to run three more Apache Airflow workers.

The boundary that no setting moves

Private networks and virtual networks are not currently supported with Fabric Apache Airflow jobs^[10]. No pool size, node count, or autoscale choice changes that, so a requirement for network isolation is a requirement to orchestrate somewhere else for now. Two related version facts sit on the same page: the supported Apache Airflow version is 2.10.5 on Python 3.12, and changing the Apache Airflow version inside an existing Apache Airflow job is not supported, so a different version means creating a new job.

Match the pool to the lifecycle: development work tolerates a 20-minute idle shutdown and a five-minute resume, a production DAG that must fire on schedule does not.

Questions on this objective tend to hand you a symptom and expect you to name the setting. The distractors are usually settings that sound adjacent but belong to a different setting group.

Pattern: a scheduled notebook must start fast every time. The right answer is a custom live pool, for the active-window reason given in Spark pools above. The starter pool distractor fails on the word every, and a plain custom Spark pool fails on its roughly three-minute node acquisition.

Pattern: every notebook in the workspace needs the same Python packages. The answer is a default Environment for the workspace. Increasing starter pool nodes, enabling autoscale, or raising executor counts are all compute answers to a software question.

Pattern: a user wants to share one Spark session with a colleague. There is no setting for this. High concurrency stays inside a single-user boundary, as High concurrency session sharing sets out, so a second user always gets a second session.

Pattern: a job has run for six hours and is blocking the workspace. The answer is the maximum job lifetime. Spark session timeout is the near-miss distractor: it expires idle interactive sessions and does nothing to a job that is actively running. Watch for stems that add "and Fabric's own table maintenance must still finish", which points at the control that exempts system-managed jobs.

Pattern: Finance users should see only Finance content in the OneLake catalog. Assign the Finance workspaces to a Finance domain. If the stem instead says Finance users should be able to open the reports, the answer is a permission mechanism and the domain option is the trap, because domain assignment never grants access.

Pattern: a workspace admin needs to classify their own workspace. They need the domain contributor role on top of the workspace Admin role, per the intersection rule in What each domain role can do. Making them a domain admin also works but over-grants, and it is the wrong pick when the stem says least privilege. Making them a Fabric admin is always over-granting.

Pattern: a shortcut chain stopped resolving after outbound protection was turned on. Approve each consecutive hop. A stem that describes an approval from the first workspace straight to the final workspace is describing the wrong fix.

Pattern: a shortcut to an ADLS Gen2 account must work in a protected workspace. Use a data connection rule for the matching connector. Creating a managed private endpoint is the trap, for the shortcut limitation listed in OneLake outbound access protection.

Pattern: a production DAG must never deprovision. Use a custom Airflow pool, which is always on until manually paused. The starter pool shuts down when idle, and if the stem also demands a virtual network, no Airflow answer is correct.

The habit that pays off here is reading the stem for the setting group first and the specific setting second. Most wrong answers on this objective are correct settings from the wrong group.