- How should refresh be configured for this model?
Answer: Schedule a nightly refresh for Targets; DirectQuery requests will retrieve current Sales data when queries run.
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.
- Which design is most appropriate for reducing the duration of recurring refreshes?
Answer: Configure incremental refresh to retain the required history while refreshing only recent partitions, and verify that date filtering folds.
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.
- Which action should a workspace administrator take?
Answer: 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.
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.
- Which sequence of actions should you perform?
Answer: Take over the semantic model, update its data source credentials, and then verify or re-enable scheduled refresh.
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.
- Which change best addresses the cause while providing a maintainable refresh configuration?
Answer: Move the gateway to an always-on computer or server, use standard mode, and configure access to the file-share source.
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.
- What should you do first to restore reliable scheduled refresh?
Answer: Review refresh history for the detailed errors, correct the recurring cause, test a manual refresh, and re-enable the schedule.
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.
- Which configuration and expectation should you recommend?
Answer: Select UTC and schedule 09:00; explain that capacity and service conditions can delay the actual refresh start.
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.
- Which modification is most likely to make the source compatible with scheduled refresh?
Answer: Use a fixed base URL in Web.Contents and pass the varying values through its RelativePath or Query options.
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."
- What should you do to resolve the failure while preserving the enterprise gateway configuration?
Answer: Change the Desktop connection to SQLPROD, republish the semantic model, and map it to the existing gateway connection.
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.
- What should you do to remove the dependency on the analyst's computer?
Answer: Change the query to use the workbook's SharePoint or OneDrive cloud location, republish, and configure its cloud credentials.
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.
