2.3 Scenario Practice for Implement and manage an analytics solution

Reading a Fabric Scenario

Every scenario question hides three cues: the actor (a role or persona), the object (workspace, item, capacity, domain), and the environment or goal (governance, security, ALM, performance). Resolve them in order, then pick the control that lives at the matching layer.

Consider governance. A central data office wants Sales and Finance to manage their own assets without a tenant admin in the loop. The control is domains: a Fabric admin creates the domains, assigns domain admins, and delegates selected tenant settings down. Discovery then flows through the OneLake catalog, where users filter by domain and see endorsement and sensitivity signals.

Endorsement has distinct tiers you must not blur:

If a stem says "without waiting for a formal reviewer," the answer is Promoted. If it says "officially vetted by the data office," the answer is Certified.

Protection and Layered Access in Practice

Sensitivity labels in Fabric come from Microsoft Purview Information Protection. They can be applied to all Fabric items, they travel with exported data (for example into an Excel or PDF export), and for supported autogenerated child items (such as a lakehouse's default semantic model or SQL analytics endpoint) the label is inherited from the parent. You do not need Purview deployed to use Fabric's native governance (domains, endorsements, the OneLake catalog Govern tab), but Purview adds enterprise classification, DLP, and cross-platform discovery.

Now a layered-access scenario: a Viewer can see a lakehouse and query its tables through the SQL analytics endpoint, but reports she cannot read the underlying files. With OneLake security enforced, the workspace role is not enough for raw file access — she must be added to a OneLake security (data-access) role that grants the folder, or the relevant default-reader behavior must still be in place. The fix is a data-access role, not a higher workspace role, because least privilege is the goal.

• Cue "can run SQL but not read files" -> OneLake security role needed.
• Cue "should not modify anything" -> Viewer workspace role.
• Cue "share one lakehouse with an outsider" -> item-level share, not a workspace role.

Configuring a Reproducible Environment

A recurring scenario: notebooks behave differently across Dev, Test, and Prod because of mismatched libraries or Spark settings. The control is the Fabric environment item. An environment lets you pin the Spark runtime version, attach custom and public libraries (PyPI, conda, or uploaded .whl/.jar), define Spark pool sizing, and set Spark properties. Attaching the same environment to all notebooks makes runs reproducible, and the environment definition is itself committed through Git and promoted by deployment pipelines, so each stage is consistent.

Workspace-level Spark settings (default pool, high-concurrency mode, autotune) can also be tuned, but the environment item is the portable, version-controlled answer when the stem stresses reproducibility across stages.

Finally, watch for default vs custom configuration distractors: enabling a workspace setting fixes one workspace, while an environment item fixes every notebook attached to it across every stage. When the scenario emphasizes consistency at scale, prefer the environment item.

Governing with the OneLake Catalog and Purview

The OneLake catalog is the in-Fabric place to explore, govern, and secure data. Its Explore tab lets users find items filtered by domain, endorsement, and sensitivity. Its Govern tab (for admins and data owners) surfaces governance insights — coverage of sensitivity labels, percentage of unlabeled items, endorsement counts, and recommended actions — so you can raise the governance posture without leaving Fabric. A frequent distinction the exam tests: you do not need Microsoft Purview to use these native governance features. Domains, endorsements, ownership metadata, and the Govern tab work inside Fabric on their own.

When the organization does connect Microsoft Purview, it adds enterprise-wide capabilities on top: cross-platform data discovery and lineage, advanced classification, broader data loss prevention (DLP) policies, and deeper auditing and compliance. So the rule for stems is: native catalog and labels for in-Fabric governance; Purview when the requirement is cross-platform, enterprise classification, or DLP. Sensitivity labels themselves are authored in Purview Information Protection but applied and inherited inside Fabric.

A worked governance scenario

Suppose Finance must own its assets, certify a golden revenue dataset, and ensure confidential items are labeled. The complete answer chains several controls: a Fabric admin creates a Finance domain and assigns a domain admin; the domain admin adds the Finance workspaces; a designated authorized reviewer applies the Certified endorsement to the golden dataset; and a Confidential sensitivity label (from Purview) is applied so it inherits to the dataset's child items. No single toggle solves this — the exam rewards selecting the action at each correct layer in sequence.

A common wrong answer collapses the chain into one step, such as "apply a sensitivity label" alone, which classifies the data but does nothing for ownership, certification, or who can administer the Finance assets. Read these multi-part stems carefully and confirm the chosen option covers the specific requirement named, not merely an adjacent one.