A Microsoft Fabric Data Factory pipeline runs a Notebook activity that loads one source table into a Lakehouse. The pipeline already holds the table name in a pipeline parameter, and the team wants the notebook to load whichever table the pipeline passes at run time without editing the notebook code between runs. Which approach lets the pipeline supply the table name to the notebook as a run-time value?
- AHard-code the table name as a Python variable in the first notebook cell and update that cell each time the pipeline targets a different source table.
- BRead the table name inside the notebook from a workspace environment variable that an administrator updates in workspace settings before each pipeline run.
- CTag a notebook cell as the parameters cell, declare the table name there, and map the pipeline parameter to it in the Notebook activity base parameters. Correct
- DStore the table name in a Lakehouse configuration table and have the notebook query that row at the start of every run to decide which table to load.
Why A is wrong: A hard-coded variable forces a manual code edit for every table, which is exactly the per-run editing the team wants to avoid; it ignores that the pipeline already carries the name as a parameter.
Why B is wrong: A workspace setting is shared and static, so it cannot vary per run and still needs a manual change before each execution; it also bypasses the pipeline parameter that is the natural carrier of the value.
Why C is correct: A toggled parameters cell defines defaults that the Notebook activity overrides through base parameters, so the pipeline injects its table-name parameter at run time and the same notebook serves any table without code edits.
Why D is wrong: A config-table lookup can drive a notebook, but it adds a separate store and ignores the value the pipeline already passes; the requirement is to receive the pipeline parameter, not to fetch a different source of truth.