Troubleshooting practice questions

You are troubleshooting a failed flow run. Where do you find the specific input and output data for each action?

Trap 1: In the Flow Designer

Flow Designer is the authoring canvas for building and editing the flow; it shows the design, not runtime execution data. It is tempting because actions are visible there, but input and output values from a specific run appear in the run history instead.

Trap 2: In the environment logs

Environment logs capture solution-level events and errors, not per-action inputs and outputs. It is tempting because logs aid troubleshooting, but action-level input and output data appear in the flow run history, where each action's execution details are recorded.

Trap 3: In the Solution history

Solution history records solution-level component changes and publishing events, not per-action run data. The run history's action detail pane exposes each action's inputs and outputs. Solution history is tempting when auditing what changed in the solution, which is a governance scenario rather than flow debugging.

A
In the Flow Designer
Why it fails: Flow Designer is the authoring canvas for building and editing the flow; it shows the design, not runtime execution data. It is tempting because actions are visible there, but input and output values from a specific run appear in the run history instead.
B
In the Run history
Run history records each flow run's action-level inputs and outputs, including the exact payloads passed between steps. Opening the failed run and expanding each action reveals the specific data, which is what troubleshooting requires; the designer only shows configuration, not runtime values.
C
In the environment logs
Why it fails: Environment logs capture solution-level events and errors, not per-action inputs and outputs. It is tempting because logs aid troubleshooting, but action-level input and output data appear in the flow run history, where each action's execution details are recorded.
D
In the Solution history
Why it fails: Solution history records solution-level component changes and publishing events, not per-action run data. The run history's action detail pane exposes each action's inputs and outputs. Solution history is tempting when auditing what changed in the solution, which is a governance scenario rather than flow debugging.

Question 2hardmulti select

Which TWO of the following represent advanced flow error handling? (Choose TWO)

Trap 1: Delete failed runs immediately

Deleting failed runs destroys the diagnostic history that error handling depends on, preventing investigation of what failed and why. It is tempting because clearing clutter keeps the run list tidy, and retention policies would be correct for managing storage, not for handling errors as they occur.

Trap 2: Stop using variables

Removing variables discards the state needed to capture error details, retry counts or branch outcomes, so failures cannot be logged or routed. Variables are tempting because poorly scoped ones cause confusion, and they would be the right tool when configuring retry logic or storing error messages for later actions.

Trap 3: Add a comment to each action

Comments are inert documentation; they execute nothing and cannot catch, log, retry or route a failure. Annotating actions is tempting because it aids maintainers reading the flow later, and comments would be the right choice when documenting intent or explaining complex expressions to colleagues.

A
Delete failed runs immediately
Why it fails: Deleting failed runs destroys the diagnostic history that error handling depends on, preventing investigation of what failed and why. It is tempting because clearing clutter keeps the run list tidy, and retention policies would be correct for managing storage, not for handling errors as they occur.
B
Use the 'Try-Catch' pattern via Scopes
Scopes group actions into Try and Catch blocks, so a failure inside the Try scope is caught and handled by the Catch scope's actions. This satisfies the advanced error-handling requirement by centralising failure logic instead of configuring conditions on every individual action.
C
Stop using variables
Why it fails: Removing variables discards the state needed to capture error details, retry counts or branch outcomes, so failures cannot be logged or routed. Variables are tempting because poorly scoped ones cause confusion, and they would be the right tool when configuring retry logic or storing error messages for later actions.
D
Configure run after
Configure run after defines dependency conditions on an action, letting it execute only when a prior action succeeds, fails, is skipped or times out. This satisfies the advanced error-handling requirement by branching the flow down a recovery path when the main action fails.
E
Add a comment to each action
Why it fails: Comments are inert documentation; they execute nothing and cannot catch, log, retry or route a failure. Annotating actions is tempting because it aids maintainers reading the flow later, and comments would be the right choice when documenting intent or explaining complex expressions to colleagues.

Question 3hardmulti select

Which TWO actions should you take when troubleshooting a broken data connection in a canvas app?

Trap 1: Reinstall the browser

Reinstalling the browser replaces client software unrelated to the app's connector configuration, credentials or gateway, so the broken connection remains. It is tempting because browser-level faults can break sign-in, and reinstalling would be correct only when a corrupted browser profile is demonstrably blocking authentication, not for canvas app data connections.

Trap 2: Delete the app

This is a destructive, unnecessary action.

Trap 3: Rename the app

Renaming does not fix connectivity.

A
Reinstall the browser
Why it fails: Reinstalling the browser replaces client software unrelated to the app's connector configuration, credentials or gateway, so the broken connection remains. It is tempting because browser-level faults can break sign-in, and reinstalling would be correct only when a corrupted browser profile is demonstrably blocking authentication, not for canvas app data connections.
B
Delete the app
Why it fails: This is a destructive, unnecessary action.
C
Rename the app
Why it fails: Renaming does not fix connectivity.
D
Verify the connection status in the Data pane
The Data pane lists every data source the canvas app references and shows whether each connection is currently connected or broken. Inspecting it satisfies the stem's troubleshooting requirement by isolating which connector has failed before investigating credentials or permissions.
E
Check the user's security role
Canvas app data connections run under the signed-in user's identity, so a missing or misconfigured security role in the underlying data source blocks access even when the connector itself is healthy. Checking the role satisfies the stem's troubleshooting requirement by ruling out authorisation as the cause.

Question 4hardmultiple choice

You are troubleshooting a form in a model-driven app. The field is read-only even though the user has 'Write' permissions. What is the most likely cause?

Trap 1: The app icon

The app icon is purely presentational metadata in the app designer and has no bearing on record or field permissions. A read-only field persists regardless of icon configuration. The cause lies in field-level security profiles or business rules that override the table-level Write privilege.

Trap 2: The browser cache

Browser cache affects stale rendering of scripts and metadata, not field-level editability, which the platform enforces server-side from form and field configuration. Clearing cache would not restore write access. A read-only field typically stems from a field-level security profile or a business rule locking the control.

Trap 3: The user's password

An incorrect password blocks authentication entirely, producing a sign-in failure rather than a rendered form with a read-only field. The user is already authenticated and holding Write privilege, so credentials are not the constraint. Field-level security or a business rule governs editability here.

A
The app icon
Why it fails: The app icon is purely presentational metadata in the app designer and has no bearing on record or field permissions. A read-only field persists regardless of icon configuration. The cause lies in field-level security profiles or business rules that override the table-level Write privilege.
B
The browser cache
Why it fails: Browser cache affects stale rendering of scripts and metadata, not field-level editability, which the platform enforces server-side from form and field configuration. Clearing cache would not restore write access. A read-only field typically stems from a field-level security profile or a business rule locking the control.
C
The user's password
Why it fails: An incorrect password blocks authentication entirely, producing a sign-in failure rather than a rendered form with a read-only field. The user is already authenticated and holding Write privilege, so credentials are not the constraint. Field-level security or a business rule governs editability here.
D
Field security profile configuration
Field-level security profiles restrict individual columns independently of table-level Write privileges. If the field is included in a field security profile where the user lacks Update permission, it renders read-only on forms regardless of their broader Write access, which is the constraint described in the stem.

Question 5hardmulti select

When troubleshooting a failed Power Automate flow, which TWO areas should you inspect to identify the root cause?

Trap 1: The Power Apps Studio version history.

Power Apps Studio version history tracks canvas app changes, not flow run data, so it holds no trigger history, action inputs or outputs needed to trace a failure. It is tempting because version history does support rollback and comparison, which is the right tool when a published app regresses after an edit.

Trap 2: The Office 365 Admin Center.

The Office 365 Admin Center reports tenant-level service health and licence assignment, not individual flow execution. It is tempting as a central Microsoft portal, but diagnosing a failed flow requires the flow's run history and the connector or action error details shown in Power Automate.

Trap 3: The AI Hub logs.

AI Hub logs record model, prompt and endpoint telemetry, not Power Automate run history. Diagnosing a failed flow requires the run history and trigger outputs plus the action-level inputs and outputs, which is where the failing connector call and its error code actually appear.

A
Run history of the flow.
The run history records each action's inputs, outputs and error codes, so it pinpoints the exact failing step and its message. Inspecting it satisfies the stem's need to identify the root cause rather than merely confirming the flow failed.
B
The Power Apps Studio version history.
Why it fails: Power Apps Studio version history tracks canvas app changes, not flow run data, so it holds no trigger history, action inputs or outputs needed to trace a failure. It is tempting because version history does support rollback and comparison, which is the right tool when a published app regresses after an edit.
C
The Office 365 Admin Center.
Why it fails: The Office 365 Admin Center reports tenant-level service health and licence assignment, not individual flow execution. It is tempting as a central Microsoft portal, but diagnosing a failed flow requires the flow's run history and the connector or action error details shown in Power Automate.
D
The AI Hub logs.
Why it fails: AI Hub logs record model, prompt and endpoint telemetry, not Power Automate run history. Diagnosing a failed flow requires the run history and trigger outputs plus the action-level inputs and outputs, which is where the failing connector call and its error code actually appear.
E
Flow Checker for design-time issues.
Flow Checker analyses the flow definition statically, flagging malformed expressions, missing required connections and invalid schema references before or after a run. Inspecting it isolates design-time faults, which is one of the two areas the troubleshooting scenario requires.