Task 1.2: Implement and manage a data analytics environment

• AShare SalesDW with the managers and select the Read all data using SQL permission

  Incorrect

  The visuals would work, but ReadData lets the managers connect to the warehouse and query every table and view.

• BGive the managers Build permission on the semantic model as well

  Incorrect

  Build lets them create content on the model; with SSO, Direct Lake still checks their own read access to the warehouse.

• CAdd the managers to the workspace with the Viewer role

  Incorrect

  Viewers get Read and ReadData on the warehouse by default, so they could query it directly.

• DBind the model to a fixed-identity cloud connection with SSO turned off

  Correct

  With a fixed identity and SSO off, Direct Lake reads data with that identity's permissions, so users need access to the model, not to the warehouse.

With the default single sign-on (Microsoft Entra ID) connection, Direct Lake checks that the user who runs the query can read the source tables, so report users would need ReadData or table permissions on the warehouse. When you bind the model to an explicit cloud connection with a fixed identity and leave SSO disabled, the fixed identity's permissions decide what Direct Lake can read for queries and refreshes, and users who aren't granted anything on the warehouse can't query it directly.

• ALabel SalesLH Confidential and let downstream inheritance label the model and reports

  Correct

  Downstream inheritance runs from a Fabric item to the Power BI items that depend on it, so labeling the lakehouse covers the model and reports.

• BWait for the next pipeline run, which copies the source label to SalesLH

  Incorrect

  Inheritance from data sources currently applies only to Power BI semantic models, so a lakehouse loaded by a pipeline doesn't take the source's label.

• CRefresh the semantic model so that it inherits Confidential from the Azure SQL database

  Incorrect

  The model reads SalesLH, not the database, so it has no labeled data source to inherit from.

• DApply Confidential to the semantic model and let inheritance carry it back to SalesLH

  Incorrect

  Labels propagate downstream only, and inheritance from a Power BI item to a Fabric item isn't supported.

In Fabric, inheritance from data sources is currently supported for Power BI semantic models only: a model that connects to a labeled source picks up its label. Downstream inheritance then passes a label from an item to the items that depend on it, from Fabric item to Fabric item, from Fabric item to Power BI item, and from Power BI item to Power BI item, but not from a Power BI item to a Fabric item. A label on the lakehouse therefore reaches the Direct Lake model and its reports.

• AThe capacity admin role on the F64 capacity

  Incorrect

  Capacity admins can assign workspaces, but they can also change the capacity's settings, which she must not be able to do.

• BThe Fabric administrator role for the tenant

  Incorrect

  A tenant-wide admin role goes far beyond assigning one workspace and includes every capacity and tenant setting.

• CThe contributor role on the F64 capacity

  Correct

  Capacity contributors can assign workspaces to the capacity but can't modify its settings or delete it.

• DAn override of the capacity's delegated tenant settings for her

  Incorrect

  Delegated tenant settings let capacity admins change feature settings for the capacity's users; they don't grant the right to assign workspaces.

To assign a workspace to a Fabric capacity, you need the Admin role on the workspace and the contributor role on the capacity. Capacity admins grant contributor permissions to the whole organization or to specific users or security groups. A capacity contributor can assign workspaces to the capacity but can't change its settings or delete it, which lets workspace admins move workspaces without getting administrative control of the capacity.

• APermissions removed on the Manage permissions page apply only after the workspace is refreshed

  Incorrect

  There's no workspace refresh step; the delay comes from how long revocation takes for a signed-in user.

• BA removed permission stays valid until his current session expires after 24 hours

  Incorrect

  Revocation isn't tied to a 24-hour session; for a signed-in user it takes effect within up to two hours.

• CA revoked item permission can take up to two hours to take effect for a signed-in user

  Correct

  For signed-in users, permission revocations can take up to two hours; otherwise they apply at the next sign-in.

• DDirect permissions can be removed only by a Fabric administrator

  Incorrect

  Workspace admins and members manage item permissions; the change was made, it just hasn't taken effect yet.

When a user's permission on an item is revoked through the manage permissions experience, it can take up to two hours to take effect if the user is signed in. If the user isn't signed in, the permissions are evaluated the next time they sign in. Permissions inherited from a workspace role can't be changed on the permission management page.

• AShared with me currently lists only Power BI items

  Correct

  Non-Power BI Fabric items shared with you, such as lakehouses, don't appear there yet.

• BThe lakehouse was shared without the Read permission

  Incorrect

  Read is always granted when an item is shared, so the share itself gave you Read.

• CLakehouses can be shared only through a workspace role

  Incorrect

  Lakehouses can be shared as items, with permissions such as Read all with Apache Spark.

• DThe lakehouse share needs a day to sync to Shared with me

  Incorrect

  There's no sync delay; the view simply doesn't show non-Power BI items.

Item sharing always grants Read, so a recipient can discover the item in the OneLake catalog and open it, plus any additional permissions selected, such as Read all with SQL analytics endpoint or Read all with Apache Spark. The Shared with me option in the Browse pane currently displays only Power BI items, not non-Power BI Fabric items that were shared with you.

• ANo label until someone applies one manually

  Incorrect

  Inheritance upon creation applies here, so the notebook doesn't start unlabeled.

• BThe tenant's default label, which always overrides inheritance

  Incorrect

  A default label is applied only when no label comes through other means, such as inheritance.

• CThe label of the engineer's personal workspace

  Incorrect

  Workspaces don't pass labels to new items; the source item does.

• DConfidential, which the notebook inherits from the lakehouse

  Correct

  A notebook created from a lakehouse inherits the lakehouse's sensitivity label.

Inheritance upon creation means that when you create a new item from an existing item, the new item inherits the existing item's label. In Fabric this is supported for Power BI items and for several non-Power BI cases, such as a notebook, a pipeline or a shortcut created from a lakehouse. Default labeling applies only when an item doesn't get a label through other means.

• ARename it in the admin portal's capacity settings with the pencil icon

  Incorrect

  That works for Premium, Embedded EM and trial capacities, not for Fabric F SKUs.

• BNothing in place: a Fabric capacity's name can't be changed

  Correct

  Renaming is supported for Premium, Embedded EM and trial capacities, but not for Fabric capacities.

• CRename it in the Azure portal under Scale

  Incorrect

  Scale changes the SKU size; it doesn't rename the capacity.

• DAsk a Fabric administrator, who can rename any capacity

  Incorrect

  The restriction applies to the capacity type, whoever tries.

Capacity admins can rename Power BI Premium, Power BI Embedded EM and trial capacities in the admin portal's capacity settings, but a Fabric capacity's name can't be changed. To get a different name, you'd create a new capacity and assign the workspaces to it.