Configure Microsoft Fabric Workspace Settings: Spark, Domains, OneLake, Airflow

A Fabric workspace is the container where a team creates and collaborates on items — Lakehouses, Warehouses, notebooks, data pipelines, Eventhouses, semantic models — and every workspace gets its compute from a capacity, the pool of purchased Fabric compute (an F SKU or a trial) that one or more workspaces share. Settings therefore live at three levels, and DP-700 loves to test which level owns which control.

The tenant admin works in the Fabric admin portal: enabling or disabling features tenant-wide (for example, whether users can create Apache Airflow jobs), creating domains, and setting governance policies such as workspace retention. The capacity admin manages the capacity a workspace is assigned to: which workspaces can use it, capacity-level Spark pools, and whether workspace admins are allowed to create their own customized pools. The workspace admin configures everything inside Workspace settings: license mode (which capacity the workspace runs on), the default Spark pool and environment, high concurrency, domain assignment (where permitted), Git integration, and Airflow pool configuration.

The pattern to remember: tenant admins decide whether a feature exists, capacity admins decide how much compute it may consume, and workspace admins decide how their team uses it. If an exam scenario says a workspace admin cannot create a custom Spark pool, the fix is at the capacity level — the capacity admin must allow customized workspace pools. If nobody in the tenant can create an Airflow job, the fix is a tenant setting. Answering these questions is mostly a matter of routing the symptom to the right admin.

Spark workspace settings decide which Spark pool backs the notebooks and Spark job definitions in the workspace, and the core choice is between the pre-warmed starter pool and a custom pool you shape yourself.

A starter pool is a Fabric-managed pool of pre-provisioned, always-ready medium nodes. Because the nodes are already warm, a session starts in seconds — ideal for interactive, exploratory notebook work. The trade-off is limited control: you take the node size and family Fabric provides. A custom pool is one you define: you choose the node family (memory optimized), node size (from small through extra-large tiers), enable autoscale to set minimum and maximum node counts, and enable dynamic executor allocation so Spark requests executors based on workload. Custom pools give predictable sizing for heavy jobs, but sessions cold-start, so expect minutes rather than seconds before code runs.

Exam trigger words: fastest session start points to starter pools; specific node size, memory-heavy job, or control costs by capping nodes points to a custom pool with autoscale limits. And remember the dependency — workspace-level custom pools only exist if the capacity admin has enabled customized workspace pools.

An environment is a Fabric item that packages everything a Spark session needs beyond raw compute: the Spark runtime version, public libraries (for example from PyPI), custom libraries you upload (such as .whl, .jar, or .tar.gz files), Spark properties, and attached resources. Instead of running pip install at the top of every notebook — which slows every session and drifts between users — you install libraries once in an environment and attach it where needed.

In Spark workspace settings, a workspace admin selects the workspace default environment (and with it the default runtime version). Every notebook and Spark job definition in the workspace then inherits that environment unless the item explicitly attaches a different one. This is the standard pattern for team consistency: one curated environment with the approved library set, made the workspace default, with specialized environments attached per notebook only where a workload genuinely needs different packages or Spark properties.

Two behaviors are worth internalizing for the exam. First, environments bind a specific runtime version — if a scenario requires a newer Spark runtime, you change it on the environment (or the workspace default), not inside the notebook. Second, environment changes must be published before sessions pick them up, and sessions started under the old definition keep it until they restart. When a question describes a team whose notebooks fail because a library is missing on some sessions but not others, the clean answer is an environment attached as the workspace default — not inline installs scattered through notebook cells.

High concurrency mode lets multiple notebooks share a single Spark session instead of each notebook spinning up its own, cutting session start waits and reducing capacity consumption. Without it, every notebook you open starts a dedicated session — expensive when an engineer is hopping between five notebooks, and slow when each one has to acquire compute.

A workspace admin enables high concurrency in the Spark workspace settings. Once on, a user can start a high concurrency session from one notebook and attach further notebooks to that same session. Sharing has sensible boundaries: notebooks share a session only for the same user and only when they are compatible — matching environment and Spark configuration — so one user's packages and session state never bleed into another user's work. Within the shared session, each notebook still gets isolation for its variables through separate contexts.

High concurrency also extends to pipeline notebook activities: a data pipeline that runs several notebooks can execute them in one shared session rather than paying session startup for each activity. For an orchestrated nightly load that chains half a dozen small notebooks, this is often the single biggest wall-clock win available from configuration alone.

On the exam, the trigger is a scenario about reducing session startup time or lowering capacity usage when running many notebooks — especially many small notebooks in one pipeline. The answer is high concurrency mode, and the distractors are usually bigger nodes or more executors, which raise cost without addressing startup overhead.

A domain is a tenant-level grouping that collects related workspaces under a business area — Finance, Sales, Supply Chain — so a large organization can manage and discover data along business lines rather than as one flat list of workspaces. Domains are Fabric's building block for a data-mesh style operating model, and each domain can carry its own image and description so its data products are recognizable in the OneLake catalog.

The role split matters for DP-700. Only a Fabric (tenant) admin can create domains and appoint domain admins. Domain admins manage their own domain: its settings, its subdomains (domains can nest one level down for finer grouping), and who its domain contributors are. Contributors — and workspace admins, when the domain is configured to allow it — assign workspaces into the domain. A workspace belongs to at most one domain (or subdomain), and the assignment is visible in the workspace settings.

Two more capabilities show up in questions. A tenant admin can define a default domain rule so that workspaces created by particular users or groups are automatically assigned to the right domain — useful when hundreds of teams create workspaces and manual assignment will not scale. And certain tenant-level settings can be delegated to domain admins, letting, say, the Finance domain set its own certification policy without opening tenant settings to them.

Trigger words: group workspaces by business unit, federated governance, or data mesh all point at domains; who can create a domain is always the tenant admin, never the workspace admin.

OneLake is the single, tenant-wide data lake behind every Fabric workspace: there is exactly one OneLake per tenant, each workspace is a top-level container inside it, and every item in the workspace (Lakehouse, Warehouse, Eventhouse) stores its data under that container in open Delta Parquet format, addressable through the OneLake endpoint with a path of the form workspace/item/Tables or workspace/item/Files. Configuring OneLake at the workspace level is therefore mostly about how that container behaves, not about provisioning storage — there is nothing to provision.

The setting DP-700 probes most is retention. Deleting a workspace does not immediately destroy its OneLake data: the workspace enters a retention period during which an admin can restore it, and only when retention lapses is the data permanently removed. Tenant admins configure how long deleted workspaces are retained. The exam angle: if a scenario says a workspace was deleted last week and the team needs its Lakehouse back, the answer is workspace retention and admin restore — not a backup product, because the retention window is the recovery mechanism.

Workspace settings also govern how the workspace's OneLake data is reached and cached. Shortcuts let items reference data in other workspaces or external cloud storage without copying it, and enabling caching for shortcuts at the workspace level keeps recently read external data local — reducing latency and egress charges for shortcuts that cross cloud providers. Finally, remember the naming consequence: because the workspace name is part of every OneLake path, treat it as a stable identifier that downstream consumers and shortcut paths depend on.

An Apache Airflow job is Fabric's managed Airflow offering: a workspace item that runs Airflow DAGs — Python-defined, code-first orchestration — without you standing up or patching any Airflow infrastructure. Teams that already think in DAGs, or that must orchestrate across systems in ways Fabric data pipelines cannot express, get the full Airflow programming model inside Fabric, billed against the workspace's capacity.

Two configuration layers matter. First, the feature is tenant-gated: a tenant admin must enable users to create and use Apache Airflow jobs before the item type appears at all. Second, the workspace-level Airflow settings shape the runtime: pool choice and sizing. As with Spark, Airflow offers a starter pool that starts on demand and deallocates after idle time — economical for intermittent or development use — versus a custom pool kept running for production schedules that cannot tolerate a pool warming up before a DAG triggers. You also configure compute size, extra nodes for parallel task capacity, and autoscale behavior.

Inside the item, you author or upload DAG files and supporting Python files, declare additional packages as requirements so the managed environment installs them, and can sync DAG files from a Git repository so orchestration code is version controlled like everything else. From a DAG, operators call Fabric items — for example triggering a data pipeline or notebook — so Airflow becomes the outer scheduler around Fabric workloads.

Exam triggers: code-first orchestration, existing Airflow DAGs to migrate, or Python-based scheduling point to an Apache Airflow job; the Airflow option is missing points to the tenant setting; production DAGs must start instantly points to a custom (always-on) pool over the starter pool.

Put the pieces together with a scenario shaped like a DP-700 question set. A retail company creates a workspace called sales-analytics for a new data engineering team. Requirements: notebooks must start fast during development; the nightly transformation job needs memory-optimized nodes capped at a fixed maximum to control spend; every notebook needs the same forecasting library; the workspace must be discoverable under the company's Sales business area; and orchestration will reuse Airflow DAGs migrated from an existing deployment.

The configuration falls straight out of this lesson. Interactive speed → keep the starter pool as the default for development notebooks. The sized nightly job → ask the capacity admin to allow customized workspace pools, then create a custom pool on the memory-optimized family with autoscale minimum and maximum set to the agreed cap, and attach it to the production Spark job. Shared library → build an environment containing the forecasting package, publish it, and set it as the workspace default so every notebook inherits it. Business-area discovery → a domain contributor (or the workspace admin, if the domain allows it) assigns the workspace to the Sales domain; if no Sales domain exists, only the tenant admin can create it. Migrated DAGs → confirm the tenant setting for Airflow jobs is enabled, create an Apache Airflow job, sync the DAG files from Git, and choose a custom pool if production schedules need instant starts.

Notice that every requirement resolved to a setting at a specific level. That mapping — requirement, to setting, to the admin who owns it — is precisely the skill this objective examines.