Task 1.3: Manage the analytics development lifecycle

• AThe .gitignore that Desktop creates keeps the local data cache, cache.abf, out of the repository

  Correct

  Without cache.abf, Desktop opens the full model definition with no data, so the visuals stay empty until a refresh.

• BThe project was saved in TMDL format, which doesn't keep data the way TMSL does

  Incorrect

  TMDL and TMSL both describe metadata only; the data lives in cache.abf whichever format the model uses.

• CPower BI projects can't keep Import tables, so the model opened with every table in DirectQuery mode

  Incorrect

  Projects support Import tables; their data is kept locally in cache.abf, not in the definition files.

• DThe report folder references the model with byConnection, so the report opened live connected

  Incorrect

  A byConnection reference opens the report against a published model without edit mode; here the model opened fully editable, which is byPath behavior.

When you save as a project, Power BI Desktop writes the report and semantic model definitions as text files and creates a .gitignore (if none exists) that excludes .pbi/localSettings.json and .pbi/cache.abf. Desktop can open a project without cache.abf: it then loads the report connected to the model with its entire definition but without data. If a cache.abf exists, Desktop loads its data.

• ATurn on autobinding in the deployment pipeline's settings and deploy the report again

  Incorrect

  Autobinding isn't an option to switch on: pipelines always try to keep the connection, and that fails while the model isn't in Test.

• BCreate a parameter rule on the Sales report that points it to SalesModel in Test

  Incorrect

  Parameter rules exist for semantic models and dataflows, not for reports; reports bind to their model through autobinding.

• CDeploy again with Select related, so that SalesModel is deployed together with the report

  Correct

  Select related adds the model the report depends on, and the report then autobinds to the model in Test.

• DRefresh SalesModel in Test after the deployment

  Correct

  Deployment copies metadata only, so the new model in Test has no data until it's refreshed.

• ECreate a data source rule on the Sales report that points it to SalesModel in Test

  Incorrect

  Data source rules are available for semantic models, dataflows Gen1 and paginated reports, not for a Power BI report's model connection.

Deployment pipelines keep the connection between dependent items: when a report is deployed and its semantic model exists in the target stage, the report autobinds to that model. If the model isn't deployed and isn't in the target stage, the deployment fails; Select related adds the items a selection depends on. Data isn't copied between stages, so a newly deployed semantic model must be refreshed before its reports show data.

• ACalculation groups can't exist in a model that's downloaded to Power BI Desktop

  Incorrect

  Power BI Desktop supports creating and editing calculation groups; the restriction comes from the XMLA write, not the object type.

• BThe model was converted to enhanced metadata, which a .pbix file can't hold

  Incorrect

  Models authored in Power BI Desktop already use enhanced metadata, which XMLA write operations require; it doesn't block downloads.

• CThe tenant setting that allows XMLA endpoints was turned off after the change

  Incorrect

  That setting controls XMLA and Analyze in Excel connections; turning it off wouldn't explain a missing download option.

• DA write through the XMLA endpoint blocks downloading the model as a .pbix file

  Correct

  After an XMLA write to a model authored in Desktop, the model can't be downloaded as a PBIX, so the original file should be kept.

XMLA write operations on semantic models authored in Power BI Desktop require enhanced metadata, which Desktop models implement. A write operation through the endpoint currently prevents the model from being downloaded back as a PBIX file, so authors should keep the original PBIX (or a Power BI project) as the source for later changes.

• ANothing; the 01:00 schedule is copied with the model

  Incorrect

  The refresh schedule isn't among the copied properties, so Production has none.

• BCreate a deployment rule that copies the refresh schedule

  Incorrect

  Deployment rules set data sources, parameters and default lakehouses, not schedules.

• CSet up the refresh schedule again in Production

  Correct

  A semantic model's refresh schedule is one of the properties that deployment doesn't copy.

• DMake the deploying user the owner of the Test semantic model first

  Incorrect

  Ownership decides who manages the model's settings; it doesn't carry the schedule into Production.

Deployment pipelines copy items between stages, but some item properties aren't copied, and for semantic models they include the refresh schedule. After the first deployment, set up the model's schedule again in the target stage. Deployment rules can change data sources, parameters or a notebook's default lakehouse, not schedules.

• ALabels are stored in the .gitignore file of the project

  Incorrect

  .gitignore only lists files that Git should leave untracked; it holds no labels.

• BSensitivity labels aren't supported with Power BI projects

  Correct

  Labels are a listed limitation of PBIP, so the label requirement can't be met inside the project files.

• CLabels are kept in definition.pbism and applied when the project opens

  Incorrect

  definition.pbism describes the semantic model definition format, not a sensitivity label.

• DProjects inherit the label of the Git repository they're saved in

  Incorrect

  Git repositories don't carry Purview sensitivity labels.

Saving as a Power BI project writes report and semantic model definitions as text files in folders, along with a .gitignore file. The considerations and limitations of Power BI projects include that sensitivity labels aren't supported, along with limits such as the 260-character path length and no direct save to OneDrive or SharePoint.

• ADelete the deployment pipeline's Production stage first

  Incorrect

  The other stages don't matter; this workspace itself must be unassigned.

• BRemove all items from the workspace, then delete it

  Incorrect

  The assignment to the pipeline, not the items, blocks the deletion.

• CAsk a capacity admin to remove the workspace from its capacity first

  Incorrect

  Capacity assignment doesn't block deleting a workspace; the pipeline assignment does.

• DUnassign the workspace from the deployment pipeline, then delete it

  Correct

  A workspace assigned to a deployment pipeline can't be deleted until it's unassigned from the pipeline.

If you try to delete a workspace from its settings while it's assigned to a deployment pipeline, the deletion fails. From the workspace, select View deployment pipeline to open the pipeline, unassign the workspace from its stage, and then remove the workspace.

• AA .pbids file supports only a single data source

  Correct

  Specifying more than one data source in a PBIDS file results in an error.

• BA .pbids file can't point to SQL Server databases

  Incorrect

  PBIDS files support the data connections that Power BI Desktop supports, with a few exceptions such as Live Connect.

• CA .pbids file must include the authors' credentials

  Incorrect

  PBIDS files don't include authentication information; authors are prompted for credentials.

• DA .pbids file can only be created by hand in a text editor

  Incorrect

  Power BI Desktop can export a PBIDS file from Data source settings.

A PBIDS file is a Power BI data source file that streamlines Get Data: when an author opens it, Power BI Desktop prompts for credentials and shows the Navigator to pick tables. Currently a PBIDS file supports only a single data source, and it doesn't include authentication information or table and schema information. You can export one from Data source settings or write it in a text editor.