PL-300 Manage and secure Power BI Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use an on-premises data gateway to connect to Azure SQL.

  Why it's wrong here

  An on-premises data gateway is only required when the data source resides inside a corporate network that Power BI cannot reach directly over the internet, such as an on-premises SQL Server or a file share. Azure SQL Database is a cloud service already accessible to the Power BI service via standard HTTPS connectivity, so adding a gateway introduces unnecessary overhead without affecting refresh timing. The problem described is a scheduling deadline, not a connectivity barrier.

• ✓

  Schedule the refresh to start early enough to complete by 6:00 AM, considering any other scheduled refreshes.

  Why this is correct

  For a dataset in Power BI Premium capacity, you can schedule multiple refreshes per day (up to 48 per dataset), but each refresh must complete before the next one begins, and the service enforces a maximum refresh duration. To ensure data is loaded by 6:00 AM, you need to schedule the start early enough to account for the dataset's expected runtime, any queue time on the capacity, and potential competition from other datasets' refreshes. This directly addresses the core requirement of having fresh data by a specific time.

• ✗

  Configure incremental refresh to reduce the refresh time.

  Why it's wrong here

  Incremental refresh partitions a large table into historical and incremental ranges, so only new or changed rows are loaded instead of the entire dataset. While this can dramatically reduce refresh duration and is a best practice for large fact tables, nothing in the scenario indicates that the dataset is too large or that refresh currently exceeds the allowed time. The core issue is the 6:00 AM deadline; if the refresh already completes quickly but starts too late, incremental refresh will not change the finish time.

• ✗

  Ensure the dataset does not exceed the maximum number of daily refreshes (8 for shared, 48 for Premium).

  Why it's wrong here

  Shared and Premium capacities both restrict the number of scheduled refreshes per dataset per day (8 for shared, 48 for Premium). However, this limit is a quota, not a scheduling guarantee—even if you are well below it, you can still schedule a refresh that finishes after 6:00 AM because the start time is too late. The requirement explicitly mentions the dataset must be loaded by 6:00 AM, which is a time-based constraint rather than a count-based constraint. Respecting the refresh limit does not ensure the deadline is met.

Go deeper

Related to this question