Task 2.1: Create objects in a lakehouse or warehouse

• AA table shortcut in Tables for each of the 40 tables

  Incorrect

  Each table shortcut links to one table, so a table added to the finance schema later needs another shortcut.

• BA shortcut in Files that points to the Tables/finance folder of FinanceLH

  Incorrect

  Table discovery doesn't happen in the Files folder, so the Delta tables wouldn't appear as tables.

• CA schema shortcut that points to the finance schema of FinanceLH

  Correct

  A schema shortcut creates a schema whose tables reference the source schema, and changes in the source, including new tables, are reflected automatically.

• DA Copy job that copies the finance schema into AnalyticsLH

  Incorrect

  A Copy job copies the data, which the requirement rules out.

In a schema-enabled lakehouse, a schema shortcut creates a new schema that references Delta tables in a schema of another lakehouse or in a folder of external storage such as ADLS Gen2. Changes to the tables in the source location are reflected in the schema automatically. Shortcuts in the Tables section can link to a single table or to a schema, while shortcuts in Files don't get table discovery.

• ACREATE TABLE test.FactSales AS SELECT * FROM dbo.FactSales, then reverse the faulty load

  Incorrect

  CTAS writes a full physical copy of the 2 TB table and takes far longer than seconds.

• BA shortcut in a test lakehouse that points to dbo.FactSales

  Incorrect

  A shortcut reads the table as it is now, faulty rows included, and the testers' changes would have to go to the source.

• CCREATE TABLE test.FactSales AS CLONE OF dbo.FactSales AT a timestamp of 18:00 UTC yesterday

  Correct

  A clone copies only metadata, can target a point in time within the retention period, and is independent of its source afterwards.

• DCREATE TABLE test.FactSales AS CLONE OF dbo.FactSales, with no timestamp

  Incorrect

  Without a point in time, the clone reflects the current table, which already contains the faulty changes.

CREATE TABLE AS CLONE OF creates a zero-copy clone: the metadata is copied while the new table references the same Parquet files in OneLake. The clone can be based on the current state or on a point in time within the configured data retention period (30 days by default), within or across schemas of one warehouse. After creation, DML and DDL on the clone don't affect the source, and changes to the source don't reach the clone.

• APartition it by a Month column derived from EventDate

  Correct

  About 36 values stays under the guidance of fewer than 100-200, and a day's delete touches only its own month's files.

• BPartition it by UserID so each user's rows sit together

  Incorrect

  UserID has a very high cardinality, which creates many small Parquet files and row groups that hurt Direct Lake transcoding.

• CPartition it by EventDate, one partition for each day

  Incorrect

  Three years of days is about 1,095 values, far above the fewer than 100-200 distinct values recommended for a partition column.

• DPartition it by Region, which has only eight values

  Incorrect

  The cardinality is low, but every region holds rows of every day, so the nightly delete still rewrites files in all eight partitions.

With a rolling-window batch pattern, deleting one day from an unpartitioned Delta table can touch almost every Parquet file, so Direct Lake must retranscode most of the data. Partitioning helps only when the partition column collocates the data that the delete removes, and it must have a low cardinality: as a best practice, fewer than 100-200 distinct values, because extensive partitioning multiplies Parquet files, row groups and column segments. When no column fits, create one by reducing the cardinality of an existing one, for example a month derived from the date.

• AALTER TABLE ... ADD LoyaltyTier varchar(20) NULL, then UPDATE it from the lookup table

  Correct

  Warehouse supports adding nullable columns with ALTER TABLE, and UPDATE can then fill them in place.

• BALTER TABLE dbo.DimCustomer ADD LoyaltyTier varchar(20) NOT NULL DEFAULT 'None' in one step

  Incorrect

  Only nullable columns can be added; other ALTER TABLE operations, such as adding a NOT NULL column with a default, are blocked.

• CADD a computed column that looks up the tier from the lookup table

  Incorrect

  Adding a computed column isn't among the ALTER TABLE operations that Warehouse supports, so the statement is blocked.

• DRebuild the table with CREATE TABLE AS SELECT under the same name

  Incorrect

  CTAS creates a new table, so reusing the name means dropping dbo.DimCustomer first, which breaks the views and reports built on it.

In Fabric Data Warehouse, ALTER TABLE supports only a subset of operations: adding nullable columns of supported data types, dropping columns, and adding or dropping primary key, unique and foreign key constraints with NOT ENFORCED. Other ALTER TABLE operations are blocked. Adding the column as nullable and filling it with UPDATE keeps the table, its rows and the objects that depend on it.

• ACreate a shortcut in OrdersDW that points to ScienceLH

  Incorrect

  Shortcuts can be created in lakehouses and KQL databases, not in warehouses, and it would point the wrong way.

• BRun a nightly Copy activity from OrdersDW into a ScienceLH table

  Incorrect

  A copy goes stale between runs and duplicates the data.

• CCreate a OneLake shortcut in the Tables section of ScienceLH that points to dbo.FactOrders

  Correct

  An internal shortcut can point to a warehouse table, and a Delta shortcut in Tables can be read as a table with Spark SQL.

• DCreate a view in ScienceLH's SQL analytics endpoint that selects from OrdersDW.dbo.FactOrders

  Incorrect

  Cross-database references reach only warehouses and endpoints in the current workspace, and OrdersDW is in another one.

Shortcuts can be created in lakehouses and KQL databases. An internal OneLake shortcut can point to data in other Fabric items, including warehouses, across workspaces, and the item types don't need to match. A shortcut in the Tables section that points to Delta data is recognized as a table, so Spark can read it with Spark SQL by name, and it always reflects the current data.

• ARun OPTIMIZE on dbo.Sales so that the endpoint picks up the new files sooner

  Incorrect

  Compaction rewrites the Parquet files but doesn't lift the block that the foreign key places on schema changes.

• BTurn on Delta column mapping by name on dbo.Sales

  Incorrect

  Column mapping doesn't lift the block that a foreign key in the endpoint places on schema changes.

• CRecreate the constraints with NOT ENFORCED

  Incorrect

  Constraints in Fabric are already NOT ENFORCED; the problem is the foreign key itself, not its enforcement.

• DDrop the foreign key constraints on the table in the SQL analytics endpoint

  Correct

  A foreign key added in the endpoint prevents further schema changes, such as new columns, from reaching the table.

The SQL analytics endpoint generates T-SQL tables from the lakehouse's Delta tables and keeps their metadata in sync automatically. If you add a foreign key constraint between tables in the SQL analytics endpoint, you can't make further schema changes, such as adding new columns. When expected Delta columns don't show up, check for a foreign key constraint that might prevent updates on the table.

• AA new schema named productdevelopment

  Incorrect

  The name is the table's; a schema is used only when you write schema.table.

• BThe Files folder, as an unregistered Delta folder

  Incorrect

  saveAsTable registers a table under Tables, not a folder in Files.

• CThe write fails, because schema-enabled lakehouses require a schema name

  Incorrect

  The schema part can be omitted; Spark then uses the default schema.

• DThe dbo schema of the default lakehouse

  Correct

  Without a schema name, the table is stored in the default dbo schema.

Every schema-enabled lakehouse includes a dbo default schema under Tables that can't be renamed or removed. To store a table in a specific schema, include the schema name when you save it, for example saveAsTable("marketing.productdevelopment"); without a schema name, the table goes to the dbo schema. In code, the four-part namespace workspace.lakehouse.schema.table falls back to defaults for omitted parts.

• AA follow-up call that enables schemas on the existing lakehouses

  Incorrect

  Tools that convert a non-schema lakehouse to a schema-enabled one in place aren't available yet.

• B"enableSchemas": true in the request's creationPayload

  Correct

  Through the REST API, schemas aren't enabled by default and must be requested in the creation payload.

• CA dbo schema created with Spark SQL after creation

  Incorrect

  A non-schema lakehouse doesn't become schema-enabled by running Spark SQL in it.

• DThe Lakehouse schemas option in the workspace settings

  Incorrect

  Schema support is chosen per lakehouse at creation, not as a workspace setting.

Schemas are enabled by default when you create a lakehouse in the Fabric portal, but not when you create one through the Create Lakehouse REST API, where you include "enableSchemas": true in the creationPayload. Migration tools that convert a non-schema lakehouse to a schema-enabled lakehouse without moving data aren't available yet.

• AIn V-Order, because Copy writes lakehouse tables in V-Order by default

  Correct

  The lakehouse connector writes data to lakehouse tables in V-Order unless you change it.

• BWithout V-Order, because the workspace's Spark default applies to every writer

  Incorrect

  The Spark session setting governs Spark writes; the Copy activity has its own default.

• CAs CSV files under Tables, because Copy keeps the source format

  Incorrect

  Copying to a lakehouse table writes Delta Parquet, not the source CSV files.

• DIn V-Order only if the table has the delta.parquet.vorder.enabled property

  Incorrect

  The Copy activity uses V-Order by default without needing that table property.

The Copy activity's lakehouse connector writes data to lakehouse tables in V-Order by default. V-Order for Spark is controlled separately, by the spark.sql.parquet.vorder.default session setting, table properties and writer options, and it's disabled by default for Spark in new workspaces.

• AGive them SELECT on dbo.Orders and CREATE TABLE in the dbo schema, keeping the Viewer role

  Incorrect

  SELECT is needed, but the Viewer workspace role can't create a clone.

• BShare the warehouse with them with Read all data using SQL

  Incorrect

  ReadData lets them read tables; it doesn't allow creating clones.

• CGive them the Contributor role, with SELECT on the table and CREATE TABLE in the schema

  Correct

  Cloning needs Admin, Member or Contributor, SELECT on every row and column of the source, and CREATE TABLE in the target schema.

• DRun the statement in the lakehouse's SQL analytics endpoint instead

  Incorrect

  Clone table isn't supported on the SQL analytics endpoint of a lakehouse.

Users with the Admin, Member or Contributor workspace role can clone tables in the workspace; the Viewer role can't. They also need SELECT permission on all the rows and columns of the source table and CREATE TABLE permission in the schema where the clone is created. Table clones aren't supported on the SQL analytics endpoint of a lakehouse.