Demonstrate the capabilities of Power Automate →hardMultiple Choice

PL-900 Practice Question: Demonstrate the capabilities of Power Automate

Exhibit

{
  "definition": {
    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
    "actions": {
      "Send_approval_email": {
        "type": "ApiConnection",
        "inputs": {
          "host": {
            "connectionName": "shared_office365",
            "operationId": "SendEmail"
          },
          "parameters": {
            "to": "manager@contoso.com",
            "subject": "Approve request",
            "body": "Please approve."
          },
          "authentication": "@parameters('$authentication')"
        },
        "runAfter": {}
      }
    },
    "triggers": {
      "manual": {
        "type": "Request",
        "kind": "Http",
        "inputs": {
          "schema": {}
        }
      }
    }
  }
}

Refer to the exhibit. This Power Automate flow is triggered manually via HTTP request. The action 'Send_approval_email' sends an email. What is a potential issue with this flow design?

⚠ Common exam trap

PL-900 often tests whether candidates recognize that sending an email is not the same as requesting an approval — the Approvals connector is a distinct, purpose-built action, and naming a flow 'Send_approval_email' does not make it an approval flow.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The flow does not include an approval action, only an email notification.

The flow is named 'Send_approval_email' and the question states it sends an email, but the design only performs a notification action rather than using Power Automate's dedicated Approvals connector (Start and wait for an approval). Without an approval action, the flow cannot capture an approve/reject decision or branch on the outcome, so it fails to fulfill its stated purpose. The HTTP request trigger is valid, authentication is a separate concern, and the email action is not deprecated.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The manual trigger cannot be used for HTTP requests.
Why it's wrong here
The manual trigger includes an HTTP request variant, so flows can be invoked via a URL. This option misstates the trigger's capability; the real concern is that the approval email action pauses the flow awaiting a response, which may not suit a synchronous HTTP caller.
✗
The authentication parameter is missing.
Why it's wrong here
Authentication is configured on the HTTP request trigger itself, and the stem does not indicate it is absent. The genuine design issue is that Send_approval_email blocks execution until a recipient responds, delaying the HTTP response returned to the caller.
✓
The flow does not include an approval action, only an email notification.
Why this is correct
The 'Send_approval_email' action only notifies recipients; it does not itself capture a decision. Without a dedicated approval action such as 'Start and wait for an approval', the flow cannot receive or act on a response, so the design lacks the actual approval mechanism the process requires.
✗
The email action uses deprecated parameters.
Why it's wrong here
The approval email action's parameters are current, not deprecated, so this check is irrelevant. The actual problem is that the action suspends the flow until an approver responds, which can exceed the HTTP request timeout for the calling client.

Go deeper

PL-900 Practice Question: Demonstrate the capabilities of Power Automate

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question