A.   a line chart that shows balances by quarter filtered to account categories that are longterm liabilities.

C.   a clustered column chart that shows balances by quarter filtered to account categories that are long-term liabilities.

Explanation:
The reporting goal for a balance sheet analysis, especially concerning long-term liabilities, is to show trends over time. Stakeholders need to see how these specific account balances have changed from one period to the next (e.g., quarter-to-quarter) to analyze debt repayment schedules, financial health, and leverage.
Let's analyze why these two visualizations are effective and why the others are not optimal for this specific goal.

Options A and C are Correct:
Both of these visualizations share the two critical components needed to meet the reporting goal:
They are filtered to the specific account categories of interest:
"long-term liabilities." This focuses the analysis on the relevant data.
They show data by quarter:
This provides the necessary time-series analysis to observe trends, increases, decreases, and patterns over multiple periods.

A. Line Chart:
This is the ideal visualization for showing trends over time. The connecting lines make it easy for the eye to follow the progression of each account category's balance across quarters.

C. Clustered Column Chart:
This is also very effective for comparing the values of different long-term liability accounts side-by-side for each quarter and for seeing the changes from one quarter to the next.

Why the Other Options Are Incorrect:
B. a clustered column chart that shows balances by date and account category without filters.
Incorrect: Showing the entire, unfiltered balance sheet (all assets, liabilities, and equity) in a single column chart by date would be far too cluttered and complex. It would be impossible to extract meaningful insights about long-term liabilities specifically. The lack of filtering makes this visualization unsuitable for the focused reporting goal.

D. a pie chart that shows balances by account category without filters.
Incorrect:A pie chart shows the proportion of parts to a whole at a single point in time. It is completely static and cannot show trends or changes over multiple quarters. It also suffers from the same problem as option B—it shows the entire balance sheet without focus, making it difficult to analyze the specific component of long-term liabilities.

E. a ribbon chart that shows balances by quarter and accounts in the legend.
Incorrect: While a ribbon chart can show data over time, its primary strength is illustrating how the ranking of categories changes. It is excellent for seeing which category is the "top" category in each period. For balance sheet amounts, the focus is on the absolute value and trend of specific accounts (like long-term liabilities), not on their changing rank against other accounts like cash or equity. It is a less effective and more specialized choice compared to a standard line or column chart for this scenario.

Reference:
Core Concept:
This question tests the knowledge of selecting appropriate visualizations based on the analytical goal. The key concepts are: Time-series analysis requires visuals that show data across a time axis (e.g., Line Charts, Column Charts). Filtering and Focus is necessary to avoid clutter and present clear, actionable insights for a specific business question.

Explanation:
The goal is to create a date key that can form a proper relationship with a Date table. This is a data preparation task that should be done as early in the process as possible.

1. Why "An M custom column" is Correct:
Data Preparation vs. Data Modeling:
This task is about preparing the source data. Power Query (which uses the M language) is the ETL tool in Power BI designed for this exact purpose—data transformation and shaping before it is loaded into the data model.
Efficiency and Best Practice:
Creating this column in Power Query (M) is a one-time operation during data refresh. The resulting date is stored in the model, making relationships and filtering very efficient.
Why not a DAX calculated column? While a DAX calculated column could achieve a similar result, it is calculated after the data is loaded into the model and consumes precious VertiPaq (in-memory) engine resources. For a static, structural column like a date key, it is a best practice to create it in Power Query. DAX is better suited for dynamic, context-aware calculations (measures) or columns that depend on other model relationships.

2. Why Date.EndOfMonth(#date([Year], [Month], 1)) is Correct:
This M language formula breaks down into two logical steps:
#date([Year], [Month], 1):
This function constructs a valid Date value from the existing [Year] and [Month] columns. It uses the first day (1) of the month because we need a valid starting point. For example, for Year=2023 and Month=10, it creates the date October 1, 2023.
Date.EndOfMonth(...):
This function then takes that first-day date and returns the last day of its respective month. Continuing the example, it would take October 1, 2023 and return October 31, 2023.
This is the perfect result for relating to a Date table, as it gives a single, specific date for each Year/Month combination in your BalanceSheet data.

Why the Other Formulas Are Incorrect:
Date.EndOfQuarter(#date([Year], [Month], 1)):
This is incorrect because it returns the last day of the quarter, not the month. For example, for October 2023 (Q4), it would return December 31, 2023, which is not the correct ending date for the month of October.
ENDOFQUARTER(DATE('BalanceSheet'[Year],BalanceSheet[Month],1),0):
This is a DAX function, not an M function. It would be syntactically incorrect in a Power Query custom column. Furthermore, even in DAX, it suffers from the same logical flaw as the previous option—it calculates the end of the quarter, not the end of the month.

Reference:
Core Concept:
This question tests the understanding of the correct tool for the job: using Power Query (M) for data preparation and structural changes, and understanding basic M language date functions.

D.   a single imported dataset

📘 Explanation:
Power BI supports combining data from multiple sources into a single imported dataset, which is the most efficient and flexible approach for report development. Import mode allows:
Integration of data from multiple tables and sources
Fast performance due to in-memory storage
Full support for modeling, DAX, and visuals
You do not need multiple datasets unless there are strict isolation or access control requirements. A single imported dataset can handle all reporting needs if properly modeled.

Reference:
🔗 Microsoft Learn – Understand dataset storage modes
🔗 Microsoft Fabric Community – Minimum number of datasets and storage mode

❌ Why other options are incorrect:
A. Two imported datasets
→ Unnecessary duplication. One well-designed dataset is sufficient.

B. A single DirectQuery dataset
→ Slower performance, limited modeling capabilities, and depends on source system availability.

C. Two DirectQuery datasets
→ Adds complexity and latency. Not needed unless source systems must remain live and isolated.

📘 Summary:
Use a single imported dataset to support multiple reports efficiently. It offers the best performance, flexibility, and simplicity for most reporting scenarios.

Explanation:
This process implements Row-Level Security (RLS) to ensure that when a business unit analyst views a report, they only see data for their specific business unit.

Step 1: From Power BI Desktop, create four roles.
Explanation:
This is the foundational step. You must first define the security roles within the data model itself. Since there are four business units, you would create four corresponding roles (e.g., "Role_UnitA", "Role_UnitB", etc.). This is done in Power BI Desktop using the "Manage Roles" dialog box.
Why it must be first: You cannot configure security for roles that do not yet exist. All RLS logic is built upon these role definitions.

Step 2: From Power BI Desktop, add a Table Filter DAX Expression to the roles.
Explanation:
After creating a role, you must define its security rules. This is done by writing a DAX expression that filters the data. For example, for a role meant to see only data for "UnitA", the DAX expression on the relevant table would be [BusinessUnit] = "UnitA" or [BusinessUnit] = "UnitA". This expression is applied for any user assigned to that role.
Why it must be second:
The filter expression is the core of the security rule and is a property of the role. Therefore, the role must be created (Step 1) before you can assign a filter to it.

Step 3: From Power BI Desktop, publish the dataset to powerbi.com.
Explanation:
The roles and their RLS rules are defined in the .pbix file. To make these security definitions available in the cloud service where users access reports, you must publish the file from Power BI Desktop to a workspace in the Power BI service.
Why it must be third: The security model is part of the dataset. You must deploy the dataset to the service before you can manage user assignments to the roles you just created and configured.

Step 4: From powerbi.com, add role members to the roles.
Explanation:
The final step is to map individual users or security groups to the roles you created. This is done in the workspace settings in the Power BI service. You select the dataset, go to its Security settings, and assign the business unit analysts to their respective roles.
Why it must be last and is correct:
Until this step is completed, the RLS rules are defined but not enforced on any specific user. Assigning a user to a role activates the DAX table filter for that user whenever they interact with reports based on the dataset.

Why the Other Action is Incorrect
From powerbi.com, assign the analysts the Contributor role to the workspace.
Explanation:
This action controls permissions to the workspace (e.g., allowing users to publish reports or modify content). It is unrelated to Row-Level Security (RLS), which controls which rows of data a user can see within a report. A user can be a Contributor, Member, or Viewer and still have RLS applied to them. Assigning a workspace role does not filter the data they see.

Reference:
Core Concept: This question tests the procedural knowledge for implementing Row-Level Security (RLS) in Power BI, which involves both Desktop (model definition) and Service (user management) steps.

A.   

DirectQuery

A.   

bar chart

Explanation:
Scenario: The On-Time Shipping report will show the following metrics for a selected
shipping month or quarter:
The percentage of orders that were shipped late by country and shipping region
Customers that had multiple late shipments during the last quarter
Note: Bar and column charts are some of the most widely used visualization charts in
Power BI. They can be used for one or multiple categories. Both these chart types
represent data with rectangular bars, where the size of the bar is proportional to the
magnitude of data values.
The difference between the two is that if the rectangles are stacked horizontally, it is called
a bar chart. If the rectangles are vertically aligned, it is called a column chart.
Reference:
https://www.pluralsight.com/guides/bar-and-column-charts-in-power-bi