Demonstrate the capabilities of Power Automate practice questions

Use parallel branches for each row

Why it fails: Incorrect. Parallel branches would still cause issues if one fails.

Use an apply to each loop with default settings

Why it fails: Incorrect. Default settings stop on failure.

Use a scope with sequential actions and set 'Configure run after' to 'is successful' only

Why it fails: Incorrect. This would stop on first failure.

Parallel branches

Why it fails: Incorrect. 'Parallel branches' are for concurrent execution, not error handling.

Try-catch-finally pattern using scopes

Why it fails: Incorrect. The 'Try-catch-finally pattern' is a design pattern implemented using scopes and 'Configure run after', but it is not a native built-in error handling option.

The SharePoint trigger did not fire

Why it fails: Incorrect. The log shows the trigger fired and action ran.

The scope 'SendNotification' failed due to a missing variable

Why it fails: Incorrect. The error is about mail server, not variables.

The SharePoint list permissions are incorrect

Why it fails: Incorrect. The trigger succeeded, so permissions are fine.

Split the flow into two: one for the SharePoint trigger and one for the CDS update, and trigger the second via HTTP request.

Why it fails: Splitting the flow adds complexity and does not address the timeout on the CDS action; the underlying timeout issue remains.

Restart the CDS environment to clear any temporary issues.

Why it fails: Restarting is disruptive and unlikely to resolve a persistent timeout; the issue is more likely due to timeout settings.

Reduce the concurrency setting to 1 to prevent multiple simultaneous requests.

Why it fails: Reducing concurrency may reduce load but won't fix the underlying timeout issue; the CDS action still has a limited timeout.

Creating a file in SharePoint whenever a new file is uploaded to a OneDrive folder

Why it fails: This is an event-driven scenario best handled by an automated flow.

Sending an approval request to a manager when a new expense report is submitted

Why it fails: Sending an approval request when a new expense report is submitted requires an **instant trigger** (e.g., "When a new item is created" in SharePoint or Dataverse) that fires immediately upon data creation, not a scheduled trigger that runs at a fixed time. A scheduled cloud flow would only check for new submissions at intervals, introducing unacceptable delays. This option is tempting because scheduled flows are commonly used for periodic batch approvals (e.g., daily review of all pending reports), but the stem demands real-time, event-driven initiation.

Sending a welcome email to a new user immediately after they sign up

Why it fails: This requires an instant trigger, such as when a new user is created in Microsoft Entra ID.

The filter condition 'statecode eq 0' is invalid

Why it fails: statecode eq 0 is a valid filter for open opportunities.

The recurrence trigger is incorrectly configured

Why it fails: The recurrence trigger is correctly set to daily.

The connections to Dataverse and Office 365 are not established

Why it fails: The connections are referenced but the error is not about missing connections.

Power Apps per user plan: A user can run only one specific app.

Why it fails: Incorrect — this describes the per app plan, not the per user plan.

Power Apps for Office 365: A user can run unlimited custom apps with premium connectors.

Why it fails: Incorrect — the Office 365 plan does not include premium connectors and has usage limits.

The flow requires a premium Power Automate license.

Why it fails: SharePoint triggers and standard approval actions are included in seeded licences, so premium licensing would not selectively block some runs. Premium applies when flows use custom connectors or premium connectors, which this scenario does not mention.

The user does not have permission to view the SharePoint list.

Why it fails: Users lacking list permissions cannot create items, so no trigger fires at all rather than intermittently. Permission failures produce consistent, total absence of runs; the intermittent pattern points to a condition inside the flow, not access rights.

The flow has a 'Delay' action before the approval step.

Why it fails: A Delay action postpones the approval but does not prevent it from eventually running, so approvals would arrive late, not fail. Delays are correct when throttling or spacing notifications is required, not when triggers are being missed.

When a user is deleted (Microsoft Entra ID)

Why it fails: A deletion trigger fires when accounts are removed, so new users never start the flow and no welcome email is sent. It is tempting because both triggers sit in the same Microsoft Entra ID connector, but provisioning automation requires the corresponding creation trigger, not its removal counterpart.

When a user is added to a group

Why it fails: Incorrect. This trigger fires when a user is added to a group, not when a new user is created.

When a user is modified (Microsoft Entra ID)

Why it fails: A welcome email must fire when a user is created, but this trigger fires on updates to an existing user, so new accounts never invoke it. It suits scenarios reacting to attribute changes, such as licence reassignment or department moves, not onboarding.

The 'email/To' parameter is missing the recipient's email.

Why it fails: A missing recipient address would cause the send action to fail outright, and the flow's condition would then branch to rejection, not approval. It is tempting because misconfigured To fields are a common cause of failed approval mails, and would be correct if the symptom were non-delivery rather than the wrong branch executing.

The condition expression is incorrectly formatted.

Why it fails: A malformed condition expression would throw a runtime error or evaluate unpredictably, not consistently return true regardless of the send outcome. It is tempting because faulty expressions are a frequent Power Automate defect, and would be correct if the run history showed the condition evaluating incorrectly rather than always taking the success path.

The 'body' function should be 'outputs' instead.

Why it fails: The body() function reads the response payload, while outputs() returns action metadata; swapping them would break the condition's data reference, not force it to true. It is tempting because body() versus outputs() confusion is a genuine Power Automate pitfall, and would be correct if the condition needed the action's status rather than its content.

Use the 'Get changes' action for the sensor data.

Why it fails: The 'Get changes' action retrieves changes for a specific entity (like a SharePoint list or OneDrive folder) and does not apply to sensor data or prevent duplicate alerts.

Increase the threshold value so alerts are less frequent.

Why it fails: Increasing the threshold would only reduce the number of alerts by making the condition harder to meet, but it does not address the duplicate alert problem for a single threshold-breaching event.

Add a 'Delay' action of 5 minutes before sending the alert.

Why it fails: Adding a 'Delay' action of 5 minutes would postpone alerts but not prevent duplicates; multiple requests within the delay period would still generate separate delayed alerts.

The SharePoint folder path is incorrect.

Why it fails: An incorrect folder path typically produces a 'Folder not found' or 404 error from SharePoint, not InvalidTemplate. InvalidTemplate indicates malformed expression syntax or a type mismatch in the flow definition; a wrong path would be the cause when SharePoint returns a not-found response.

The trigger is not set to include attachments.

Why it fails: Attachment inclusion is a trigger setting that filters whether the flow runs at all; it cannot produce an InvalidTemplate error, which arises from malformed expressions or mismatched action inputs. It tempts because trigger conditions genuinely control attachment handling, and would be the fix if the flow simply never fired on emails carrying files.

The file name is taken from the email subject instead of the attachment.

Why it fails: The subject is a valid string, so referencing it as a filename cannot itself raise InvalidTemplate; the error stems from an expression or schema mismatch, such as a missing attachment array reference. It tempts because naming files from subjects is a common design, and would be correct if the flow ran but produced wrongly named documents.

Enable 'Retry policy' on an action to automatically retry on failure

Why it fails: This is incorrect. 'Retry policy' is a configuration option on an action, not a separate action available in Power Automate. The correct three are A, B, and E.

Use the 'if' function in expressions to check for errors

Why it fails: The 'if' function is used in expressions but is not an action for error handling.

SQL Server

Why it fails: SQL Server is a premium connector, so it is unavailable without a premium licence. It is the correct selection when the environment holds premium licences and you need direct on-premises or Azure SQL data access.

Azure Blob Storage

Why it fails: Azure Blob Storage requires a premium Power Automate licence, so it cannot be one of the two standard connectors. It is tempting because it genuinely integrates with Power Automate for reading, writing and managing blobs, and would be the right choice when a flow must store or retrieve unstructured files in Azure storage.

Salesforce

Why it fails: Salesforce requires a premium connector, so it cannot be used under a standard licence. It is tempting because Salesforce is a widely used CRM and appears in many Power Automate templates, but those templates consume premium capacity. It would be the right choice only when the tenant holds premium licences and the flow must read or write Salesforce records.

Switch

Why it fails: Switch is also possible but is not the only option; condition is more common for simple if-else.

Compose

Why it fails: Compose is for creating a single output.

Select

Why it fails: Select is for transforming arrays.

Apply to each

Why it fails: 'Apply to each' is for iterating over arrays.

Use a 'When an item is created' trigger with a condition on Score > 50 and Status = 'New'. Use 'Send an email' to notify the manager and include a link to a Power Apps approval screen. Use a separate flow triggered by an HTTP request from Power Apps to update the item.

Why it fails: This does not handle the 7-day timeout or automatic reminders.

Use a 'When an item is created' trigger with a condition on Score > 50 and Status = 'New'. Inside the condition, use 'Start and wait for an approval' with a 7-day timeout. After approval, update the item and send email. Use 'Parallel branch' to send a reminder every 2 days by adding a 'Delay' action followed by an email.

Why it fails: Parallel branch with a delay does not repeat every 2 days; it only delays once.

Use a 'Recurrence' trigger that runs every hour, queries the SharePoint list for items with Status = 'New' and Score > 50, then sends an approval request. Use a 'Delay until' action to set a 7-day timeout. Use a 'Compose' action to track reminders.

Why it fails: This approach is less efficient and does not use the built-in approval timeout.

Recreate the connection to Dynamics 365.

Why it fails: 'Invalid template specification' indicates malformed action inputs or an unmapped required field in the Create a task action, not an authentication failure. Recreating the Dynamics 365 connection addresses expired credentials or consent errors, which produce authorisation failures instead.

Change the trigger to 'When a record is updated' instead of created.

Why it fails: Changing the trigger to 'When a record is updated' alters when the flow fires, leaving the malformed Planner action definition untouched, so the same error recurs. Update triggers suit flows reacting to field changes, not correcting invalid action parameters.

Grant the flow service principal Planner permissions.

Why it fails: Permission errors surface as 401 or 403 responses during the action run, not as 'Invalid template specification', which concerns the action's schema. Granting Planner permissions suits access-denied failures where the connection lacks the required scope.

The Office 365 Users connector is not properly configured.

Why it fails: The Office 365 Users connector is not properly configured. This is incorrect because the flow runs successfully, meaning the connector retrieved the manager's information correctly.

The approval action is configured to use the Teams channel instead of email.

Why it fails: The approval action is configured to use the Teams channel instead of email. This is incorrect because whether the approval is sent via Teams or email, it still requires a recipient with a valid mailbox to receive it. The channel does not prevent delivery if the manager lacks a mailbox.

The manager's user profile is missing in Microsoft Entra ID.

Why it fails: The manager's user profile is missing in Microsoft Entra ID. This is incorrect because the 'Get manager' action successfully retrieved the manager's email, so their profile exists.

Verify that the flow trigger is set to 'When a new item is created'.

Why it fails: The trigger already fires on new items, so it cannot explain missing attachments; the attachment content must be passed correctly into the email action. It is tempting because trigger misconfiguration breaks flows, and would be correct if items were never processed at all.

Ensure the SharePoint list has the correct permissions for the flow.

Why it fails: List permissions control whether the flow can read items; if they were insufficient, the trigger or Get item action would fail outright rather than deliver an email missing its attachment. Permissions are the correct check when the flow cannot access the list at all.

Change the email action to 'Send an email with options'.

Why it fails: 'Send an email with options' produces actionable approval messages and carries no attachment parameter, so it cannot attach SharePoint files. It is tempting because it is another Outlook email action, and would be correct when recipients must respond with approve or reject choices.

The flow is disabled or paused.

Why it fails: A disabled flow never executes, so the caller would receive no response or a connection failure, not a 500 returned after the run succeeded. Checking flow state is correct when the trigger produces no run history entries at all.

The external application is not sending the correct JSON payload.

Why it fails: A malformed JSON payload typically causes a 400 Bad Request or a schema validation failure at the trigger, not a 500 returned after the flow has already run successfully. Payload validation is the correct focus when the trigger rejects the request before any action executes.

The flow requires authentication and the API key is missing.

Why it fails: A missing API key produces 401 Unauthorised, not 500; authentication failures are rejected before the flow body executes. It is tempting because the HTTP trigger can require key-based auth, and that configuration is the right answer when callers report 401 responses instead of server-side errors.