Microsoft Power BI Quiz: Scheduled Refresh
10 questions · exam conditions
0:00
Scheduled RefreshQuestion 1 of 10

A composite semantic model contains an imported Targets table and a DirectQuery Sales table. Targets are revised once each night. Sales transactions must be visible shortly after they are committed to the source system.

How should refresh be configured for this model?

Schedule a nightly refresh for Targets; DirectQuery requests will retrieve current Sales data when queries run.
Schedule an hourly refresh for Sales; imported Targets data will update automatically when the report opens.
Schedule a nightly refresh for both tables; DirectQuery caches cannot retrieve changes between scheduled refreshes.
Disable scheduled refresh for the model; both imported and DirectQuery tables always query their sources at report time.
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Scheduled Refresh

Practice Scheduled Refresh in Microsoft Power BI with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Scheduled Refresh, giving you a quick way to practice the rules, question types, and explanations that matter most for Microsoft Power BI.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A composite semantic model contains an imported Targets table and a DirectQuery Sales table. Targets are revised once each night. Sales transactions must be visible shortly after they are committed to the source system.

How should refresh be configured for this model?

  1. Schedule a nightly refresh for Targets; DirectQuery requests will retrieve current Sales data when queries run. (correct answer)
  2. Schedule an hourly refresh for Sales; imported Targets data will update automatically when the report opens.
  3. Schedule a nightly refresh for both tables; DirectQuery caches cannot retrieve changes between scheduled refreshes.
  4. Disable scheduled refresh for the model; both imported and DirectQuery tables always query their sources at report time.
Explanation: When you see a question about composite models in Power BI, focus on how each storage mode behaves independently — imported tables and DirectQuery tables have fundamentally different refresh mechanics, and understanding both is the key to this question. In a composite model, imported tables store data in Power BI's in-memory cache and require scheduled refresh to pick up changes from the source. DirectQuery tables, by contrast, never cache data — every time a report visual queries a DirectQuery table, Power BI sends a live query directly to the source system. This means DirectQuery Sales data is always current without any scheduled refresh configuration. Since Targets only change nightly, a single nightly scheduled refresh keeps that imported table accurate. This makes A the correct approach: it handles each table according to its actual behavior. B is wrong on two counts — Sales doesn't need a scheduled refresh at all (DirectQuery handles that automatically), and imported Targets data absolutely does not update automatically when a report opens; it requires an explicit refresh. C misunderstands DirectQuery entirely. DirectQuery doesn't use a "cache" in the scheduled-refresh sense — it queries live. Saying it "cannot retrieve changes between refreshes" describes imported mode behavior, not DirectQuery. D is incorrect because imported tables do not query their source at report time. Without a scheduled refresh, the Targets table would remain frozen at whatever data was last loaded, never reflecting nightly updates. A useful rule of thumb: on the PL-300 exam, whenever you see "DirectQuery," remember it's always live — you only schedule refreshes for imported or dual-mode tables.

Question 2

A scheduled refresh has failed on four consecutive nights. The latest notification only states that the refresh was unsuccessful. The semantic model previously refreshed without errors, but its schedule is now inactive.

What should you do first to restore reliable scheduled refresh?

  1. Enable the schedule immediately and add more daily refresh times to compensate for the missed executions.
  2. Review refresh history for the detailed errors, correct the recurring cause, test a manual refresh, and re-enable the schedule. (correct answer)
  3. Republish the unchanged Desktop file so Power BI clears the failure count and recreates the existing schedule.
  4. Convert every imported table to DirectQuery so refresh failures are retried automatically by report queries.
Explanation: When a scheduled refresh fails repeatedly in Power BI, the service automatically disables the schedule after four consecutive failures — a protective mechanism to prevent endless retry loops. Your instinct should be to diagnose before you act: re-enabling a broken schedule without fixing the root cause just restarts the failure cycle. The right approach, captured in B, follows a logical sequence: open the dataset's refresh history (in the Power BI service, navigate to the dataset settings → Refresh history) to read the detailed error messages, which are far more informative than the email notification. Once you identify the cause — an expired gateway credential, a changed data source path, a locked on-premises server — you fix it, then manually trigger a refresh to confirm the fix works before re-enabling the automated schedule. This disciplined order prevents guessing and wasted time. A is a trap: re-enabling the schedule without correcting the underlying error will simply produce four more failures and another automatic disable, plus adding extra refresh times multiplies the failures rather than compensating for missed ones. C misunderstands how republishing works — republishing the Desktop file does not reset a failure count or recreate the schedule in any meaningful way; it can actually break existing dataset settings and gateway mappings. D is a fundamental misunderstanding of DirectQuery: switching to DirectQuery doesn't make scheduled refresh more resilient — imported tables and DirectQuery serve different architectural purposes, and DirectQuery doesn't "auto-retry" anything transparently. For the exam, remember the pattern: diagnose → fix → test manually → re-enable. Power BI questions about refresh failures almost always reward systematic troubleshooting over reactive configuration changes.

Question 3

A global team requires a semantic model refresh to begin at approximately 09:00 UTC every day. The model currently uses a refresh time of 09:00 with the time zone set to Pacific Time. Users also expect the refresh to start at exactly the configured minute.

Which configuration and expectation should you recommend?

  1. Keep Pacific Time and select 09:00; Power BI automatically converts every scheduled time to UTC before displaying it.
  2. Select UTC and schedule 09:00; explain that capacity and service conditions can delay the actual refresh start. (correct answer)
  3. Select the report author's local time and schedule 09:00; refresh always follows the current viewer's regional settings.
  4. Select UTC and schedule 08:45; Power BI guarantees that every scheduled refresh begins exactly 15 minutes later.
Explanation: When configuring scheduled refresh for a global team, the key concept to understand is time zone standardization and refresh reliability expectations. Since teams span multiple regions, using a universal reference point eliminates confusion about when the refresh actually runs. UTC (Coordinated Universal Time) is Power BI's universal time reference, and selecting it directly for scheduling is the clearest, most reliable approach for global teams. When you set the time zone to UTC and schedule 09:00, every team member — regardless of location — shares the same unambiguous reference. Crucially, you must also set the correct expectation: Power BI does not guarantee that a refresh begins at the exact scheduled minute. Capacity load, service queue conditions, and resource availability can introduce delays of several minutes. This is why B is correct — it pairs the right technical configuration (UTC at 09:00) with an honest, accurate expectation about start time variability. A is wrong because Power BI does not automatically convert Pacific Time schedules to a UTC display. The interface shows the time in whatever time zone you configured, and Pacific Time also shifts with Daylight Saving Time, creating seasonal drift that can misalign your 09:00 UTC target by an hour. C is wrong because Power BI refresh scheduling is not viewer-dependent. It is set at the dataset/semantic model level and does not adapt to whoever is currently viewing the report. D is wrong because Power BI makes no guarantee of a refresh starting exactly 15 minutes after any configured offset — that precision simply doesn't exist in the service. Study tip: On Power BI exam questions about scheduled refresh, always pair the correct technical setting with realistic service behavior — Power BI schedules are approximate, not exact.

Question 4

A department uses a personal gateway installed on an analyst's laptop to refresh an imported semantic model from an on-premises file share. Refresh succeeds while the analyst is working but fails overnight. The laptop enters sleep mode after one hour.

Which change best addresses the cause while providing a maintainable refresh configuration?

  1. Move the gateway to an always-on computer or server, use standard mode, and configure access to the file-share source. (correct answer)
  2. Keep the personal gateway on the laptop, add retry times overnight, and increase the semantic model refresh frequency.
  3. Publish a second copy of the report, alternate its schedule with the first, and use the same sleeping gateway.
  4. Store the PBIX file in the workspace, remove the gateway, and let the Power BI service open the on-premises file share.
Explanation: When you see a question about gateway refresh failures tied to specific timing patterns, focus on the root cause: what physical or infrastructure condition explains why failures happen at a predictable time? Here, the laptop sleeps after one hour of inactivity — overnight refreshes fail because the gateway process is suspended. The fix must eliminate that dependency, not work around it. Option A resolves the actual problem. A standard-mode gateway installed on an always-on machine (a server or dedicated workstation) runs continuously as a Windows service, survives unattended hours, and can be centrally managed by IT. Configuring it with access to the file-share source replicates the analyst's setup in a supportable, scalable way. This is the maintainable enterprise solution Power BI is designed around. Option B is a band-aid, not a fix. Adding retry times doesn't help when the gateway process itself is suspended by sleep mode — retries against an offline gateway still fail. Increasing refresh frequency compounds the problem. Option C is nonsensical from an infrastructure standpoint. Publishing a second report copy doesn't keep the laptop awake, and alternating schedules between two reports pointing at the same sleeping gateway doubles nothing except the failure count. Option D misunderstands how the Power BI service works. The cloud service cannot directly reach an on-premises file share — that's exactly why gateways exist. Removing the gateway breaks the connection entirely. As a study tip: on Power BI gateway questions, always distinguish personal mode (single-user, runs only when signed in) from standard mode (service-based, multi-user, always-on). Overnight or unattended refresh scenarios almost always require standard mode on a dedicated machine.

Question 5

An imported fact table contains five years of transactions. Only transactions from the most recent five days can change, but each scheduled refresh reloads the entire table and exceeds the capacity's refresh time limit. The source supports query folding on the transaction-date column.

Which design is most appropriate for reducing the duration of recurring refreshes?

  1. Create a DAX filter for the latest five days so the service stops importing older rows during scheduled refresh.
  2. Add more daily schedule entries so each execution reloads a smaller portion of the imported table automatically.
  3. Enable automatic page refresh on the report so visual queries progressively replace the table's historical rows.
  4. Configure incremental refresh to retain the required history while refreshing only recent partitions, and verify that date filtering folds. (correct answer)
Explanation: When a fact table grows too large for full refreshes, Power BI's incremental refresh feature is the right tool to reach for. The core idea is to partition the table by date so that only recent partitions are refreshed on each cycle, while historical data is retained untouched in older partitions. Option D is correct because incremental refresh directly solves both problems stated in the passage: it limits each refresh to only the five most recent days (matching the business rule), and it preserves the full five years of history in static partitions. The critical detail — that date filtering must fold to the data source — is also addressed in D. Query folding means Power BI pushes the date filter down to the source system as a native query, rather than importing all rows and filtering afterward. Without folding, incremental refresh loses most of its performance benefit. Option A is a common misconception. DAX filters control what visuals display, not what data gets imported during a refresh. A DAX measure cannot prevent rows from being loaded into the model. Option B misunderstands how scheduled refresh works. Adding more schedule entries just triggers more full reloads — it does not make each reload smaller or smarter. This would actually worsen capacity pressure. Option C confuses report-level features with data loading. Automatic page refresh controls how frequently visuals re-query an already-loaded dataset; it has no effect on the import refresh process or table partitioning. Study tip: On Power BI exam questions involving large imported tables and refresh performance, look for the combination of incremental refresh plus query folding — both pieces together are required for the solution to be valid.

Question 6

A user has Viewer access to a workspace and Build permission on a semantic model. The user can create reports from the model but cannot edit its data source credentials or scheduled refresh settings. The current owner is unavailable.

Which action should a workspace administrator take?

  1. Grant the user Reshare permission on the semantic model, because scheduled refresh and credential management are controlled through the model's distribution and sharing settings.
  2. Make the user the owner of the connected report, because refresh configuration for a semantic model is inherited from whichever report was most recently published against it.
  3. Take over the semantic model or assign appropriate workspace rights so an authorized user can take ownership and configure the data source credentials and refresh schedule. (correct answer)
  4. Grant the user access to the refresh-history page, because successfully viewing a completed execution automatically elevates the user's permissions and enables editing of the schedule.
Explanation: Whenever you see a question about semantic model administration in Power BI, focus on ownership and permission boundaries. Editing data source credentials and configuring scheduled refresh are actions tied specifically to semantic model ownership — not general workspace roles or report-level permissions. In Power BI, only the semantic model owner (or a workspace Admin/Member who takes over ownership) can modify credential settings and refresh schedules. A user with Build permission can create reports from a model but cannot touch its backend configuration. When the current owner is unavailable, the correct resolution is exactly what C describes: a workspace administrator must either take over the semantic model directly or assign workspace rights that allow an authorized user to assume ownership. Once ownership transfers, that user gains full control over credentials and refresh settings. A is wrong because Reshare permission controls whether a user can share a dataset with others — it has no bearing on credential management or refresh configuration. These are ownership-level privileges, not distribution settings. B is wrong because refresh configuration for a semantic model is not inherited from any associated report. Report ownership and model ownership are entirely separate concepts in Power BI. Taking ownership of a report does nothing to unlock model-level refresh settings. D is wrong and is a pure fabrication. Viewing the refresh history page is a read-only action and grants no additional permissions whatsoever. No such automatic privilege escalation exists in Power BI. As a study tip, remember this distinction: Build = create content from the model; Ownership = configure the model itself. Questions mixing these two concepts are a common trap on the Power BI exam.

Question 7

A semantic model imports data from an on-premises SQL Server database. An enterprise gateway is online, and a gateway connection exists for server SQLPROD and database SalesDW. The Power BI Desktop file connects to server SQLPROD.contoso.com and database SalesDW. Scheduled refresh reports that no gateway is available for the data source.

What should you do to resolve the failure while preserving the enterprise gateway configuration?

  1. Change the Desktop connection to SQLPROD, republish the semantic model, and map it to the existing gateway connection. (correct answer)
  2. Add the semantic model owner to the SQL Server administrators group, and restart the enterprise gateway service.
  3. Create a second refresh schedule that runs after the gateway connection performs its own scheduled synchronization.
  4. Change the semantic model storage mode to DirectQuery so the service can automatically discover the existing gateway connection.
Explanation: When Power BI Service tries to match a semantic model's data source to a gateway connection, it performs an exact string match on the server and database names. If your Desktop file uses SQLPROD.contoso.com but the gateway connection is registered under SQLPROD, the service sees two different sources — even though they resolve to the same machine — and reports no gateway available. The fix in A is correct because it realigns the server name in the Desktop file to match exactly what the gateway connection expects (SQLPROD), then republishes and explicitly maps the semantic model to that existing connection. No gateway reconfiguration is needed — you're preserving it entirely and simply making the source strings match. B is wrong because the failure is a name-matching issue, not a permissions problem. Adding the model owner to SQL Server admins wouldn't change how Power BI Service identifies gateway connections, and restarting the gateway service doesn't alter its registered data source strings. C is wrong because gateway connections don't have their own "synchronization schedule" that semantic model refreshes need to wait for. This answer invents a concept that doesn't exist in Power BI's gateway architecture. D is wrong because switching to DirectQuery doesn't enable automatic gateway discovery. DirectQuery still requires an explicit, matching gateway connection — and it changes the semantic model's behavior fundamentally, which is far more disruptive than a simple name correction. As a study tip: whenever you see a gateway mismatch scenario on this exam, immediately check whether the server/database name strings are identical between the Desktop source and the gateway connection registration — that's almost always the root cause.

Question 8

A Power Query function builds a web request by concatenating a different full URL for each customer. Refresh works in Power BI Desktop, but the service rejects scheduled refresh because the source is dynamic. Every request uses the same domain and API endpoint; only query-parameter values vary.

Which modification is most likely to make the source compatible with scheduled refresh?

  1. Create a separate refresh schedule for each customer so every execution contains only one dynamically generated URL.
  2. Keep concatenating full URLs, but store the customer values as hidden calculated columns in the semantic model.
  3. Convert the function to a DAX calculated table so the API requests execute after the model refresh is completed.
  4. Use a fixed base URL in Web.Contents and pass the varying values through its RelativePath or Query options. (correct answer)
Explanation: When Power BI service evaluates a data source for scheduled refresh, it checks whether the source URL is "static" enough to apply stored credentials. If Web.Contents receives a fully constructed dynamic string as its first argument, the service cannot reliably identify the base endpoint, so it blocks the refresh — even though Desktop works fine because it evaluates lazily without the same credential-binding check. The fix is to use Web.Contents with a fixed base URL as the first argument, then pass varying values through the RelativePath or Query named options. This tells the Power BI service exactly which domain and endpoint to authenticate against, while still allowing dynamic parameters at refresh time. Option D describes precisely this pattern, making it the correct choice. Option A is a misconception — creating separate schedules doesn't change how the service evaluates the URL structure. You'd still have the same dynamic concatenation problem on every individual run. Option B misunderstands where the issue lives. Hiding customer values as calculated columns in the semantic model doesn't affect how Power Query constructs the web request; the M query still generates a dynamic URL, so the service still rejects it. Option C is a fundamental category error. DAX calculated tables cannot make HTTP requests — they operate on data already loaded into the model. You cannot move web API calls into DAX. As a study tip, remember this pattern: Web.Contents needs a hard-coded first argument for scheduled refresh. Any time you see dynamic URL construction in Power Query, immediately think "move the variable parts into RelativePath or Query options."

Question 9

The owner of a semantic model has left the company. The model imports data from an online service by using OAuth2 credentials associated with that owner. Scheduled refresh now fails with an invalid-credentials message. You are a workspace administrator.

Which sequence of actions should you perform?

  1. Reset the former owner's password, run an on-demand refresh, and then transfer ownership of the refresh schedule.
  2. Take over the semantic model, update its data source credentials, and then verify or re-enable scheduled refresh. (correct answer)
  3. Download and republish the report, delete its gateway mapping, and wait for OAuth2 credentials to renew automatically.
  4. Assign yourself Build permission, edit the report connection, and create a separate schedule under your account.
Explanation: When a semantic model owner leaves an organization, their OAuth2 credentials become orphaned — Power BI can no longer use them for scheduled refresh because those credentials are tied to that specific user identity. The key concept here is semantic model ownership and credential management: whoever owns the model controls which credentials authenticate its data sources. The correct path is B. As a workspace administrator, you can take over the semantic model (transferring ownership to yourself), then update the data source credentials with your own valid OAuth2 credentials, and finally verify that scheduled refresh is still enabled and configured correctly. This directly addresses the root cause — invalid credentials — without unnecessary workarounds. Option A fails because resetting a former employee's password creates a security risk and likely violates company policy. You shouldn't resurrect a departed user's account to fix a technical problem, and "transferring ownership of the refresh schedule" isn't actually a discrete Power BI action — refresh schedules are owned by the model, not scheduled independently. Option C is wrong on multiple levels: republishing the report doesn't fix semantic model credentials, OAuth2 tokens don't "renew automatically" after an owner leaves, and deleting a gateway mapping would break connectivity further rather than restore it. Option D misunderstands the permission model. Build permission allows users to create content from a dataset, but it doesn't grant you the ability to update the model's data source credentials or fix a broken refresh schedule. You need ownership or admin rights, not just Build access. Study tip: On Power BI exam questions involving broken refresh, always trace the problem to its root — usually credentials or ownership — and look for the answer that fixes that root cause directly.

Question 10

A PBIX file imports an Excel workbook through the path C:\Users\Analyst\OneDrive - Contoso\Finance\Budget.xlsx. Both files appear in OneDrive, but the semantic model's scheduled refresh requests a gateway and fails when the analyst's computer is offline.

What should you do to remove the dependency on the analyst's computer?

  1. Keep the local synchronized path and configure the Power BI service to translate it into the corresponding OneDrive URL.
  2. Move only the PBIX file into the same synchronized folder and disable scheduled refresh for the semantic model.
  3. Change the query to use the workbook's SharePoint or OneDrive cloud location, republish, and configure its cloud credentials. (correct answer)
  4. Install a personal gateway for every report consumer so one gateway can access the synchronized workbook during refresh.
Explanation: When a Power BI semantic model connects to a file via a local path (like C:\Users\Analyst\...), the Power BI service treats it as an on-premises data source — even if that folder happens to sync with OneDrive. The service has no visibility into the local file system, so it demands a gateway and depends entirely on that specific machine being online. The fix is to break that local dependency by pointing the query directly at the cloud location. Option C is correct because SharePoint and OneDrive expose files through stable HTTPS URLs that the Power BI service can reach directly, without a gateway. By updating the query source to the workbook's cloud URL, republishing the PBIX, and supplying organizational credentials in the service, scheduled refresh runs entirely in the cloud — no analyst laptop required. Option A is wrong because the Power BI service cannot automatically translate a local synchronized path into a cloud URL. No such translation feature exists; the service simply sees a local path and demands a gateway. Option B is wrong on two counts: moving the PBIX file doesn't change the query's source path, and disabling scheduled refresh defeats the purpose — the business still needs fresh data. Option D is wrong because installing personal gateways for every consumer doesn't eliminate the dependency on the analyst's computer. It multiplies complexity without solving the root problem: the source path still points to a local file. The key pattern to remember: if the file lives in the cloud, the connection string must also point to the cloud. A local sync path always implies a gateway requirement, regardless of where the file ultimately resides.