Implement and manage an analytics solution practice questions

Custom Spark pools have two independent scaling controls: autoscale (how many nodes the pool holds, between a min and max) and dynamic executor allocation (how many executors a single Spark application uses, within bounds).

Autoscale works at the pool level, adding nodes up to the configured maximum and retiring them after jobs finish. Dynamic allocation works at the application level, sizing a job's executor count to the data volume. The swapped statement is the common confusion. Node size, family, capacity units and driver memory are not run-time settings of either feature.

1. Separate the two scopes: the pool (nodes) and the application (executors).
2. Map autoscale to the pool's node count between min and max.
3. Map dynamic allocation to a job's executor count.
4. Reject options that change node size, family or capacity, which are fixed by configuration or the SKU.

Exam tip: Autoscale = nodes in the pool; dynamic allocation = executors in a job.

An environment is the Fabric item that bundles a Spark runtime version, public and custom libraries and Spark properties for notebooks and Spark job definitions to attach.

The requirement is a single attachable item holding libraries and Spark properties: that is an environment. Pools in Fabric carry compute settings only (unlike Synapse, where pools held libraries). A Spark job definition is a runnable job, and a lakehouse folder only stores files.

1. List what must be shared: packages, a custom wheel, Spark properties.
2. Note it must be one attachable item.
3. Recall where Fabric keeps libraries and Spark properties: environments.
4. Reject compute-only (pool), runnable (job definition) and storage-only (lakehouse) items.

Exam tip: Libraries + Spark properties + runtime in one attachable item = a Fabric environment.

The workspace default environment, chosen in the workspace Spark settings by a workspace admin, is inherited by every notebook and Spark job definition that doesn't attach a different environment.

The failure is a forgotten manual attach, so the fix has to be inheritance. Making the environment the workspace default gives every new notebook the package with no author action. The %run notebook and resources folder both still need a per-notebook step, and high concurrency shares sessions rather than providing libraries.

1. Identify the root cause: a per-notebook step that authors forget.
2. Look for a setting that new notebooks inherit automatically.
3. Recall that the workspace default environment is inherited unless overridden.
4. Reject options that still need an action in each notebook.

Exam tip: To give every notebook the same libraries without anyone remembering, set the environment as the workspace default.

High concurrency mode (on by default in workspace Spark settings) lets one user attach several compatible notebooks to a single running Spark session.

Both problems come from one session per notebook. Sharing one high concurrency session removes the per-notebook startup and the duplicate idle sessions together. A shorter timeout fixes only the idle sessions; more nodes or fewer executors don't change how many sessions start.

1. Find the shared cause: every notebook starts its own session.
2. Look for an option that reduces the number of sessions.
3. Recall that high concurrency attaches compatible notebooks to one session.
4. Check each distractor against both requirements (wait time and idle capacity).

Exam tip: Many small notebooks from one user = one high concurrency session, not more compute.

Custom Spark pools in a workspace require the capacity-level 'Customized workspace pools' option (on by default). Separately, the workspace admin's 'Customize compute configuration for items' toggle decides whether items can adjust session compute.

The workspace admin already has full rights, so the block must come from the level above: the capacity. When the capacity admin turns off customized workspace pools, workspace admins can't create custom pools. The item-level compute toggle is the near-twin, but it governs session overrides, not pool creation. Git and domains don't touch Spark compute.

1. Note that the workspace admin has full rights, so the limit is set above the workspace.
2. Recall that Spark compute guardrails sit at the capacity level.
3. Identify the capacity setting that allows workspace custom pools.
4. Distinguish it from the workspace toggle for item-level compute.

Exam tip: A workspace admin who can't create a custom pool needs the capacity admin to allow customized workspace pools.

Fabric domains are the tenant-level grouping of workspaces by business area that supports a data mesh model and domain filtering in the OneLake catalog.

The requirement is a business-area grouping across many workspaces that consumers can filter by. That is exactly what domains provide. Capacities group compute, folders group items within one workspace, and labels classify sensitivity.

1. Identify the unit to group: whole workspaces, by business area.
2. Note the consumer requirement: filter the OneLake catalog.
3. Recall that domains associate workspaces and their items with a business area.
4. Reject options that group by compute, location inside a workspace or sensitivity.

Exam tip: Group workspaces by business area for discovery = Fabric domains.