How should I use these Deploy and maintain assets practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

Can I practise just Deploy and maintain assets questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Deploy and maintain assets domain.

PL-300 · topic practice

Deploy and maintain assets practice questions

Practise Microsoft Power BI Data Analyst PL-300 Deploy and maintain assets practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Reviewed byJohnson Ajibi· MSc IT Security

20 questionsDomain: Deploy and maintain assets

Practice 10 questions Browse domain →

What the exam tests

What to know about Deploy and maintain assets

Deploy and maintain assets questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Watch out for

Common Deploy and maintain assets exam traps

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Practice set

Deploy and maintain assets questions

20 questions · select your answer, then reveal the explanation

Question 1hardmultiple choice

Read the full Deploy and maintain assets explanation →

Your Power BI dataset uses DirectQuery to an Azure SQL Database. Users complain that the report is slow. You need to improve query performance without changing the data source. What should you do?

Trap 1: Add more visuals to the report to distribute the load.

Adding more visuals does not spread the query workload; it multiplies it, because each visual issues its own DirectQuery query and Power BI may run them concurrently against Azure SQL. This can create connection pool contention and increase CPU and I/O on the source database, making performance worse, not better. To reduce load, you should consolidate visuals or use fewer, not add more.

Trap 2: Increase the scheduled refresh frequency.

DirectQuery does not use scheduled refresh—the dataset is not cached and every interaction queries Azure SQL live, so refreshing an Import-mode cache has no bearing on DirectQuery query performance. Increasing refresh frequency would only matter if you had switched to Import mode, and even then it updates cached data, not the speed of queries against it. For DirectQuery, the lever is reducing source-side work (indexes, query folding), not refresh cadence.

Study all Deploy and maintain assets common traps →

A
Reduce the number of columns and rows retrieved by the report visuals.
Each DirectQuery visual translates to a query sent to the Azure SQL database, so reducing the columns selected and rows filtered at the source directly cuts the data scanned, transferred, and processed. Pruning columns (avoiding SELECT *) and applying filters or page-level slicers lets the engine push down more work to SQL Server via query folding, which lowers load and improves visual response time. This is the foundational DirectQuery optimization.
B
Add more visuals to the report to distribute the load.
Why wrong: Adding more visuals does not spread the query workload; it multiplies it, because each visual issues its own DirectQuery query and Power BI may run them concurrently against Azure SQL. This can create connection pool contention and increase CPU and I/O on the source database, making performance worse, not better. To reduce load, you should consolidate visuals or use fewer, not add more.
C
Switch the dataset to Import mode.
Switching the dataset to Import mode would eliminate DirectQuery queries during report interaction because data is cached in memory, but that is an architectural change rather than a DirectQuery tuning technique; it abandons the real-time querying that DirectQuery provides and introduces separate refresh scheduling and potential data freshness staleness. In a question focused on improving DirectQuery performance, the goal is to optimize the live queries, not replace the connectivity mode.
D
Increase the scheduled refresh frequency.
Why wrong: DirectQuery does not use scheduled refresh—the dataset is not cached and every interaction queries Azure SQL live, so refreshing an Import-mode cache has no bearing on DirectQuery query performance. Increasing refresh frequency would only matter if you had switched to Import mode, and even then it updates cached data, not the speed of queries against it. For DirectQuery, the lever is reducing source-side work (indexes, query folding), not refresh cadence.

Full breakdown with real-world context →

Question 2hardmultiple choice

Read the full Deploy and maintain assets explanation →

You have a Power BI dataset that is refreshed every hour from an on-premises data source using an enterprise gateway. The refresh consistently fails at 2:00 AM. What is the most likely cause?

Trap 1: The refresh is failing due to a transient network error.

Transient network errors are unpredictable and intermittent by nature, so they would not produce a failure at exactly 2:00 AM every day. Power BI also performs automatic retries for transient connectivity issues, and a short-lived network blip would typically self-resolve on a subsequent attempt. A consistently timed failure points to a scheduled or persistent cause, not a random, transient condition.

Trap 2: The data source is undergoing maintenance in the cloud.

The data source is on-premises, so maintenance in the cloud would not affect the connection to an on-premises server. Cloud maintenance would impact cloud-based services, not the gateway's ability to reach a local data source. This option fundamentally misunderstands the architecture: the gateway bridges Power BI to on-premises resources, and any source-side maintenance must occur on-premises to matter.

Trap 3: The scheduled refresh time conflicts with another refresh.

A conflicting refresh does not cause a hard failure; the Power BI service queues overlapping refresh requests for the same dataset rather than canceling them. The conflict would produce a 'queued' or delayed status, not a consistent error at the same time every day. Since the failure is recurring and time-specific, a queuing issue is an incorrect explanation.

Study all Deploy and maintain assets common traps →

A
The on-premises data gateway is scheduled to reboot at 2:00 AM.
A scheduled gateway reboot at 2:00 AM would make the on-premises data gateway temporarily unavailable, so the 2:00 AM refresh cannot connect to the data source. Because the reboot recurs daily at the same time, the refresh failure is consistent and deterministic, matching the symptom. The gateway is a required bridge between the Power BI service and on-premises sources, so if it is offline during the scheduled window, the refresh fails every time.
B
The refresh is failing due to a transient network error.
Why wrong: Transient network errors are unpredictable and intermittent by nature, so they would not produce a failure at exactly 2:00 AM every day. Power BI also performs automatic retries for transient connectivity issues, and a short-lived network blip would typically self-resolve on a subsequent attempt. A consistently timed failure points to a scheduled or persistent cause, not a random, transient condition.
C
The data source is undergoing maintenance in the cloud.
Why wrong: The data source is on-premises, so maintenance in the cloud would not affect the connection to an on-premises server. Cloud maintenance would impact cloud-based services, not the gateway's ability to reach a local data source. This option fundamentally misunderstands the architecture: the gateway bridges Power BI to on-premises resources, and any source-side maintenance must occur on-premises to matter.
D
The scheduled refresh time conflicts with another refresh.
Why wrong: A conflicting refresh does not cause a hard failure; the Power BI service queues overlapping refresh requests for the same dataset rather than canceling them. The conflict would produce a 'queued' or delayed status, not a consistent error at the same time every day. Since the failure is recurring and time-specific, a queuing issue is an incorrect explanation.

Full breakdown with real-world context →

Question 3mediummulti select

Read the full Deploy and maintain assets explanation →

Which TWO actions should you take to ensure that a Power BI report deployed to production is available to users even if the gateway is offline for maintenance?

Trap 1: Create a Power BI Premium capacity to ensure high availability.

Power BI Premium capacity provides dedicated resources and high availability for the Power BI service, but it does not eliminate the dependency on an on-premises data gateway for sources in a private network. During gateway maintenance, scheduled refreshes will still fail because the gateway is unavailable. Premium capacity does not offer a gateway failover path or proxy for on-premises connectivity, so this action alone cannot ensure refresh continuity.

Trap 2: Schedule the dataset refresh to run during the maintenance window.

Scheduling the dataset refresh to run during the maintenance window assumes the gateway will be back online, but the gateway is exactly what is being maintained and may be stopped or restarted at that time. If the gateway is offline, the refresh connection to the on-premises source cannot be established, and the job will fail. Simply changing the schedule does not address the root cause of gateway unavailability.

Trap 3: Use DirectQuery instead of Import mode to avoid gateway dependency.

DirectQuery mode does not avoid the gateway dependency; in fact, it makes it worse because every user query against the on-premises source must go through the gateway at query time. This means during gateway maintenance, users will be unable to load report data at all, whereas Import mode at least benefits from the cached data that was last refreshed. DirectQuery removes the cached layer that could provide resilience during the maintenance window.

Study all Deploy and maintain assets common traps →

A
Create a Power BI Premium capacity to ensure high availability.
Why wrong: Power BI Premium capacity provides dedicated resources and high availability for the Power BI service, but it does not eliminate the dependency on an on-premises data gateway for sources in a private network. During gateway maintenance, scheduled refreshes will still fail because the gateway is unavailable. Premium capacity does not offer a gateway failover path or proxy for on-premises connectivity, so this action alone cannot ensure refresh continuity.
B
Schedule the dataset refresh to run during the maintenance window.
Why wrong: Scheduling the dataset refresh to run during the maintenance window assumes the gateway will be back online, but the gateway is exactly what is being maintained and may be stopped or restarted at that time. If the gateway is offline, the refresh connection to the on-premises source cannot be established, and the job will fail. Simply changing the schedule does not address the root cause of gateway unavailability.
C
Use DirectQuery instead of Import mode to avoid gateway dependency.
Why wrong: DirectQuery mode does not avoid the gateway dependency; in fact, it makes it worse because every user query against the on-premises source must go through the gateway at query time. This means during gateway maintenance, users will be unable to load report data at all, whereas Import mode at least benefits from the cached data that was last refreshed. DirectQuery removes the cached layer that could provide resilience during the maintenance window.
D
Create a separate dataset in the cloud that caches the data.
Creating a separate dataset in the cloud that caches the data decouples the user-facing reports from the live on-premises connection. The cloud dataset is refreshed via the gateway when it is online, and once cached in the Power BI service, it can be accessed without any gateway dependency. During gateway maintenance, reports keep working against the cached dataset because queries are served directly from the cloud. This provides a practical way to ensure availability while the gateway is down.
E
Implement a disaster recovery plan that includes a secondary gateway.
A disaster recovery plan that includes a secondary gateway provides redundancy by allowing the refresh workload to fail over to another gateway when the primary one is unavailable. The secondary gateway can be set up as a member of an on-premises data gateway cluster, enabling automatic failover if the primary gateway goes offline during maintenance. This ensures scheduled refresh jobs can still reach the on-premises data source, maintaining business continuity.

Full breakdown with real-world context →

Question 4hardmulti select

Read the full Deploy and maintain assets explanation →

Which THREE steps should you perform to deploy a Power BI solution from development to production using deployment pipelines?

Trap 1: Create a new workspace manually in production.

In Power BI Deployment Pipelines, workspaces are automatically created and assigned to pipeline stages (Development, Test, Production) when you set up the pipeline. Manually creating a production workspace defeats the purpose of the pipeline's managed deployment process, because the pipeline enforces consistency and tracks lineage across stages. If you manually create a workspace outside the pipeline, you lose features like deployment rules, selective deployment, and back-in-time review, and you must handle data source updates and permissions manually. The correct approach is to let the pipeline create or connect to the production workspace as part of its stage setup.

Trap 2: Assign Power BI Pro licenses to all developers.

While Power BI Pro or Premium Per User (PPU) licenses are a prerequisite for using Deployment Pipelines (pipelines are only available to Pro/PPU users), license assignment itself is not a deployment step. The deployment workflow is about moving content through pipeline stages, configuring rules, and validating in test environments. License provisioning is an admin/tenant-level prerequisite, not part of the operational deployment process. Additionally, end users viewing reports in production might need Pro or Free licenses depending on the workspace's Premium capacity, but again that is separate from the pipeline deployment action.

Study all Deploy and maintain assets common traps →

A
Create a new workspace manually in production.
Why wrong: In Power BI Deployment Pipelines, workspaces are automatically created and assigned to pipeline stages (Development, Test, Production) when you set up the pipeline. Manually creating a production workspace defeats the purpose of the pipeline's managed deployment process, because the pipeline enforces consistency and tracks lineage across stages. If you manually create a workspace outside the pipeline, you lose features like deployment rules, selective deployment, and back-in-time review, and you must handle data source updates and permissions manually. The correct approach is to let the pipeline create or connect to the production workspace as part of its stage setup.
B
Set up deployment pipeline rules to modify parameters (e.g., database name).
Deployment rules in Power BI Deployment Pipelines allow you to define stage-specific values for parameters (like database server or database name), data source connections, and model parameters. When content is deployed from Development to Test or Production, these rules automatically override the source values, ensuring each environment points to its own data sources without manual edit. This is essential because raw content in Development likely references development data sources; without rules, the deployed report would incorrectly connect to dev. Rules are configured per stage and can target datasets, reports, paginated reports, and even dataflows.
C
Assign Power BI Pro licenses to all developers.
Why wrong: While Power BI Pro or Premium Per User (PPU) licenses are a prerequisite for using Deployment Pipelines (pipelines are only available to Pro/PPU users), license assignment itself is not a deployment step. The deployment workflow is about moving content through pipeline stages, configuring rules, and validating in test environments. License provisioning is an admin/tenant-level prerequisite, not part of the operational deployment process. Additionally, end users viewing reports in production might need Pro or Free licenses depending on the workspace's Premium capacity, but again that is separate from the pipeline deployment action.
D
Deploy content from development to test, then to production.
Deployment Pipelines enforce a sequential, staged deployment model: you first develop content in the Development workspace, then deploy to the Test workspace for validation (e.g., with business users or QA), and finally deploy to the Production workspace for end users. This order mirrors the software development lifecycle and ensures that only validated content reaches production. You can perform a full deployment (all items) or selectively deploy specific items, but you cannot skip a stage—the pipeline's deployment action goes from a source stage to a target stage in linear order (e.g., Test to Production). This sequential rollout minimizes risk and provides a clear approval point before exposing changes to the entire organization.
E
Create a development workspace and add content.
The pipeline's first stage, Development, is the workspace where content authors build datasets, reports, dashboards, and dataflows. You must create or assign a workspace to this stage before any deployment can occur—without content in Development, there is nothing to promote. Development workspaces are typically connected to a data source (like a SQL database) that may store configuration settings; these are later parameterized using deployment rules. This initial step is foundational because all subsequent deployments and rules operate on the items you add here, and it is the only stage where you freely build and edit content.

Full breakdown with real-world context →

Question 5easymultiple choice

Read the full Deploy and maintain assets explanation →

You review the dataset refresh history. The second refresh took 30 minutes and failed. What is the most likely reason for the failure?

Exhibit

Refer to the exhibit.

Dataset Refresh History:
Refresh #1: Start: 2024-01-15 01:00:00, End: 2024-01-15 01:05:00, Status: Completed
Refresh #2: Start: 2024-01-15 02:00:00, End: 2024-01-15 02:30:00, Status: Failed
Refresh #3: Start: 2024-01-15 03:00:00, End: 2024-01-15 03:03:00, Status: Completed

Trap 1: The refresh schedule conflicted with another refresh.

A refresh schedule conflict would only happen if another refresh job were actively running on the same dataset at the same time, forcing Power BI to queue or abort the second one with a 'refresh already in progress' error. Since the refresh history shows no other refresh was running at 2:00 AM, there was no scheduling contention. Thus, this is not a plausible cause of the failure.

Trap 2: The on-premises data gateway was offline.

If the on-premises data gateway were offline, every refresh that depends on it would fail with an error like 'GatewayNotReachable' or 'Unable to connect to gateway' across all datasets. Since other refreshes succeeded in the same time window, the gateway was online and accepting connections. A gateway outage is therefore not the cause of this particular refresh failure.

Trap 3: The data source was unavailable.

A data source unavailability error typically manifests as a connection failure or authentication failure, such as 'Cannot connect to server' or 'Database is not available.' Because other refreshes connected to the same source succeeded during the same period, the source was reachable and credentials were valid. This rules out data source availability as the explanation for the timeout-related failure.

Study all Deploy and maintain assets common traps →

A
The refresh schedule conflicted with another refresh.
Why wrong: A refresh schedule conflict would only happen if another refresh job were actively running on the same dataset at the same time, forcing Power BI to queue or abort the second one with a 'refresh already in progress' error. Since the refresh history shows no other refresh was running at 2:00 AM, there was no scheduling contention. Thus, this is not a plausible cause of the failure.
B
The on-premises data gateway was offline.
Why wrong: If the on-premises data gateway were offline, every refresh that depends on it would fail with an error like 'GatewayNotReachable' or 'Unable to connect to gateway' across all datasets. Since other refreshes succeeded in the same time window, the gateway was online and accepting connections. A gateway outage is therefore not the cause of this particular refresh failure.
C
The refresh exceeded the timeout limit set in the gateway.
The on-premises data gateway imposes a configurable timeout limit on each refresh operation, with a default of two hours in many environments. When a dataset refresh runs longer than that limit, the gateway terminates the operation and logs a timeout error, even if the data source is healthy and the query is still progressing. Given the long refresh duration and the specific failure pattern, exceeding the gateway timeout is the most likely cause.
D
The data source was unavailable.
Why wrong: A data source unavailability error typically manifests as a connection failure or authentication failure, such as 'Cannot connect to server' or 'Database is not available.' Because other refreshes connected to the same source succeeded during the same period, the source was reachable and credentials were valid. This rules out data source availability as the explanation for the timeout-related failure.

Full breakdown with real-world context →

Question 6mediummultiple choice

Read the full Deploy and maintain assets explanation →

You are troubleshooting connectivity to a Power BI Premium dataset via the XMLA endpoint. A user reports that they cannot connect using SQL Server Management Studio (SSMS) but can view reports in the Power BI service. The user's email is user3@contoso.com. What is the most likely cause?

Exhibit

Refer to the exhibit.

Power BI XMLA endpoint configuration:
{
  "allowedUsers": [
    "user1@contoso.com",
    "user2@contoso.com"
  ],
  "allowAzureAnalysisServicesConnections": true,
  "blockExternalConnections": false
}

Trap 1: External connections are blocked by the configuration.

External connections are not the source of the problem because the `blockExternalConnections` property is explicitly set to false, meaning external applications are permitted to access the capacity. The XMLA endpoint enforces its own access control list (allowedUsers) that is independent of that external-connection setting. Since the endpoint allows external traffic, the failed connection must be due to a more granular authorization rule, not a blanket block on external connections.

Trap 2: The user does not have permission to view reports.

The user already has the ability to view reports, which demonstrates they hold at least read permission on the relevant workspace and the underlying dataset in the Power BI service. However, XMLA connectivity is governed by a separate authorization layer defined by the capacity administrator, not by report-level permissions. Therefore, the user's report-viewing permission is irrelevant to the XMLA endpoint's authentication and authorization process, making this an incorrect explanation for the connection failure.

Trap 3: The XMLA endpoint is disabled.

The XMLA endpoint is configured as enabled in the capacity settings, so it is actively accepting connections at the protocol level. If the endpoint were disabled, every connection attempt would fail, but the problem is isolated to a specific user, which indicates a per-user authorization issue rather than a global switch. The configuration confirms the endpoint is on, so this option incorrectly identifies the failure mechanism.

Study all Deploy and maintain assets common traps →

A
External connections are blocked by the configuration.
Why wrong: External connections are not the source of the problem because the `blockExternalConnections` property is explicitly set to false, meaning external applications are permitted to access the capacity. The XMLA endpoint enforces its own access control list (allowedUsers) that is independent of that external-connection setting. Since the endpoint allows external traffic, the failed connection must be due to a more granular authorization rule, not a blanket block on external connections.
B
The user does not have permission to view reports.
Why wrong: The user already has the ability to view reports, which demonstrates they hold at least read permission on the relevant workspace and the underlying dataset in the Power BI service. However, XMLA connectivity is governed by a separate authorization layer defined by the capacity administrator, not by report-level permissions. Therefore, the user's report-viewing permission is irrelevant to the XMLA endpoint's authentication and authorization process, making this an incorrect explanation for the connection failure.
C
The user is not in the allowedUsers list for the XMLA endpoint.
This is the correct explanation because the XMLA endpoint's access is explicitly restricted through the `allowedUsers` list, which contains only user1 and user2. This list is the primary authorization gatekeeper for XMLA connections, and a user who is not listed will receive a connection error even if they have valid credentials and report permissions. Since the user is absent from that list, their attempt to reach the dataset via the XMLA endpoint is rightfully rejected.
D
The XMLA endpoint is disabled.
Why wrong: The XMLA endpoint is configured as enabled in the capacity settings, so it is actively accepting connections at the protocol level. If the endpoint were disabled, every connection attempt would fail, but the problem is isolated to a specific user, which indicates a per-user authorization issue rather than a global switch. The configuration confirms the endpoint is on, so this option incorrectly identifies the failure mechanism.

Full breakdown with real-world context →

Question 7mediummultiple choice

Read the full Deploy and maintain assets explanation →

You deploy a Power BI app to a workspace with an app-only license (Premium Per User). Users report that they can access the app but cannot see any visuals in the reports. The dataset uses Import mode. What is the most likely issue?

Trap 1: The report uses DirectQuery and the data source is offline.

In DirectQuery mode, every visual sends a live query to the data source. When that source is offline, Power BI cannot retrieve data and displays a clear error message, such as 'Cannot connect to the data source' or a warning icon, directly on each affected visual. The visual containers and report layout remain intact, so users would see explicit connectivity failures rather than completely blank visuals.

Trap 2: The report is published to a shared dataset that has been deleted.

When a report references a published shared dataset that has been deleted, Power BI cannot resolve the dataset reference. The report canvas will display an error such as 'Unable to connect to the dataset' or 'We couldn't find the dataset' on every visual. This is a broken, error-ridden state, not a blank absence of visuals, because the visual objects still exist on the page but are not connected to any data source.

Trap 3: The dataset has row-level security (RLS) that filters all rows for…

Row-level security (RLS) never hides visual objects from the report layout; it only restricts the rows of data returned to the user. If RLS filters out every row, the visuals will still be present on the page and will show empty axes, blank tables, or a 'No data' indicator. Since the reported issue involves visuals entirely missing rather than visuals rendering with no data, RLS cannot be the root cause.

Study all Deploy and maintain assets common traps →

A
The report uses DirectQuery and the data source is offline.
Why wrong: In DirectQuery mode, every visual sends a live query to the data source. When that source is offline, Power BI cannot retrieve data and displays a clear error message, such as 'Cannot connect to the data source' or a warning icon, directly on each affected visual. The visual containers and report layout remain intact, so users would see explicit connectivity failures rather than completely blank visuals.
B
The users do not have a Premium Per User license assigned.
Premium Per User (PPU) is a per-user licensing tier that controls access to content residing in PPU-backed workspaces. Without a PPU license assigned to each user, the Power BI service cannot execute the semantic model queries that feed the report visuals. In app or embedded scenarios, this often manifests as visual objects that fail to render, leaving a blank canvas, even though the app shell and navigation are visible.
C
The report is published to a shared dataset that has been deleted.
Why wrong: When a report references a published shared dataset that has been deleted, Power BI cannot resolve the dataset reference. The report canvas will display an error such as 'Unable to connect to the dataset' or 'We couldn't find the dataset' on every visual. This is a broken, error-ridden state, not a blank absence of visuals, because the visual objects still exist on the page but are not connected to any data source.
D
The dataset has row-level security (RLS) that filters all rows for these users.
Why wrong: Row-level security (RLS) never hides visual objects from the report layout; it only restricts the rows of data returned to the user. If RLS filters out every row, the visuals will still be present on the page and will show empty axes, blank tables, or a 'No data' indicator. Since the reported issue involves visuals entirely missing rather than visuals rendering with no data, RLS cannot be the root cause.

Full breakdown with real-world context →

Question 8hardmultiple choice

Read the full Deploy and maintain assets explanation →

You manage a Power BI deployment that uses deployment pipelines. After promoting content from Development to Test, you notice that the Test workspace dataset uses a different data source than expected. What is the most likely reason?

Trap 1: The pipeline didn't deploy the dataset because it was already in…

A deployment pipeline does not check whether an item already exists in the target workspace and then decide to skip it; every deployment copies all selected items from the source stage to the target stage and overwrites matching artifacts. Even if the Test workspace already contained a dataset with the same name, the pipeline would replace it with the version from the source stage. Thus, 'already in Test' would never prevent a dataset from being deployed.

Trap 2: The data source credentials were not applied during deployment.

Data source credentials are stored as workspace-level datasource settings and are not part of the deployment pipeline's content payload, so they cannot change a dataset's connection path. The symptom of a wrong data source points to the dataset's server/database properties, which are controlled by dataset parameters. Configuring credentials would only authenticate against whatever source the dataset already references; it would not redirect the dataset to the Test environment's data source.

Trap 3: The Test workspace has a separate dataset that was manually created.

A manually created dataset in the Test workspace would be overwritten during a pipeline deployment, because the pipeline pushes the source item and replaces the target item of the same name. The presence of a separate dataset does not stop deployment or cause the deployed dataset to connect to the wrong server. This explanation confuses an unrelated workspace artifact with the actual root cause, which is a parameter configuration gap in the pipeline rules.

Study all Deploy and maintain assets common traps →

A
The pipeline didn't deploy the dataset because it was already in Test.
Why wrong: A deployment pipeline does not check whether an item already exists in the target workspace and then decide to skip it; every deployment copies all selected items from the source stage to the target stage and overwrites matching artifacts. Even if the Test workspace already contained a dataset with the same name, the pipeline would replace it with the version from the source stage. Thus, 'already in Test' would never prevent a dataset from being deployed.
B
The data source credentials were not applied during deployment.
Why wrong: Data source credentials are stored as workspace-level datasource settings and are not part of the deployment pipeline's content payload, so they cannot change a dataset's connection path. The symptom of a wrong data source points to the dataset's server/database properties, which are controlled by dataset parameters. Configuring credentials would only authenticate against whatever source the dataset already references; it would not redirect the dataset to the Test environment's data source.
C
The dataset parameters were not configured in the deployment pipeline rules.
Dataset parameters, such as server name or database name, can be overridden per stage using deployment pipeline rules. If no rule is configured for the relevant parameter, Test inherits the parameter values from Development, causing the dataset to keep pointing to the Dev data source. Creating a parameter rule that assigns the Test SQL server/database value for that parameter is the required fix. Without this rule, the pipeline will successfully deploy the dataset but still reference the wrong environment.
D
The Test workspace has a separate dataset that was manually created.
Why wrong: A manually created dataset in the Test workspace would be overwritten during a pipeline deployment, because the pipeline pushes the source item and replaces the target item of the same name. The presence of a separate dataset does not stop deployment or cause the deployed dataset to connect to the wrong server. This explanation confuses an unrelated workspace artifact with the actual root cause, which is a parameter configuration gap in the pipeline rules.

Full breakdown with real-world context →

Question 9hardmulti select

Read the full Deploy and maintain assets explanation →

Which THREE factors should you consider when planning the deployment of Power BI content to a large enterprise with multiple regions?

Trap 1: The number of visuals per report page.

The number of visuals per report page is a report design and performance consideration, not a deployment planning factor. While too many visuals can degrade rendering speed and interactivity, it does not affect where the report is published, how data is stored, or what infrastructure is required. Deployment planning focuses on capacity, gateways, and data residency, not the composition of a single page.

Trap 2: The currency format used in reports for each region.

Currency format is a localization concern that is handled at the report or data model level, not during deployment. Power BI can automatically format currencies based on the report consumer's locale or through dynamic format strings, but whether a report displays euros or dollars has no bearing on server placement, region selection, or data residency compliance. Therefore, it should not be considered when planning the deployment infrastructure across regions.

Study all Deploy and maintain assets common traps →

A
Data residency requirements for each region.
Data residency requirements must be evaluated first when planning a regional Power BI deployment. Compliance regulations, such as GDPR or India's data localization rules, mandate that data remains within specific geographic boundaries, which determines the home region for the Power BI service or the location of dedicated capacity. Even if the tenant is global, the placement of capacities and workspaces must align with these legal obligations, and this directly influences whether multi-region or single-region architectures are viable.
B
The number of visuals per report page.
Why wrong: The number of visuals per report page is a report design and performance consideration, not a deployment planning factor. While too many visuals can degrade rendering speed and interactivity, it does not affect where the report is published, how data is stored, or what infrastructure is required. Deployment planning focuses on capacity, gateways, and data residency, not the composition of a single page.
C
The currency format used in reports for each region.
Why wrong: Currency format is a localization concern that is handled at the report or data model level, not during deployment. Power BI can automatically format currencies based on the report consumer's locale or through dynamic format strings, but whether a report displays euros or dollars has no bearing on server placement, region selection, or data residency compliance. Therefore, it should not be considered when planning the deployment infrastructure across regions.
D
The use of deployment pipelines to promote content between regions.
Deployment pipelines are a feature used to manage the content lifecycle by moving reports, dashboards, and datasets across development, test, and production workspaces. When planning multi-region deployments, pipelines can be leveraged to promote content between workspaces in different regions or to apply different parameters and data source connections per stage. This makes them a critical tool for ensuring consistent and controlled release management across geographically distributed environments.
E
The location and performance of on-premises data gateways.
On-premises data gateways bridge Power BI service to on-premises data sources for scheduled refreshes and DirectQuery. The gateway location and performance are important deployment factors because refresh speed and latency depend on network proximity to both the data source and Power BI region, and gateway availability requires proper setup in each region. In a multi-region deployment, you may need to install and manage multiple gateways in different locations to ensure reliable and timely data refresh.

Full breakdown with real-world context →

Question 10easymultiple choice

Read the full Deploy and maintain assets explanation →

A company publishes a Power BI dataset to the service. They need to ensure that when the underlying data source is updated, the dataset refreshes automatically within 30 minutes. The data source is an on-premises SQL Server database. Which component must be configured to enable this automatic refresh?

Trap 1: Publish the dataset with incremental refresh enabled

Incremental refresh optimizes refresh performance but still requires a gateway for on-premises sources.

Trap 2: Change the dataset storage mode to DirectQuery

DirectQuery does not use scheduled refresh; it queries the source directly on each interaction.

Trap 3: Enable the XMLA endpoint for the workspace

The XMLA endpoint allows programmatic management but does not automate refresh scheduling.

Study all Deploy and maintain assets common traps →

A
Publish the dataset with incremental refresh enabled
Why wrong: Incremental refresh optimizes refresh performance but still requires a gateway for on-premises sources.
B
Change the dataset storage mode to DirectQuery
Why wrong: DirectQuery does not use scheduled refresh; it queries the source directly on each interaction.
C
Install and configure an on-premises data gateway
The gateway enables Power BI to connect to on-premises data sources for scheduled refresh.
D
Enable the XMLA endpoint for the workspace
Why wrong: The XMLA endpoint allows programmatic management but does not automate refresh scheduling.

Full breakdown with real-world context →

Question 11hardmultiple choice

Read the full Deploy and maintain assets explanation →

A Power BI administrator reviews the JSON configuration for a dataset named SalesDataset. The dataset is deployed to a Premium capacity workspace. The data source is an on-premises SQL Server. The administrator notices that the dataset has never refreshed successfully. Based on the exhibit, what is the most likely cause of the refresh failure?

Exhibit

Refer to the exhibit.

```json
{
  "dataset": {
    "name": "SalesDataset",
    "defaultMode": "Push",
    "refreshSchedule": {
      "enabled": true,
      "frequency": "Weekly",
      "days": ["Monday"],
      "times": ["02:00"]
    },
    "dataSources": [
      {
        "type": "Sql",
        "connectionString": "Server=sqlserver01;Database=SalesDB;Integrated Security=SSPI"
      }
    ]
  }
}
```

Trap 1: The refresh schedule specifies a frequency of Weekly, but the time…

The weekly schedule would still trigger the refresh job; the time zone setting only shifts the precise execution time from the user's local wall clock to its UTC equivalent. If the administrator intended a specific local hour, the refresh runs at the wrong clock time, but the job is not blocked or failed because of that. It is a configuration mistake, not a technical constraint, so it cannot explain a complete failure of scheduled refresh.

Trap 2: The dataset uses Integrated Security in the connection string,…

Integrated Security, also known as Windows authentication, is supported for scheduled refresh when the dataset uses an on-premises data gateway that stores the Windows account credentials. Without a gateway or with improperly mapped credentials, the refresh may fail, but the authentication mode itself is not inherently unsupported by Power BI's refresh engine. For cloud data sources, alternative authentication types are required, yet the statement as written is factually incorrect, so this option cannot be the correct cause.

Trap 3: The dataset is in a Premium capacity workspace, which does not…

Premium capacity workspaces support scheduled refresh and actually lift the refresh frequency limit to up to 48 times a day, so the workspace type is not the problem. For on-premises data sources, the only requirement is that a gateway is installed and the data source credentials are configured correctly in the dataset's settings. Since Premium does not block refresh, this option is factually wrong and cannot be the reason the configuration review flagged a failure.

Study all Deploy and maintain assets common traps →

A
The refresh schedule specifies a frequency of Weekly, but the time is in UTC and not adjusted for the local time zone
Why wrong: The weekly schedule would still trigger the refresh job; the time zone setting only shifts the precise execution time from the user's local wall clock to its UTC equivalent. If the administrator intended a specific local hour, the refresh runs at the wrong clock time, but the job is not blocked or failed because of that. It is a configuration mistake, not a technical constraint, so it cannot explain a complete failure of scheduled refresh.
B
The dataset uses Integrated Security in the connection string, which is not supported for scheduled refresh
Why wrong: Integrated Security, also known as Windows authentication, is supported for scheduled refresh when the dataset uses an on-premises data gateway that stores the Windows account credentials. Without a gateway or with improperly mapped credentials, the refresh may fail, but the authentication mode itself is not inherently unsupported by Power BI's refresh engine. For cloud data sources, alternative authentication types are required, yet the statement as written is factually incorrect, so this option cannot be the correct cause.
C
The dataset's defaultMode is set to Push, which does not support scheduled refresh
A dataset whose defaultMode is Push is designed for real-time streaming through the Power BI REST API, where rows are appended to an in-memory cache without any underlying data source connection. Because there is no connected source to re-query, the refresh engine has nothing to run, and Power BI explicitly does not allow scheduled refresh on Push datasets. Instead, data must be updated by pushing new rows via the Push API, making the refresh schedule irrelevant and rendering this the correct explanation for the failure.
D
The dataset is in a Premium capacity workspace, which does not support scheduled refresh for on-premises data sources
Why wrong: Premium capacity workspaces support scheduled refresh and actually lift the refresh frequency limit to up to 48 times a day, so the workspace type is not the problem. For on-premises data sources, the only requirement is that a gateway is installed and the data source credentials are configured correctly in the dataset's settings. Since Premium does not block refresh, this option is factually wrong and cannot be the reason the configuration review flagged a failure.

Full breakdown with real-world context →

Question 12mediumdrag order

Read the full Deploy and maintain assets explanation →

Drag and drop the steps to create a measure in Power BI Desktop into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Step 1: Write the DAX formula, Step 2: Open the Modeling tab, Step…

Starting by writing a DAX formula first is logically impossible because the formula needs a target measure container to be stored in. Without first opening the Modeling tab and clicking New Measure, there is no field in which to type the formula — the formula bar is blank and any text you enter would be discarded or attached to a different context. In Power BI Desktop, a measure must be explicitly created as an object before the DAX expression has a home, so the correct sequence must place the creation actions before the formula entry.

Trap 2: Step 1: Open the Modeling tab, Step 2: Write the DAX formula, Step…

In this arrangement, you open the Modeling tab but then immediately write the DAX formula without clicking New Measure. That is ineffective because the Modeling tab's formula bar can only accept a formula after a measure is created; otherwise, the text you type is not associated with any field. Even if you intend to create a new measure later, the formula you wrote would have no named context and would be lost when you click New Measure. The explicit click of New Measure is the essential action that instantiates the measure and enables formula entry, so skipping it breaks the workflow.

Trap 3: Step 1: Use the measure in a visual, Step 2: Open the Modeling tab,…

Using a measure in a visual before it exists is impossible because the Fields pane has no such measure to drag, and the visual's value field dropdown cannot display a non-existent measure. Even if you try to type the measure name directly into the visual's field well, validation will fail because the measure has not been defined yet. A visual can only aggregate from fields and measures that are already in the current data model, so the creation and formula steps must occur first. This sequence inverts the dependency: a measure is a prerequisite for its use, not an afterthought.

Study all Deploy and maintain assets common traps →

A
Step 1: Open the Modeling tab, Step 2: Click New Measure, Step 3: Write the DAX formula, Step 4: Use the measure in a visual.
The correct sequence begins by navigating to the Modeling tab in Power BI Desktop, where the New Measure button is located. Clicking New Measure creates a measure object in the selected table, after which you can enter the DAX formula in the formula bar. Once validated, the measure appears in the Fields pane and can be dragged into any visual to compute dynamic, context-aware aggregations. This order ensures that the measure exists as a named, storable formula before any visual references it.
B
Step 1: Write the DAX formula, Step 2: Open the Modeling tab, Step 3: Click New Measure, Step 4: Use the measure in a visual.
Why wrong: Starting by writing a DAX formula first is logically impossible because the formula needs a target measure container to be stored in. Without first opening the Modeling tab and clicking New Measure, there is no field in which to type the formula — the formula bar is blank and any text you enter would be discarded or attached to a different context. In Power BI Desktop, a measure must be explicitly created as an object before the DAX expression has a home, so the correct sequence must place the creation actions before the formula entry.
C
Step 1: Open the Modeling tab, Step 2: Write the DAX formula, Step 3: Click New Measure, Step 4: Use the measure in a visual.
Why wrong: In this arrangement, you open the Modeling tab but then immediately write the DAX formula without clicking New Measure. That is ineffective because the Modeling tab's formula bar can only accept a formula after a measure is created; otherwise, the text you type is not associated with any field. Even if you intend to create a new measure later, the formula you wrote would have no named context and would be lost when you click New Measure. The explicit click of New Measure is the essential action that instantiates the measure and enables formula entry, so skipping it breaks the workflow.
D
Step 1: Use the measure in a visual, Step 2: Open the Modeling tab, Step 3: Click New Measure, Step 4: Write the DAX formula.
Why wrong: Using a measure in a visual before it exists is impossible because the Fields pane has no such measure to drag, and the visual's value field dropdown cannot display a non-existent measure. Even if you try to type the measure name directly into the visual's field well, validation will fail because the measure has not been defined yet. A visual can only aggregate from fields and measures that are already in the current data model, so the creation and formula steps must occur first. This sequence inverts the dependency: a measure is a prerequisite for its use, not an afterthought.

Full breakdown with real-world context →

Question 13mediummatching

Read the full Deploy and maintain assets explanation →

Match each Power BI license type to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Create personal reports, cannot share

Share and collaborate with others

Dedicated capacity for a user

Reserved compute resources

Embed analytics in applications

Trap 1: Power BI Premium Per User: Enables collaboration, sharing, and…

The statement incorrectly describes Power BI Pro, because Premium Per User is a per-user add-on that combines the features of Pro with access to Premium capabilities such as paginated reports, AI visuals, and advanced analytics, all assigned to an individual user. With Premium Per User, collaboration is not simply 'with other Pro users'; every user who shares or views content in a PPU workspace must also have a PPU license, and capacity-based features are delivered through the shared infrastructure rather than a dedicated cluster. Thus PPU is about giving an individual advanced features, not about expanding who can receive shared Pro content.

Trap 2: Power BI Premium: Allows users to create reports and dashboards for…

This description confuses Power BI Premium with Power BI Free, since Premium is not a personal-use license but an enterprise capacity-based offering that reserves dedicated cloud resources for an organization's entire deployment. With Power BI Premium (capacity) an organization can distribute dashboards and reports to many users, including Free license holders, without requiring each recipient to have a Pro license, and it supports features like dataflows, paginated reports, and larger data storage limits. Allowing only personal use contradicts Premium's entire purpose of organization-wide BI delivery.

Study all Deploy and maintain assets common traps →

A
Power BI Free: Allows users to create reports and dashboards for personal use only. Cannot share with others.
A Power BI Free license restricts a user to creating reports and dashboards in their personal My Workspace and using Power BI through the Power BI service, but it does not permit sharing, publishing, or collaborating with others. When working on the shared capacity, a Free license cannot be used to view content shared by a Pro user; the user must either be in a Premium capacity workspace or have a Pro license to open that content. This is the base-level license designed solely for individual, non-collaborative use.
B
Power BI Pro: Enables collaboration, sharing, and publishing content with other Pro users.
Power BI Pro is a per-user license that grants full authoring and consumption rights in the Power BI service, including the ability to create and manage shared workspaces, publish apps, share dashboards and reports, and collaborate with other users who also have a Pro license. Pro operates on the shared capacity, meaning every user who needs to access shared content must be assigned Pro, except when the content resides on a Premium capacity where Free users can consume it. Pro does not include dedicated compute or storage, but it is the standard license for business users collaborating within an organization.
C
Power BI Premium Per User: Enables collaboration, sharing, and publishing content with other Pro users.
Why wrong: The statement incorrectly describes Power BI Pro, because Premium Per User is a per-user add-on that combines the features of Pro with access to Premium capabilities such as paginated reports, AI visuals, and advanced analytics, all assigned to an individual user. With Premium Per User, collaboration is not simply 'with other Pro users'; every user who shares or views content in a PPU workspace must also have a PPU license, and capacity-based features are delivered through the shared infrastructure rather than a dedicated cluster. Thus PPU is about giving an individual advanced features, not about expanding who can receive shared Pro content.
D
Power BI Premium: Allows users to create reports and dashboards for personal use only.
Why wrong: This description confuses Power BI Premium with Power BI Free, since Premium is not a personal-use license but an enterprise capacity-based offering that reserves dedicated cloud resources for an organization's entire deployment. With Power BI Premium (capacity) an organization can distribute dashboards and reports to many users, including Free license holders, without requiring each recipient to have a Pro license, and it supports features like dataflows, paginated reports, and larger data storage limits. Allowing only personal use contradicts Premium's entire purpose of organization-wide BI delivery.

Full breakdown with real-world context →

Question 14mediummatching

Read the full Deploy and maintain assets explanation →

Match each data source type to an example.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

SQL Server

CSV

Salesforce

Azure SQL Database

REST endpoint

Trap 1: Relational Database: CSV file

Although a CSV file contains rows and columns, it lacks the defining attributes of a relational database: no enforced schema, no primary/foreign keys, no indexes or constraints, and no SQL query engine. It is a flat file that simply stores comma-delimited text, so it has no capability to maintain relationships or perform transactional operations - categorizing it as a relational database is incorrect.

Trap 2: Flat File: Excel file

An Excel workbook is not a flat file because it is a compound, structured document (XLSX) that can encapsulate multiple worksheets, formulas, charts, and macros within a zipped XML package. A flat file, by definition, is a single plain-text or record-based file (like CSV or TXT) without embedded metadata or multiple logical sections. Although a single worksheet can look flat, the overall workbook format belongs to the Excel source category, not the flat-file category.

Study all Deploy and maintain assets common traps →

A
Relational Database: SQL Server database
SQL Server is a relational database management system (RDBMS) that organizes data into structured tables with explicitly defined rows, columns, primary keys, and foreign keys. It enforces referential integrity, supports ACID transactions, and allows querying via T-SQL, which is why it is the canonical example of a relational database in Power BI. Its relational engine also enables query folding and DirectQuery mode for enterprise-scale reporting.
B
Flat File: CSV file
A CSV (comma-separated values) file is a plain-text flat file that stores tabular data as rows of text, with each field separated by a delimiter such as a comma. It has no schema, indexes, data types, or relationships - only raw, unstructured lines that Power BI reads via the Text/CSV connector. This makes it a minimalist flat file, distinct from databases or binary workbook formats.
C
Excel Workbook: Excel file
An Excel file (.xlsx) is the native format for Excel workbooks, a proprietary binary/XML-based document that can contain multiple worksheets, named ranges, formulas, pivot tables, and embedded data models (e.g., Power Pivot). Power BI classifies it as its own workbook source because it offers rich features and in-file structure beyond a simple flat table, while still not being a relational database or a web service.
D
Web Service: REST API
A REST API is a web service that exposes data through standard HTTP methods (GET, POST, etc.) at specific endpoints, typically returning JSON or XML payloads. Power BI connects via the Web or OData connectors, enabling real-time or token-authenticated data queries from cloud or on-premises services. This fits the 'Web Service' category because data is accessed over the network using asynchronous requests, not imported from a local file or database.
E
Relational Database: CSV file
Why wrong: Although a CSV file contains rows and columns, it lacks the defining attributes of a relational database: no enforced schema, no primary/foreign keys, no indexes or constraints, and no SQL query engine. It is a flat file that simply stores comma-delimited text, so it has no capability to maintain relationships or perform transactional operations - categorizing it as a relational database is incorrect.
F
Flat File: Excel file
Why wrong: An Excel workbook is not a flat file because it is a compound, structured document (XLSX) that can encapsulate multiple worksheets, formulas, charts, and macros within a zipped XML package. A flat file, by definition, is a single plain-text or record-based file (like CSV or TXT) without embedded metadata or multiple logical sections. Although a single worksheet can look flat, the overall workbook format belongs to the Excel source category, not the flat-file category.

Full breakdown with real-world context →

Question 15mediummultiple choice

Read the full Deploy and maintain assets explanation →

You manage a Power BI workspace that contains a dataset refreshed daily from an on-premises SQL Server. Users report that the report shows data from two days ago. You verify that the scheduled refresh ran successfully this morning. What is the most likely cause?

Trap 1: The refresh took longer than expected and timed out.

Incorrect. If the refresh had timed out, Power BI would record a failed refresh in the refresh history and the dataset would retain its previous data — it would not show a successful status. A timeout is an error condition, not a silent success, so it cannot explain a refresh that completed this morning while loading stale data. This option mistakes a possible cause of refresh failure for a cause of a successful-but-outdated load.

Trap 2: The scheduled refresh is not set to refresh the dataset.

Incorrect. If no scheduled refresh is configured for the dataset, Power BI will not automatically run any refresh at all; the refresh history would be empty or show only manual refreshes. The question states the refresh ran successfully this morning, which proves that some refresh mechanism — scheduled or manual — executed. A missing schedule cannot cause a refresh to run successfully yet load stale data; it would simply prevent the refresh from occurring.

Trap 3: The on-premises data gateway is offline.

Incorrect. An offline on-premises data gateway would make the connection to the on-premises source fail entirely, producing a refresh error such as 'Could not connect to the data source' or 'Gateway not reachable.' Since the refresh reportedly succeeded, the gateway must have been online and able to route the query. Thus an offline gateway could not result in a successful refresh with outdated data — it would result in no data load at all.

Study all Deploy and maintain assets common traps →

A
The on-premises data source is misconfigured, causing the refresh to load data from an outdated source.
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.
B
The refresh took longer than expected and timed out.
Why wrong: Incorrect. If the refresh had timed out, Power BI would record a failed refresh in the refresh history and the dataset would retain its previous data — it would not show a successful status. A timeout is an error condition, not a silent success, so it cannot explain a refresh that completed this morning while loading stale data. This option mistakes a possible cause of refresh failure for a cause of a successful-but-outdated load.
C
The scheduled refresh is not set to refresh the dataset.
Why wrong: Incorrect. If no scheduled refresh is configured for the dataset, Power BI will not automatically run any refresh at all; the refresh history would be empty or show only manual refreshes. The question states the refresh ran successfully this morning, which proves that some refresh mechanism — scheduled or manual — executed. A missing schedule cannot cause a refresh to run successfully yet load stale data; it would simply prevent the refresh from occurring.
D
The on-premises data gateway is offline.
Why wrong: Incorrect. An offline on-premises data gateway would make the connection to the on-premises source fail entirely, producing a refresh error such as 'Could not connect to the data source' or 'Gateway not reachable.' Since the refresh reportedly succeeded, the gateway must have been online and able to route the query. Thus an offline gateway could not result in a successful refresh with outdated data — it would result in no data load at all.

Full breakdown with real-world context →

Question 16easymultiple choice

Read the full Deploy and maintain assets explanation →

You need to deploy a Power BI report from a development workspace to a production workspace. You want to ensure that the report uses the production dataset connection string without manual changes. What should you use?

Trap 1: Manually update the data source in the production workspace after…

Manually updating the data source in the production workspace after deployment introduces human error risk and violates the requirement for zero manual changes, as the stem explicitly demands that the report automatically use the production dataset connection string. This approach is tempting because it is a straightforward, one-time fix for a broken connection after deployment, and it would be the correct choice if the scenario allowed for a single, controlled manual adjustment rather than requiring an automated, repeatable deployment pipeline.

Trap 2: Use a Power BI template (.pbit) and change the connection string…

Using a .pbit template does not automate the connection string change; you would still have to manually edit the connection string in Power BI Desktop before each publish. That manual step is error-prone, does not scale across environments, and fails the requirement for a zero-touch, repeatable deployment. A .pbit is a project template, not a deployment artifact, so it provides no built-in mechanism for environment-specific substitutions.

Trap 3: Publish the report directly to the production workspace and update…

Publishing directly to the production workspace and then updating the dataset after the fact is a manual, post-hoc fix that violates the requirement for an automated deployment. You would have to locate the dataset in the Power BI service, change the connection string manually, and ensure credentials are configured correctly—all of which introduces human error risk and is not repeatable. Additionally, this approach bypasses the deployment pipeline, so you lose the ability to validate the report in test/QA environments before production, and any future updates would require the same manual correction each time.

Study all Deploy and maintain assets common traps →

A
Manually update the data source in the production workspace after deployment.
Why wrong: Manually updating the data source in the production workspace after deployment introduces human error risk and violates the requirement for zero manual changes, as the stem explicitly demands that the report automatically use the production dataset connection string. This approach is tempting because it is a straightforward, one-time fix for a broken connection after deployment, and it would be the correct choice if the scenario allowed for a single, controlled manual adjustment rather than requiring an automated, repeatable deployment pipeline.
B
Use a Power BI template (.pbit) and change the connection string before publishing.
Why wrong: Using a .pbit template does not automate the connection string change; you would still have to manually edit the connection string in Power BI Desktop before each publish. That manual step is error-prone, does not scale across environments, and fails the requirement for a zero-touch, repeatable deployment. A .pbit is a project template, not a deployment artifact, so it provides no built-in mechanism for environment-specific substitutions.
C
Configure a deployment pipeline with parameter rules to override the data source.
Power BI Deployment Pipelines allow you to assign parameter rules (e.g., for data source parameters like Server and Database) that override values automatically when content is deployed from dev to test to production. This is the correct choice because it is the only option that truly meets the requirement of the report automatically using the production connection string without any manual adjustment. The rules are configured once in the pipeline and then applied consistently on every deployment, making the process repeatable and governed.
D
Publish the report directly to the production workspace and update the dataset.
Why wrong: Publishing directly to the production workspace and then updating the dataset after the fact is a manual, post-hoc fix that violates the requirement for an automated deployment. You would have to locate the dataset in the Power BI service, change the connection string manually, and ensure credentials are configured correctly—all of which introduces human error risk and is not repeatable. Additionally, this approach bypasses the deployment pipeline, so you lose the ability to validate the report in test/QA environments before production, and any future updates would require the same manual correction each time.

Full breakdown with real-world context →

Question 17mediummultiple choice

Read the full Deploy and maintain assets explanation →

You are deploying a Power BI solution to a customer. The customer requires that all report access be controlled via Azure Active Directory (Azure AD) groups. You have a single workspace with multiple reports. What is the best practice for managing permissions?

Trap 1: Create a Power BI group and add users to it.

Creating a Power BI group (an Office 365/Outlook group) and adding users to it does not, by itself, grant anyone access to a Power BI workspace. These groups are deprecated as a management concept and are not recognized as direct workspace principals. To use a group for access, you must explicitly add that group to a workspace role in Power BI, which is exactly what the correct option does. Merely creating the group adds no permission and users will still get 'You need permission' errors.

Trap 2: Assign each user directly to the workspace role.

Assigning each user directly to the workspace role is technically functional but becomes administrationally burdensome at scale. For every new user, change, or departure, you must manually edit the workspace role membership; with multiple workspaces and many users, this quickly becomes error-prone and time-consuming. It also bypasses central identity management, making access hard to audit and govern. Azure AD groups as role members allow membership changes to flow automatically, which is the recommended scalable approach.

Trap 3: Share each report individually with users.

Sharing each report individually gives users read-only access to that specific artifact, but it does not grant access to the underlying workspace, dataset, or other content. This approach does not scale: every new report must be shared separately, and you risk stale or inconsistent permissions across reports. It also blocks collaboration and editing, because workspace roles carry broader permissions (like Viewer, Contributor, Member, or Admin). The correct pattern is to manage access at the workspace level by assigning an Azure AD group to a workspace role, so all content inherits permissions consistently.

Study all Deploy and maintain assets common traps →

A
Create a Power BI group and add users to it.
Why wrong: Creating a Power BI group (an Office 365/Outlook group) and adding users to it does not, by itself, grant anyone access to a Power BI workspace. These groups are deprecated as a management concept and are not recognized as direct workspace principals. To use a group for access, you must explicitly add that group to a workspace role in Power BI, which is exactly what the correct option does. Merely creating the group adds no permission and users will still get 'You need permission' errors.
B
Assign each user directly to the workspace role.
Why wrong: Assigning each user directly to the workspace role is technically functional but becomes administrationally burdensome at scale. For every new user, change, or departure, you must manually edit the workspace role membership; with multiple workspaces and many users, this quickly becomes error-prone and time-consuming. It also bypasses central identity management, making access hard to audit and govern. Azure AD groups as role members allow membership changes to flow automatically, which is the recommended scalable approach.
C
Share each report individually with users.
Why wrong: Sharing each report individually gives users read-only access to that specific artifact, but it does not grant access to the underlying workspace, dataset, or other content. This approach does not scale: every new report must be shared separately, and you risk stale or inconsistent permissions across reports. It also blocks collaboration and editing, because workspace roles carry broader permissions (like Viewer, Contributor, Member, or Admin). The correct pattern is to manage access at the workspace level by assigning an Azure AD group to a workspace role, so all content inherits permissions consistently.
D
Add an Azure AD group to the workspace role.
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.

Full breakdown with real-world context →

Question 18easymultiple choice

Read the full Deploy and maintain assets explanation →

A user reports that a Power BI report is not refreshing data from a SQL Server database. The dataset uses Import mode. The gateway cluster shows all gateways are online. What is the most likely cause?

Trap 1: The report is using a scheduled refresh with a conflicting time.

Scheduled refresh conflicts do not cause a refresh to fail outright. Power BI's service serializes overlapping refreshes by queuing them; a refresh that would run during an already running refresh is simply deferred until the prior one finishes. At most, you might see a 'refresh skipped because a refresh is already in progress' warning, but the scheduled time itself never invalidates data source credentials. Refresh failures from conflicts would also produce a specific error message, not a silent data staleness issue.

Trap 2: The gateway version is incompatible with the SQL Server version.

The on-premises data gateway is a bridge between Power BI and the data source, and its version compatibility is generally defined against the Power BI service, not against the SQL Server version. Even if a gateway were too old, the symptom would typically be a driver or protocol error during the attempt to connect, not a generic refresh failure. Most modern gateway versions support a wide range of SQL Server versions, so a version mismatch is an uncommon root cause compared to authentication issues.

Trap 3: The dataset uses DirectQuery mode which requires a live connection.

This dataset was created with Import mode, which means the report is not using DirectQuery. In DirectQuery, there is no scheduled refresh job because queries are issued live against the source each time the report is opened, and that would instead produce a 'cannot connect to data source' error during report render. Since this report is Import mode, a refresh failure is about the stored data source credentials or gateway connectivity, not a live-connection requirement.

Study all Deploy and maintain assets common traps →

A
The report is using a scheduled refresh with a conflicting time.
Why wrong: Scheduled refresh conflicts do not cause a refresh to fail outright. Power BI's service serializes overlapping refreshes by queuing them; a refresh that would run during an already running refresh is simply deferred until the prior one finishes. At most, you might see a 'refresh skipped because a refresh is already in progress' warning, but the scheduled time itself never invalidates data source credentials. Refresh failures from conflicts would also produce a specific error message, not a silent data staleness issue.
B
The gateway version is incompatible with the SQL Server version.
Why wrong: The on-premises data gateway is a bridge between Power BI and the data source, and its version compatibility is generally defined against the Power BI service, not against the SQL Server version. Even if a gateway were too old, the symptom would typically be a driver or protocol error during the attempt to connect, not a generic refresh failure. Most modern gateway versions support a wide range of SQL Server versions, so a version mismatch is an uncommon root cause compared to authentication issues.
C
The dataset uses DirectQuery mode which requires a live connection.
Why wrong: This dataset was created with Import mode, which means the report is not using DirectQuery. In DirectQuery, there is no scheduled refresh job because queries are issued live against the source each time the report is opened, and that would instead produce a 'cannot connect to data source' error during report render. Since this report is Import mode, a refresh failure is about the stored data source credentials or gateway connectivity, not a live-connection requirement.
D
The data source credentials are incorrect or expired.
Incorrect or expired data source credentials are the most frequent cause of a Power BI scheduled refresh failure. When you configure a dataset for refresh, Power BI stores the authentication values—Windows credentials, database passwords, or OAuth tokens—and if those are changed or time out, the service cannot authenticate to the source and the refresh operation fails with an error. Updating the credentials in the dataset settings under 'Edit credentials' resolves the issue, and you should verify that the account still has the same permissions.

Full breakdown with real-world context →

Question 19easymultiple choice

Read the full Deploy and maintain assets explanation →

You need to ensure that a Power BI report uses the latest data from a cloud-based Azure SQL Database. The report is configured with scheduled refresh. What is the minimum required license for the dataset owner to configure a scheduled refresh?

Trap 1: Power BI Premium capacity

Power BI Premium capacity is a cloud-based computing resource that provides dedicated processing power, not a per-user license. Even when a workspace is assigned to Premium capacity, the user who creates or schedules the dataset refresh must hold a Power BI Pro license because scheduled refresh is a Pro feature. The capacity alone does not grant refresh scheduling rights.

Trap 2: Power BI Premium Per User

Power BI Premium Per User (PPU) is a per-user upgrade that bundles Power BI Pro capabilities with additional premium features, but it is not the minimum requirement for scheduling refresh. A standard Power BI Pro license already permits you to configure scheduled refresh in shared capacity, so PPU is more expensive than necessary and does not change the underlying licensing requirement.

Trap 3: Power BI Free

Microsoft Power BI Free licenses are designed mainly for consuming content, not authoring and publishing reports that require scheduled refresh. In either shared capacity or a Premium-backed workspace, a free license lacks the service-level permissions needed to create dataset refresh schedules because scheduled refresh is reserved for Pro (or above) accounts. Therefore, Free cannot satisfy the requirement.

Study all Deploy and maintain assets common traps →

A
Power BI Premium capacity
Why wrong: Power BI Premium capacity is a cloud-based computing resource that provides dedicated processing power, not a per-user license. Even when a workspace is assigned to Premium capacity, the user who creates or schedules the dataset refresh must hold a Power BI Pro license because scheduled refresh is a Pro feature. The capacity alone does not grant refresh scheduling rights.
B
Power BI Premium Per User
Why wrong: Power BI Premium Per User (PPU) is a per-user upgrade that bundles Power BI Pro capabilities with additional premium features, but it is not the minimum requirement for scheduling refresh. A standard Power BI Pro license already permits you to configure scheduled refresh in shared capacity, so PPU is more expensive than necessary and does not change the underlying licensing requirement.
C
Power BI Free
Why wrong: Microsoft Power BI Free licenses are designed mainly for consuming content, not authoring and publishing reports that require scheduled refresh. In either shared capacity or a Premium-backed workspace, a free license lacks the service-level permissions needed to create dataset refresh schedules because scheduled refresh is reserved for Pro (or above) accounts. Therefore, Free cannot satisfy the requirement.
D
Power BI Pro
Power BI Pro is the correct minimum license because scheduled refresh in the Power BI service is a Pro-only feature. With a Pro license, you can create datasets, publish them to shared capacity, and configure a refresh schedule without needing Premium capacity or Premium Per User. A Pro license is sufficient for the standard, recurring data refresh scenario in shared capacity.

Full breakdown with real-world context →

Question 20mediummultiple choice

Read the full Deploy and maintain assets explanation →

You publish a Power BI report to a workspace that uses an organizational app. After updating the report, you want users to see the changes immediately without having to reinstall the app. What should you do?

Trap 1: Delete and recreate the app from the workspace.

Deleting and recreating the app is an unnecessarily destructive action: it removes the app from all users' Power BI service, forcing them to lose access immediately and then reinstall the app from the new version. Additionally, you would need to reconfigure the app's contents, positioning, and permissions from scratch, and you risk breaking any shared links or embedded views that rely on the original app. The intended flow is to update the existing app, which preserves the app's URL, user access, and settings while simply propagating the latest report changes.

Trap 2: Republish the report from Power BI Desktop.

Republishing the report from Power BI Desktop only updates the report and dataset within the workspace itself; it does not automatically update the app that was created from that workspace. In Power BI, an app is a separate distribution layer that must be explicitly "Updated" to push the workspace's latest content to end users. Without taking that final step in the service, users of the app will continue to see the previous version of the report, regardless of how many times you republish the underlying .pbix file. This option also risks overwriting the dataset or introducing unvalidated changes into the workspace without the intended app-level review.

Trap 3: Ask users to refresh their browser cache.

Asking users to refresh their browser cache is ineffective because the app's content is served from Power BI service, not stored client-side. The report version displayed is determined by the app's published snapshot, which remains unchanged until the app is explicitly updated. Browser caching might affect page assets like images or CSS, but it will not force the app to pull a new report definition or reflect modifications made in the workspace. Therefore, even after clearing the cache, users will still see the stale app content because the app itself has not been updated.

Study all Deploy and maintain assets common traps →

A
Delete and recreate the app from the workspace.
Why wrong: Deleting and recreating the app is an unnecessarily destructive action: it removes the app from all users' Power BI service, forcing them to lose access immediately and then reinstall the app from the new version. Additionally, you would need to reconfigure the app's contents, positioning, and permissions from scratch, and you risk breaking any shared links or embedded views that rely on the original app. The intended flow is to update the existing app, which preserves the app's URL, user access, and settings while simply propagating the latest report changes.
B
Republish the report from Power BI Desktop.
Why wrong: Republishing the report from Power BI Desktop only updates the report and dataset within the workspace itself; it does not automatically update the app that was created from that workspace. In Power BI, an app is a separate distribution layer that must be explicitly "Updated" to push the workspace's latest content to end users. Without taking that final step in the service, users of the app will continue to see the previous version of the report, regardless of how many times you republish the underlying .pbix file. This option also risks overwriting the dataset or introducing unvalidated changes into the workspace without the intended app-level review.
C
Ask users to refresh their browser cache.
Why wrong: Asking users to refresh their browser cache is ineffective because the app's content is served from Power BI service, not stored client-side. The report version displayed is determined by the app's published snapshot, which remains unchanged until the app is explicitly updated. Browser caching might affect page assets like images or CSS, but it will not force the app to pull a new report definition or reflect modifications made in the workspace. Therefore, even after clearing the cache, users will still see the stale app content because the app itself has not been updated.
D
Update the app in the workspace by selecting 'Update app'.
In the Power BI service, the correct way to propagate workspace changes to the audience is to open the workspace and click "Update app" (or "Update app" in the app editing screen). This action re-publishes the app's content, including the modified report, to all current app users without interrupting their access or requiring them to reinstall the app. It also ensures the app's metadata, navigation, and permissions remain intact. This is the standard lifecycle step after editing a report or dashboard in the source workspace.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Deploy and maintain assets sessions

Start a Deploy and maintain assets only practice session

Every question in these sessions is drawn from the Deploy and maintain assets domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Deploy and maintain assets questions →Mixed PL-300 session

Frequently asked questions

What does the PL-300 exam test about Deploy and maintain assets?: Deploy and maintain assets questions test whether you can apply the concept in context, not just recognise a definition.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Deploy and maintain assets questions in a focused session?: Yes — the session launcher on this page draws every question from the Deploy and maintain assets domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other PL-300 topics?: Use the topic links above to move to related areas, or go back to the PL-300 question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the PL-300 exam covers. They are not copied from any real exam or dump site.

Deploy and maintain assets only

10 questions 20 questions 30 questions 50 questions

Mixed PL-300 session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All PL-300 questions Deploy and maintain assets domain overview PL-300 exam guide

Exam traps to avoid

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Deploy and maintain assets practice questions

What to know about Deploy and maintain assets

Common Deploy and maintain assets exam traps

Deploy and maintain assets questions

Your Power BI dataset uses DirectQuery to an Azure SQL Database. Users complain that the report is slow. You need to improve query performance without changing the data source. What should you do?

You have a Power BI dataset that is refreshed every hour from an on-premises data source using an enterprise gateway. The refresh consistently fails at 2:00 AM. What is the most likely cause?

Which TWO actions should you take to ensure that a Power BI report deployed to production is available to users even if the gateway is offline for maintenance?

Which THREE steps should you perform to deploy a Power BI solution from development to production using deployment pipelines?

You review the dataset refresh history. The second refresh took 30 minutes and failed. What is the most likely reason for the failure?

Exhibit

You are troubleshooting connectivity to a Power BI Premium dataset via the XMLA endpoint. A user reports that they cannot connect using SQL Server Management Studio (SSMS) but can view reports in the Power BI service. The user's email is user3@contoso.com. What is the most likely cause?

Exhibit

You deploy a Power BI app to a workspace with an app-only license (Premium Per User). Users report that they can access the app but cannot see any visuals in the reports. The dataset uses Import mode. What is the most likely issue?

You manage a Power BI deployment that uses deployment pipelines. After promoting content from Development to Test, you notice that the Test workspace dataset uses a different data source than expected. What is the most likely reason?

Which THREE factors should you consider when planning the deployment of Power BI content to a large enterprise with multiple regions?

Exhibit

Drag and drop the steps to create a measure in Power BI Desktop into the correct order.

Match each Power BI license type to its description.

Match each data source type to an example.

You manage a Power BI workspace that contains a dataset refreshed daily from an on-premises SQL Server. Users report that the report shows data from two days ago. You verify that the scheduled refresh ran successfully this morning. What is the most likely cause?

You need to deploy a Power BI report from a development workspace to a production workspace. You want to ensure that the report uses the production dataset connection string without manual changes. What should you use?

You are deploying a Power BI solution to a customer. The customer requires that all report access be controlled via Azure Active Directory (Azure AD) groups. You have a single workspace with multiple reports. What is the best practice for managing permissions?

A user reports that a Power BI report is not refreshing data from a SQL Server database. The dataset uses Import mode. The gateway cluster shows all gateways are online. What is the most likely cause?

You need to ensure that a Power BI report uses the latest data from a cloud-based Azure SQL Database. The report is configured with scheduled refresh. What is the minimum required license for the dataset owner to configure a scheduled refresh?

You publish a Power BI report to a workspace that uses an organizational app. After updating the report, you want users to see the changes immediately without having to reinstall the app. What should you do?

Track your progress over time

Start a Deploy and maintain assets only practice session

Related PL-300 topic practice pages

Prepare the data practice questions