Troubleshooting practice questions

Refer to the exhibit. You are troubleshooting a Power Automate flow that fails when trying to access an on-premises SQL Server database. The flow uses the SQL connector. Based on the exhibit, what is the most likely cause of the failure?

Exhibit

{
  "connections": [
    {
      "name": "shared_office365",
      "id": "/providers/Microsoft.PowerApps/apis/shared_office365"
    },
    {
      "name": "shared_sql",
      "id": "/providers/Microsoft.PowerApps/apis/shared_sql"
    }
  ],
  "environment": {
    "name": "Production",
    "type": "Production",
    "region": "eastus"
  }
}

Trap 1: The Office 365 connector is conflicting with the SQL connector.

Multiple connectors can coexist in a flow without conflict.

Trap 2: The environment type is Production, which restricts access to…

Production environments can connect to on-premises data with a gateway.

Trap 3: The region 'eastus' does not support on-premises connectivity.

All Azure regions support on-premises data gateways.

A
The Office 365 connector is conflicting with the SQL connector.
Why it fails: Multiple connectors can coexist in a flow without conflict.
B
The flow is using the cloud SQL connector without an on-premises data gateway.
The cloud SQL connector reaches only internet-accessible databases; on-premises SQL Server requires an on-premises data gateway to bridge the network boundary. Without that gateway installed and configured, the flow's connection attempt fails, matching the exhibit's error.
C
The environment type is Production, which restricts access to on-premises data.
Why it fails: Production environments can connect to on-premises data with a gateway.
D
The region 'eastus' does not support on-premises connectivity.
Why it fails: All Azure regions support on-premises data gateways.

Question 2hardmultiple choice

You are a Power BI administrator for a large retail company. The company has a Power BI workspace that contains a dashboard named 'Sales Overview'. The dashboard is shared with the sales team. Recently, users have reported that the dashboard is loading slowly, and some visuals show 'Data is not available' errors. The dashboard uses a DirectQuery connection to an on-premises SQL Server database. The database team confirms that the server is not under heavy load. You need to troubleshoot and resolve the issue. What should you do first?

Trap 1: Replace the DirectQuery connection with an Import connection

Switching to Import would cache data but abandons the near-real-time requirement DirectQuery exists to satisfy, and it does not address the failing gateway causing 'Data is not available'. Import is correct when latency tolerance allows scheduled refreshes instead of live queries.

Trap 2: Ask the database team to add more indexes to the SQL Server tables

Adding indexes targets query performance on the SQL Server, yet the database team confirms the server is not under heavy load, so the bottleneck lies elsewhere — most likely the on-premises data gateway. Indexing would be the right move when DirectQuery queries themselves are slow due to poor table scans.

Trap 3: Increase the scheduled refresh frequency to every 15 minutes

Scheduled refresh frequency applies only to Import datasets; DirectQuery models query the source live and have no refresh schedule to increase. This would be the right action for an Import model whose cached data is stale, not for a DirectQuery connectivity failure.

A
Check the on-premises data gateway performance and logs for errors
DirectQuery routes every visual query through the on-premises data gateway, so gateway latency or errors produce slow loads and 'Data is not available' messages even when the SQL Server itself is healthy. Checking gateway performance and logs isolates the failing hop first.
B
Replace the DirectQuery connection with an Import connection
Why it fails: Switching to Import would cache data but abandons the near-real-time requirement DirectQuery exists to satisfy, and it does not address the failing gateway causing 'Data is not available'. Import is correct when latency tolerance allows scheduled refreshes instead of live queries.
C
Ask the database team to add more indexes to the SQL Server tables
Why it fails: Adding indexes targets query performance on the SQL Server, yet the database team confirms the server is not under heavy load, so the bottleneck lies elsewhere — most likely the on-premises data gateway. Indexing would be the right move when DirectQuery queries themselves are slow due to poor table scans.
D
Increase the scheduled refresh frequency to every 15 minutes
Why it fails: Scheduled refresh frequency applies only to Import datasets; DirectQuery models query the source live and have no refresh schedule to increase. This would be the right action for an Import model whose cached data is stale, not for a DirectQuery connectivity failure.

Question 3hardmultiple choice

You are troubleshooting a canvas app that loads slowly. The app uses over 50 data sources and many formulas. Which action is most likely to improve performance?

Trap 1: Increase the data row limit for each data source

Raising the data row limit increases the volume each data source retrieves, adding load rather than reducing it. The setting exists to fetch more records when an app genuinely needs them, but with 50 data sources the bottleneck is the number of connections and formula evaluations, not row ceilings.

Trap 2: Disable the formula-level error checking

Disabling formula-level error checking only suppresses compile-time warnings; it does not reduce the number of data sources, delegable queries or formula evaluations that drive load time. It is tempting because it speeds up authoring in Power Apps Studio, which is the correct choice when editing large apps becomes sluggish, not when runtime performance suffers.

Trap 3: Remove unused data sources from the app

Removing unused data sources reduces the number of connections the app establishes at startup, which is a genuine performance lever. However, the stem's slow load stems from excessive data sources and formulas combined; eliminating unused ones alone leaves the heavy formula and delegation load unaddressed.

A
Increase the data row limit for each data source
Why it fails: Raising the data row limit increases the volume each data source retrieves, adding load rather than reducing it. The setting exists to fetch more records when an app genuinely needs them, but with 50 data sources the bottleneck is the number of connections and formula evaluations, not row ceilings.
B
Use delegable queries to filter data at the source
Delegable queries push filtering to the data source rather than pulling entire tables to the client, so the canvas app retrieves only matching records. With over 50 data sources, this sharply cuts the volume transferred and processed locally, directly addressing the slow loading caused by non-delegable operations.
C
Disable the formula-level error checking
Why it fails: Disabling formula-level error checking only suppresses compile-time warnings; it does not reduce the number of data sources, delegable queries or formula evaluations that drive load time. It is tempting because it speeds up authoring in Power Apps Studio, which is the correct choice when editing large apps becomes sluggish, not when runtime performance suffers.
D
Remove unused data sources from the app
Why it fails: Removing unused data sources reduces the number of connections the app establishes at startup, which is a genuine performance lever. However, the stem's slow load stems from excessive data sources and formulas combined; eliminating unused ones alone leaves the heavy formula and delegation load unaddressed.

Question 4hardmultiple choice

You are troubleshooting a canvas app that connects to a SQL Server database through an on-premises data gateway. Users in the finance department receive an error stating the app cannot reach the data source, while users in IT can use the app normally. What is the most likely cause?

Trap 1: The finance users lack the necessary permissions on the SQL Server…

If finance users lacked SQL Server permissions, the error would typically be an authentication or access-denied message from SQL Server, not a generic inability to reach the data source. The gateway connection uses stored credentials, so individual database permissions are less likely to produce a reachability error.

Trap 2: The gateway is installed on a machine that is turned off during…

If the gateway machine were offline, all users including IT would experience failures, not just finance. A time-based outage would also affect IT users who work the same hours. The selective failure by department points to a permission issue rather than gateway availability.

Trap 3: The SQL Server database has reached its maximum number of…

A connection limit would cause intermittent or global failures, not a consistent failure isolated to one department. The gateway pools and reuses connections, so hitting a hard concurrent limit that only affects finance users is unlikely. This does not explain the department-specific pattern.

A
The finance users lack the necessary permissions on the SQL Server database.
Why it fails: If finance users lacked SQL Server permissions, the error would typically be an authentication or access-denied message from SQL Server, not a generic inability to reach the data source. The gateway connection uses stored credentials, so individual database permissions are less likely to produce a reachability error.
B
The gateway is installed on a machine that is turned off during finance working hours.
Why it fails: If the gateway machine were offline, all users including IT would experience failures, not just finance. A time-based outage would also affect IT users who work the same hours. The selective failure by department points to a permission issue rather than gateway availability.
C
The finance users have not been granted access to the on-premises data gateway connection.
On-premises data gateway connections have their own user list separate from the gateway itself. If finance users are not added as users of the specific connection, their apps cannot use it, producing a data source unreachable error. IT users were likely added, explaining why only they succeed.
D
The SQL Server database has reached its maximum number of concurrent connections.
Why it fails: A connection limit would cause intermittent or global failures, not a consistent failure isolated to one department. The gateway pools and reuses connections, so hitting a hard concurrent limit that only affects finance users is unlikely. This does not explain the department-specific pattern.

Question 5hardmultiple choice

You are troubleshooting a Power Automate flow that uses an HTTP action to call a REST API. The flow fails with a '429 Too Many Requests' error. The API has a rate limit of 100 requests per minute. Which strategy should you implement to handle this error gracefully?

Trap 1: Increase the flow's concurrency setting to process more requests…

Raising concurrency sends requests in parallel, exhausting the 100-per-minute quota sooner and worsening the 429 responses. Concurrency tuning suits high-volume flows against APIs without tight limits, but graceful handling here requires retry-after delays or throttling to stay within the rate limit.

Trap 2: Use a 'Condition' action to check the status code and ignore 429…

Ignoring 429 responses discards the call without retrying, so the API request never completes and data is lost. Condition actions are appropriate for branching on business logic, but rate limiting demands honouring the Retry-After header and reissuing the request after a delay, not suppressing the error.

Trap 3: Use the 'Configure Run After' option to skip the action on failure.

Skipping the action on failure abandons the API call permanently, leaving downstream steps without the response data. Configure Run After is designed for optional or non-critical steps, but a rate-limited call must be retried after the Retry-After interval so the request eventually succeeds.

A
Implement retry logic with exponential backoff in the HTTP action settings.
Exponential backoff spaces retries progressively, so the flow waits out the 100-requests-per-minute window rather than hammering the API. This satisfies the rate-limit constraint by letting the HTTP action retry after throttling clears, avoiding repeated 429 failures.
B
Increase the flow's concurrency setting to process more requests simultaneously.
Why it fails: Raising concurrency sends requests in parallel, exhausting the 100-per-minute quota sooner and worsening the 429 responses. Concurrency tuning suits high-volume flows against APIs without tight limits, but graceful handling here requires retry-after delays or throttling to stay within the rate limit.
C
Use a 'Condition' action to check the status code and ignore 429 errors.
Why it fails: Ignoring 429 responses discards the call without retrying, so the API request never completes and data is lost. Condition actions are appropriate for branching on business logic, but rate limiting demands honouring the Retry-After header and reissuing the request after a delay, not suppressing the error.
D
Use the 'Configure Run After' option to skip the action on failure.
Why it fails: Skipping the action on failure abandons the API call permanently, leaving downstream steps without the response data. Configure Run After is designed for optional or non-critical steps, but a rate-limited call must be retried after the Retry-After interval so the request eventually succeeds.

Question 6mediummulti select

Which THREE of the following are features of Power Automate that help manage and monitor flows?

Trap 1: Solution checker

Solution checker validates solution packages for Dataverse and Power Apps artefacts, not individual flow run health or monitoring. It is tempting because it sounds like a flow diagnostic, and would be correct when packaging components into a solution before deployment to another environment.

Trap 2: Flow checker

Flow checker flags design errors such as missing required parameters inside the flow designer, but it does not provide run history, analytics, or alerting for monitoring. It is tempting because its name suggests oversight, and would be correct when validating a flow's configuration before saving.

A
Solution checker
Why it fails: Solution checker validates solution packages for Dataverse and Power Apps artefacts, not individual flow run health or monitoring. It is tempting because it sounds like a flow diagnostic, and would be correct when packaging components into a solution before deployment to another environment.
B
Flow checker
Why it fails: Flow checker flags design errors such as missing required parameters inside the flow designer, but it does not provide run history, analytics, or alerting for monitoring. It is tempting because its name suggests oversight, and would be correct when validating a flow's configuration before saving.
C
Run history
Run history records each flow execution, showing trigger time, duration, and per-action inputs and outputs, including failures. This satisfies the monitoring requirement by letting makers diagnose why a run failed and confirm whether it succeeded, rather than merely designing or triggering flows.
D
Alerts
Alerts notify flow owners when a run fails or a connector degrades, satisfying the stem's monitoring requirement. Unlike run history, which requires manual inspection, alerts push exception notifications automatically, enabling prompt remediation of failed flows without constant dashboard checking.
E
Flow analytics
Flow analytics provides built-in dashboards tracking run history, success and failure rates, and usage trends across individual flows and environments. This satisfies the monitoring constraint in the stem, letting makers and admins review performance metrics without exporting data, complementing management features like the Power Automate portal's run history.