Practice Test #4

Pass (A) is appropriate because the correct transformation sequence is a well-known Power Query pattern for time-series reporting. Correct four actions in order: 1) Use the first row as headers. 2) Unpivot all the columns other than Measure. 3) Rename the Attribute column as Year. 4) Change the data type of the Year column to Date. Why this works: - Promoting headers ensures the year columns are correctly labeled (2016–2020) and the first column is “Measure”. - Unpivot converts multiple year columns into a single Year column (initially called Attribute) plus a Value column, producing a normalized table suitable for visuals over time. - Renaming Attribute to Year makes the semantic meaning clear for modeling. - Setting Year to Date enables proper chronological sorting and supports time intelligence (especially when related to a Date table). Why other actions are wrong: - Transpose is unnecessary and would complicate the shape. - “Use headers as the first row” is the opposite of what you need. - Renaming Measure as Year is incorrect because Measure contains categories, not years.

To keep only managers associated with a sales region, the merge logic must preserve the subset defined by Region_Manager. Using Sales_Region with Region_Manager as a right join keeps all rows from Region_Manager, which are exactly the region-manager assignments that should remain in scope; because the relationship is 1:1, this is equivalent to keeping only matched assigned regions. Merging Region_Manager with Manager by using an inner join adds manager details while excluding managers that are not referenced in Region_Manager. Finally, merging Sales_Manager with Sales_Region by using a left join keeps the Sales_Manager rows that correspond to the already valid Sales_Region rows without relying on extra unmatched Sales_Manager records; options that start from Sales_Manager incorrectly risk retaining rows not tied to a region, and the plain inner-join option between Sales_Region and Sales_Manager is not the intended choice from the provided sequence.

Answer: No. An on-premises data gateway is only required when the Power BI service needs to access a data source that is on-premises or otherwise not reachable from the Power BI service over the public internet. In this scenario (as implied by typical PL-300 hotspot patterns when publishing to powerbi.com), the dataset connects to a cloud-accessible source, so the service can authenticate and refresh without a gateway. Why “Yes” would be wrong: If the data source were SQL Server on-premises, a local file path, or a private network resource, then a gateway would be mandatory for refresh (and for DirectQuery to on-prem sources). But for cloud sources (for example, Azure SQL Database with public endpoint, SharePoint Online, or SaaS), Power BI can connect directly. Exam tip: Always map the source location and network accessibility. Gateway requirement is about network reachability from the Power BI service, not about whether the dataset is published.

Answer: Yes. After publishing an Import-mode dataset to the Power BI service, you typically must configure scheduled refresh if you want the data to stay current automatically. Publishing uploads the model and the imported data snapshot, but it does not automatically set up a refresh cadence. In the service, you configure dataset credentials and then define a refresh schedule (daily/weekly, time slots, time zone, failure notifications, etc.). Why “No” would be wrong: Without scheduled refresh, the dataset will only update when you manually refresh in the service or republish from Power BI Desktop. That does not meet most operational requirements for ongoing reporting. Exam tip: Scheduled refresh is primarily an Import dataset concept. DirectQuery/live connections don’t refresh on a schedule in the same way (they query the source at view time), though they may still require credential configuration and potentially a gateway depending on the source.

Answer: No. Basic authentication is not universally supported in Power BI service for dataset connections and is commonly not the correct choice for modern organizational data sources. Many connectors and enterprise data sources require OAuth2 or Microsoft Entra ID (Azure AD) authentication, and organizations frequently disable Basic auth due to security best practices (credential exposure risk, lack of MFA/conditional access, and weaker governance). Why “Yes” would be wrong: “Basic” might be available for a limited set of sources (for example, some generic web endpoints), but unless the scenario explicitly states a connector/source that supports Basic and that it is permitted, you should not assume it can be used. PL-300 questions typically expect you to choose organizational authentication methods (OAuth/Entra ID) for cloud services. Exam tip: Align authentication with Zero Trust and the Azure Well-Architected Framework security pillar—prefer modern identity-based auth over username/password where possible.

To support RLS, the Sales Employees table should act like a dimension (or security dimension) that filters downstream tables. In a typical model, each employee appears once in Sales Employees (unique EmployeeID/UPN), while the related transactional table contains many rows per employee. That pattern is a one-to-many relationship: Sales Employees on the “one” side and the related table on the “many” side. Why not the others: - One-to-one is uncommon here because a fact/transaction table (like Orders) will have multiple rows per employee. - Many-to-one is just the inverse description; in Power BI you define cardinality, and the correct conceptual direction is dimension (one) to fact (many). - Many-to-many is generally avoided for RLS because it can introduce ambiguous filter propagation and can lead to incorrect or overly permissive results unless additional measures/bridge tables and careful direction settings are used.

The relationship for RLS should connect Sales Employees to the table that contains the employee key used to restrict sales transactions. Among the options, the Orders table is the most appropriate target because it is the core fact table that records sales transactions and typically includes a SalespersonID/EmployeeID column. By relating Sales Employees (dimension/security table) to Orders (fact table), an RLS role that filters Sales Employees (often using USERPRINCIPALNAME() to match the logged-in user) will propagate to Orders and restrict what rows are visible. Why not the others: - Suppliers table is usually unrelated to sales employee security and would not restrict sales transactions correctly. - Order Details is typically a child fact table related to Orders; securing at Orders is cleaner and then flows to Order Details through the Orders relationship. - Customer Details worksheet sounds like a source artifact rather than the correct model fact table for enforcing sales-employee-based RLS.