Microsoft Power BI Data Analyst PL-300 (PL-300) — Questions 451–524

Filtering the folder contents by 'Date Modified' before combining is correct because the folder query in Power Query contains metadata (including 'Date Modified') for each file before any binary content is read. By filtering this file-list table, you prune the set of files that the 'Combine Files' transformation will process, so only recent files are expanded and loaded. This is an efficient streaming-like approach that minimizes data extraction and refresh time.

Adding latitude and longitude fields (both numeric) gives the map visual exact coordinate pairs for each store, bypassing the geocoding service entirely. This is the only option that directly addresses the root cause of a map failing to place points—the geocoder may fail on ambiguous or non-standardized city names, whereas coordinates are unambiguous, instantaneous, and always render at the correct location regardless of how the address or city is formatted.

In DAX, CALCULATE modifies the filter context by applying its filter arguments. When FILTER is used as a filter argument, it creates a new filter on the Sales table that replaces any existing filters on that table, including those from a slicer. This replacement behavior is by design: filter arguments in CALCULATE override existing filters on the same columns or tables. Therefore, the slicer's context is ignored, and the measure returns values based solely on the FILTER condition.

Configuring a Conditional Access policy in Microsoft Entra ID that targets the Power BI cloud app and requires multifactor authentication enforces the MFA challenge when a user signs in to Power BI, including on personal devices. Because Power BI uses Microsoft Entra ID for authentication, the policy applies at sign-in and satisfies the security team's requirement without needing Fabric capacity.

Row-level filtering in Power Query (M) is applied before data enters the VertiPaq engine, enabling you to import only the rows that are relevant to your analysis. This reduces the number of rows materialized in the model, which directly shrinks the overall memory footprint and improves refresh time, query performance, and columnar compression ratios. Because only the necessary data is loaded, all downstream measures and reports run over a targeted dataset, making this the most effective way to reduce the initial data load size.

Static row-level security is implemented by creating one or more roles whose DAX filters use constant values, such as [Country] = "USA". Every user assigned to a specific role receives exactly the same filtered view; to grant different views, you must create separate roles for each distinct filter value. This approach is predictable and easy to audit, but it becomes cumbersome when many user groups need different subsets of rows.

The Analytics pane in a line chart provides a dedicated 'Constant line' option that lets you specify a fixed numeric value or a measure to draw a horizontal reference line across the visual. This is exactly the intended method for annotating a chart with a target value, and it can be styled with colors, dashes, and a data label. Because the constant line is applied at the visual level, it remains aligned with the chart's y-axis and plot area, clearly showing when monthly sales fall above or below the target.

The 'Expand' button on a column containing structured values (like a nested array) allows you to expand the array elements into new rows, effectively flattening the nested data. This is the correct way to turn each order into a row. Selecting all fields ensures all order details are included. This transformation is standard when working with JSON or XML data in Power Query.

Aggregating transaction data to a daily level reduces the number of rows imported into the model, which directly shrinks the compressed columnar storage. For example, millions of individual sales rows become a few thousand daily totals, and lower cardinality in date and measure columns yields better compression. This is an effective size-reduction technique when daily granularity satisfies your reporting needs.

Order Details is the correct fact table because each row represents a line item from an order, the lowest grain of the sales process, and it holds numeric measures like quantity, unit price, and discount that can be aggregated with SUM and similar functions. It also contains foreign key columns (OrderID, ProductID, CustomerID, etc.) that link to the surrounding dimension tables, creating the star schema. The presence of both additive measures and multiple dimension keys is the defining property of a fact table.

Inner join retains only rows where a matching key exists in both tables—so an order is included only if it has a corresponding customer, and customers appear only if they have at least one order. This produces exactly the intersection of the two queries, which is the standard approach for combining transactional and dimensional data to analyze completed order-customer pairs.

Alice, as the dataset owner, bypasses RLS entirely. In the Power BI service, users who have Owner permission (or Write permission) on the dataset are exempt from row-level security filters, so they can see all rows in any report built on that dataset. Even in Power BI Desktop, the model designer sees all data unless they explicitly test a role with 'View as'. Thus, Alice seeing all data is expected when she owns the dataset.

Custom visuals are compiled against a specific Power BI API version, and that API version must be within the range supported by your Power BI Desktop release. When a visual was built for an older API or targets a newer API that your Desktop does not implement, the visual can fail to load, appear blank, or throw a rendering exception. Checking compatibility means verifying the minimum supported Power BI version on the visual's AppSource listing or its metadata, and confirming your Desktop is at or above that version. This is a critical diagnostic because an incompatible visual will misbehave regardless of how correctly its data fields are configured.

DATESINPERIOD is a general-purpose time intelligence function that returns a table of dates from an initial start date and moves a specified number of intervals (such as -12 months) into the past or future. When used with a start date of the current context date and an interval of -12 MONTH, it dynamically constructs the exact trailing 12-month period, including all dates from the current date going back one year. This makes it the correct choice for a last-12-months measure because it directly defines the rolling window based on the current filter context.

A drillthrough page is lazy-loaded by Power BI, meaning the daily revenue line chart is not instantiated or queried until a user explicitly right-clicks a data point on the category page and selects the drillthrough target. The source category page remains the only visual rendered upfront, so the detailed trend data is deferred until the exact moment of interaction. This reduces the report's initial load time and is the recommended pattern for on-demand detail exploration in PL-300 performance optimization.

On-premises or private-network sources cannot be reached directly by the Power BI service, so a data gateway must bridge the connection. Without a configured gateway, the scheduled refresh cannot authenticate to the source, explaining the consistent failures despite Premium capacity.

Power BI dataflows are a native, cloud-based ETL service in the Power BI service that can connect to a wide range of sources, apply data cleansing and shaping logic through Power Query Online, and include masking steps such as hashing, replacing, or removing sensitive columns before the resulting entity is loaded into a semantic model. This centralized approach supports enterprise-scale data preparation, scheduled refresh, and reusable entities that can serve multiple reports and datasets, making it the right architecture for this scenario.

Drillthrough is a built-in Power BI feature that enables navigation from a data point on a source visual to a separate, binded target report page. When the user right-clicks a bar and selects the drillthrough target, the target page is automatically filtered to the clicked data point's field values (e.g., the specific category), providing a contextual detail view. This matches the requirement exactly because it is triggered by a per-data-point action and results in a page transition.

Import mode loads the contents of the Excel file into the VertiPaq in-memory engine, where data is compressed and stored for fast interactive analysis. After the initial load, you can refresh the dataset on a schedule to pick up changes in the workbook, though for files on a local machine an on-premises data gateway is needed for automated refresh. Because the data is cached, all Power BI features—including calculated columns, measures, and RLS—are fully supported, and visuals do not hit the source file on every interaction.

Creating a Data Loss Prevention policy in Microsoft Purview that targets the Power BI workload is the correct, service-native approach: the policy can specify a condition that the sensitivity label equals 'Highly Confidential', and define an action to block the share, optionally allowing an override or business justification. When a user attempts to share a labeled item, Purview, via its integration with Power BI, intercepts the request and enforces the policy in near real time, providing both audit and DLP event logs. This is the only listed option that directly uses label-aware DLP semantics to prevent unauthorized sharing.

A line chart is the correct visualization for analyzing customer churn trends over time because it plots time on the x-axis (a continuous or ordinal field) and the churn metric on the y-axis, allowing you to see peaks, troughs, and overall direction. Line charts excel at highlighting temporal patterns, such as seasonality or steady declines, because the connecting line guides the eye across intervals. They also support multiple series, so you can compare churn across segments without losing clarity.

DATESYTD requires a gapless, contiguous set of dates spanning the entire year because it internally constructs a date range from January 1 through the last visible date in the filter context. If the Date table has missing dates—for example, only trading days or a subset of dates—the year-to-date calculation cannot include those gaps, causing blanks or understated totals. A properly built continuous date table with every calendar date is mandatory for time intelligence functions.

Power Query inferred text because the CSV values were read as strings. Explicitly setting the column's data type to Date via the Data Type dropdown applies locale-aware conversion, ensuring the values are stored and modelled as dates rather than text.

By importing raw data, you offload transformation work to Power BI's mashup engine, which leverages Power Query's in-memory and streaming capabilities. This avoids pushing compute-intensive operations to SQL Server, preserving database resources for other workloads. Additionally, Power Query's step-based transformations are highly maintainable and can be refreshed on a schedule.

Reducing the number of parallel data refresh operations lowers the peak memory and CPU demand on the capacity because each refresh must load and compress the entire dataset into memory. By serializing refreshes, you flatten the resource usage curve, preventing the capacity from reaching its memory threshold during overlapping refresh jobs. This is a direct, effective lever to avoid capacity throttling and eviction.

Adding alt text to each visual is the correct approach because Power BI's accessibility model exposes visuals to screen readers through their 'Accessibility' pane's 'Alt text' field. When a screen reader encounters a visual, it reads the provided alt text instead of attempting to interpret the visual content, giving non-sighted users a meaningful summary. To be effective, alt text must be concise yet descriptive, and it should be set consistently for charts, slicers, and images; this directly fulfills the requirement to make the report accessible to users who rely on assistive technologies.

A defining characteristic of DirectQuery is that report interactions—such as filtering, slicing, or simply changing a page—are translated in real time into native queries executed directly against the underlying data source. This ensures that the report always shows the current state of the source, but it also means query performance depends heavily on the source's responsiveness and indexing. Since no snapshot is taken, any change in the source is immediately reflected in the report.

Adding an Azure AD group to the workspace role is the correct, recommended approach for scalable access management in Power BI. When you assign the group to a role such as Viewer, Contributor, Member, or Admin, all current and future members of that group automatically receive the corresponding permissions on the workspace and its content. This centralizes identity governance in Azure AD: adding or removing a user from the group instantly reflects in Power BI, with no per-workspace or per-report edits needed. It aligns with enterprise security best practices and simplifies auditing and compliance.

In DirectQuery mode, Power BI sends every visual query directly to the underlying SQL Server, so query performance depends on the source engine's ability to return results quickly. Creating indexes on columns used in filters and relationship joins lets SQL Server use efficient lookup and merge operations instead of full table scans, dramatically reducing query latency. Without appropriate indexes, even simple filter operations can force the database to scan millions of rows, which directly degrades the Power BI report experience.

This expression is correct because DATESINPERIOD constructs a continuous, dynamic 30-day window ending at the boundary defined by MAX('Date'[Date])—the latest date present in the current filter context. By specifying DAY as the interval type and a negative offset of -30, the function returns the set of dates from MAX('Date'[Date]) minus 29 days through MAX('Date'[Date]), inclusive of both endpoints, resulting in exactly 30 calendar days. Since it is anchored to the maximum date in the date table rather than to a hardcoded system date like TODAY(), it remains accurate even when the underlying data has not been refreshed up to the current day, and it automatically adapts to whatever date range is selected in a report slicer or page filter, making it the most robust choice for a rolling last-30-days measure.

In a paginated report, a dataset defines the query and the fields that populate the data regions; without a dataset, there is no data to bind to the report items. The dataset references a data source and includes the query text, parameters, and field collection. Even if a report uses a shared dataset, there is still at least one dataset in the report's data model. Therefore, a dataset is an essential, required component.

Using 'Split Column' by delimiter is the core transformation that parses the fullname column into two columns based on the comma separator. In Power Query, this command (found on the Transform tab) scans each cell for the specified delimiter and divides the text at that point, producing two new columns containing the fragments. This is the only option here that directly creates the separate LastName and FirstName values from the original string, so it is the correct primary action.

Creating a one-to-many relationship from Customers[CustomerID] to Sales[CustomerID] is the correct star schema design. This relationship lets filter context flow from the dimension table (Customers) to the fact table (Sales), enabling correct aggregations like total sales by customer name. It also uses Power BI's optimized VertiPaq engine to join tables only when needed, reducing memory and improving query performance compared with calculated columns or merged tables. The cardinality is correctly specified because one customer can appear in many sales records.

Roles in Power BI define row-level security by using DAX expressions as filter predicates. For example, a role can be configured with a DAX filter like `[SalesRegion] = "North"` or a more complex FILTER expression that returns a table of allowed rows. These expressions are evaluated within the filter context of each row, and only rows that return TRUE for the predicate become visible to users assigned to that role. This makes DAX the core mechanism for implementing custom, flexible row-level security in Power BI.

Marking a table as a date table in Power BI Desktop (via Table tools > Mark as date table) establishes it as the model's official calendar source. This designation is required for time intelligence functions like TOTALYTD, SAMEPERIODLASTYEAR, and DATESBETWEEN to operate correctly. Power BI validates that the chosen date column contains continuous, unique dates and automatically uses it for date-based calculations and hierarchy generation.

Merge Queries performs a relational join by matching rows on a common key column, such as ProductID, with configurable join types (Inner, Left Outer, Full Outer, etc.). This enriches each sales record with the corresponding product attributes (name, price, category) from the Products table in a single output table. Because the requirement is to combine two tables column-wise based on a shared field, Merge Queries is the correct approach.

In composite models, time intelligence functions like DATESYTD or TOTALYTD often fail or behave unexpectedly when they reference tables from both Import and DirectQuery storage modes. This occurs because the engine cannot guarantee consistent calendar boundaries across heterogeneous sources, and certain functions such as OPENINGBALANCEQUARTER rely on iterating a date table that must be fully cached. As a result, you may need to use CALCULATE with explicit filters or ensure all supporting tables are in the same storage mode.

Creating a calculated NetAmount column in Power Query (M) evaluates Quantity * UnitPrice - Discount once at refresh time, storing the result as a static column in the data model. The subsequent measure SUM(Sales[NetAmount]) simply aggregates those pre-computed values, avoiding row-by-row evaluation at report time and improving query performance for large fact tables. Because the calculation is pushed to the query engine instead of the DAX engine, it also keeps the code simpler and avoids iterator overhead during visual rendering.

CustomerID, ProductID, and OrderDate are all foreign keys that establish relationships to the Customer, Product, and Date dimension tables. In a proper star schema, these keys should be replaced with dimension attributes such as CustomerName, ProductCategory, and OrderMonth during reporting. This replacement makes reports readable and lets users filter and group by meaningful descriptions instead of opaque ID numbers.

Viewer is a legitimate read-only workspace role in Power BI. Viewers can see and interact with dashboards, reports, and apps in the workspace, but they cannot edit content, share items, or manage permissions. This role is ideal for consumers who only need to view and analyze data without modifying the underlying reports.

SUM is the correct DAX function to add all values in a numeric column, such as Sales[SalesAmount]. It aggregates the column across the filter context, providing the total sales amount. This is a fundamental aggregation function for measures and is efficient because it operates on a single column without iterating rows.

TOTALYTD is a DAX time intelligence function that evaluates an expression over the year-to-date period based on a given date column. It returns a scalar value representing the cumulative total from the start of the year to the latest date in the current filter context. This function is specifically designed for time-based calculations, making it a valid answer.

ALL('Sales'[Category]) inside a CALCULATE removes all filters applied to the Category column, including row and slicer filters, giving you the grand total across every category. This is the canonical method for building a percentage-of-total measure: you divide the current category's sales by the unfiltered total from CALCULATE with ALL. By clearing only the category filter, you preserve other context like date ranges, making the measure precise and flexible.

Keeping Customers and Products as separate dimension tables and Orders as the fact table correctly implements a star schema: the fact table holds numeric measures and foreign keys, while each dimension provides descriptive attributes linked by one-to-many relationships. This design lets users filter sales by any customer or product attribute without duplication or fan-out, and it lets DAX aggregate order measures directly and efficiently.

Remove Duplicates evaluates the selected columns as a composite key, so rows that match on MeterId, ReadingTimestamp, and Consumption are treated as duplicates. One copy of each distinct combination is retained. This precisely targets the exact duplicates described without risking removal of legitimate readings that differ in any column.

Matrix visuals in Power BI support sparklines. In the Format pane, under 'Sparklines', you can turn them on and add a measure (e.g., Total Sales). The sparkline then appears in each row, showing the trend across the columns (years). This is the correct way to add sparklines to a matrix.

The many-to-one (*:1) relationship from Orders to Customers is correct because the Orders table contains many rows that reference the same single customer row through the customer key. Each order belongs to exactly one customer, so the CustomerID column is not unique in Orders but is unique in Customers. This is the standard fact-to-dimension relationship in Power BI, where filtering from Customers to Orders yields all orders for that customer.

This tenant setting specifically blocks users from connecting Power BI Desktop to the Power BI service. Enabling this restriction ensures that users can only use the browser-based service, as required. It is the direct control for limiting Desktop client access to the service.

The dataset points to Azure SQL Database, a fully managed cloud PaaS service, so Power BI can connect directly over the internet without any on-premises data gateway. Neither Import mode nor DirectQuery requires a gateway for cloud-only sources, because the data source is not behind a corporate firewall and is already reachable via standard cloud endpoints. This is why the configuration correctly shows no gateway association and the dataset functions normally.

Star schema is the recommended modeling approach in Power BI because it separates measure-bearing numeric data (Sales) from descriptive attributes (Customers, Products). This structure leverages VertiPaq's columnar compression by storing dimensions as small, indexed tables, and enables unambiguous one-to-many relationships that make DAX filters propagate correctly. As a result, queries are simpler, more performant, and the model is easier for report consumers to navigate.

Splitting by comma as the delimiter separates the name into two columns, typically breaking at the comma between last and first name. After the split, the resulting columns often retain leading spaces (e.g., ' Doe' or 'Jane ') that come from the source data's formatting. Applying the Trim transformation removes these extraneous spaces, yielding clean standardized name values ready for further analysis or reporting. This combination of delimiter splitting and trimming is a best practice when handling delimited text with incidental whitespace.

Filtering out rows that are not needed reduces the volume of data loaded into the Power BI model, directly lowering the number of values that VertiPaq stores and compresses. The VertiPaq engine compresses data column-by-column, so fewer rows mean smaller dictionaries and bitmaps, which can also improve compression ratios. However, filter pushdown via query folding may further improve refresh speed, but the size reduction is the primary benefit.

This statement correctly describes the core mechanism Power Query uses when combining files. After you provide a sample file, Power Query auto-generates a parameterized function (often named 'Transform File') that captures the transformation steps applied to the sample file. It then calls that function for each file in the folder, passing the file's path and contents as parameters, which ensures the same cleaning, filtering, or reshaping logic is applied consistently across all files.

Performing aggregation in SQL before importing is a classic pushdown optimization that leverages the database engine to pre-summarize the sales data, so only the aggregated results are transferred to Power BI. This dramatically reduces the row count and the size of the imported dataset, leading to faster refreshes, lower model memory usage, and quicker report responses. It also offloads compute from Power BI to the SQL server, which is generally more scalable for large fact tables.

Setting QuoteStyle.None tells the CSV parser to ignore the special meaning of double quotes, so it treats every comma as a field separator, even those that are inside a quoted string. For example, a line like "John, Doe" would become two columns instead of one, causing column count mismatches and data shifting. This is exactly the kind of symptom that would appear when debugging an import. The fix is to use QuoteStyle.Csv (or another style) so the parser honors quoted fields and keeps embedded commas as part of the same value.

This is a correct use case for composite models. In Power BI, a composite model allows you to combine tables from different storage modes in a single data model. A DirectQuery table can be configured to always pull the latest data from the source, while historical tables can be imported and refreshed on a schedule. This hybrid approach gives you real-time visibility into current transactions without giving up the performance benefits of pre-loaded historical data.

The Microsoft Purview compliance portal (Audit) hosts the unified audit log for Microsoft 365, which captures user and admin activities across services, including Power BI. Events such as viewing a report, modifying a dataset, sharing a dashboard, and exporting data are recorded with actor, timestamp, operation, and affected item details. Searching this log is the standard way to perform compliance auditing of Power BI user activities, making it the correct answer.

Power BI's auto-date/time feature silently creates hidden date tables for every date column, inflating model size and creating extra relationships that can confuse the report layer. Disabling this option forces you to use an explicit date table, giving you control over data type, granularity, and contiguous date ranges, which improves time-intelligence performance and reduces memory footprint.

Using a line chart with OrderDate on the axis and the built-in date hierarchy enables drill-down from year to quarter to month without extra measures or columns. This hierarchy is auto-generated by Power BI for date columns, supports correct chronological sorting, and provides a natural, interactive way for users to explore trends at multiple granularities. The line chart's continuous axis is ideal for showing changes in Amount over time.

This is the canonical star-schema relationship. A single customer can appear in many orders, so Customers is the 'one' side and Orders is the 'many' side. By placing the relationship from Customers to Orders, customer attributes (region, segment, etc.) automatically filter and slice all related order rows, enabling correct aggregations in measures. This relationship uses the dimension table as the lookup table and the fact table as the data table, which is the preferred pattern for performance and intuitive filtering.

Power BI only exposes sensitivity labels that are published through a sensitivity label policy in Microsoft Purview. Creating a label alone is insufficient—the label must be added to a policy that is enabled for Power BI and scoped to the appropriate users or security groups. Without such a policy, the labels remain invisible in the Power BI interface.

Filtering on the IsActive column is a foldable operation for Azure Synapse Analytics, so Power Query can translate it into a WHERE clause in the native query sent to the source. This reduces the rows transferred over the network and satisfies the requirement to filter as close to the source as possible. No source schema change is needed.

Embedding the WHERE clause in a native SQL query lets the source database filter rows before Power Query ingests them, satisfying the stem's requirement to push filtering upstream. This avoids loading the full table and applying the filter locally, which is what causes the slow grouping by ProductID.

DATEDIFF(Orders[OrderDate], Orders[ShipDate], DAY) is correct because the DATEDIFF function in DAX returns the number of interval boundaries crossed between a start date and an end date, with the third argument specifying the interval unit. Here, DAY asks for whole calendar days, so the result is an integer representing the total days from OrderDate to ShipDate. This is the intended calculation for order-to-ship time.

DATESINPERIOD correctly constructs a contiguous range of dates ending at MAX(Date[Date]) and extending backward 12 months using the MONTH interval. This creates a filter context containing approximately 365 days that includes the current month and the preceding 11 months, so the CALCULATE SUM aggregates all sales attributable to that trailing twelve-month window. Because the end date is dynamically determined by the active filter context and the interval is relative, the measure automatically updates as the user selects different time periods, making it the accurate rolling 12-month total.

A calculated table in DAX is materialized in memory when the model is refreshed, meaning its rows and values are stored as static data in the VertiPaq engine. Slicer selections generate a filter context at query time and can only filter visuals over existing rows; they cannot re-execute the table expression for each selection. To make a summary respond to slicers, the aggregation must be defined as a measure or use a dynamic technique such as a disconnected table with measures.

This automates combining files with different structures.

With RLS, you create a role whose DAX filter uses USERPRINCIPALNAME() to identify the current user—for example, filtering a 'Manager' column to match the user's UPN, or using LOOKUPVALUE to return all employees reporting up to that manager. Because USERPRINCIPALNAME() is evaluated per user at query time, a single role dynamically resolves the correct data scope for any manager without per-user configuration. This is the standard pattern for hierarchical or manager-based row-level security.

SAMEPERIODLASTYEAR is a time-intelligence function that returns a table of dates shifted exactly one year back from the current filter context, preserving the same day, month, and quarter boundaries. When used inside CALCULATE, it recalculates a measure over that prior-year date range, making it the precise foundation for a year-over-year growth calculation. Because it respects the current filter context and automatically handles leap years by shifting to the nearest valid date, it is the standard choice for comparing any arbitrary period—month, quarter, or cumulative range—to the same period in the previous year.

Correct. A misconfigured on-premises data source in the Power BI service — such as a gateway data source entry pointing to the wrong server, database, or folder, or using credentials for a different environment — can cause the refresh engine to successfully connect to and load data from an outdated or unintended location. Because the refresh completes without error, the service reports success even though the dataset is populated from the wrong source. This perfectly matches the scenario: a successful refresh that yields stale data.

In Power BI, an active relationship is what enables automatic filter propagation between tables; without one, Power BI cannot traverse from the Sales table to the Regions table to retrieve RegionName. When a foreign key column like RegionID is placed in a visual and no active relationship links it to the Regions table, Power BI simply shows the raw ID value because it has no way to perform the lookup. The correct fix is to create or activate a relationship between Sales[RegionID] and Regions[RegionID] (typically with a single-direction filter), so that the relationship becomes active and the report can display the corresponding RegionName.

Importing all tables into memory and applying an incremental refresh policy to the Sales table to keep only the last 5 years is the correct approach because it reduces the 500M-row table to a manageable subset that leverages the VertiPaq columnstore engine for in-memory aggregations. Incremental refresh uses RangeStart/RangeEnd parameters to filter historical data during each refresh, while keeping the model's date table and time-intelligence functions intact. This delivers fast, consistent performance and satisfies the requirement for a date hierarchy without sacrificing freshness of the most recent data.

When an Azure Blob Storage container is private, Power BI's anonymous (public) access is rejected, so you must authenticate with a credential the storage service actually recognizes. The Azure Blob connector in Power BI supports Account Key authentication as the straightforward shared-key method: supplying the storage account key authorizes your request as the account owner. This grants full access to the container and resolves the 'container is private' error without needing to configure Azure RBAC roles. Use the key from the storage account's Access keys blade in the Azure portal.

This is correct because it uses a composite model to combine DirectQuery and Import modes: DirectQuery on Azure SQL for the current month's sales queries the source directly, providing near real-time visibility without data duplication or refresh latency. Historical sales are imported with incremental refresh, which partitions the data and only loads new or changed partitions, dramatically reducing refresh time and resource use. Customer feedback is imported on an hourly schedule since it does not require sub-hour latency, and SharePoint files are combined via Power Query and imported, as they lack DirectQuery support. This design maximizes performance while meeting all stated latency and freshness requirements, and it is a recognized best practice for hybrid data scenarios in Power BI.