hardMultiple Choice

PL-900 Practice Question: Refer to the exhibit

Exhibit

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.PowerPlatform/portals",
      "apiVersion": "2022-03-01-preview",
      "name": "myPortal",
      "location": "[resourceGroup().location]",
      "properties": {
        "displayName": "My Portal",
        "portalUrl": "https://myportal.powerappsportals.com",
        "authentication": {
          "provider": "Local"
        }
      }
    }
  ]
}

Refer to the exhibit. You are deploying a Power Pages site using an ARM template. After deployment, you find that the portal uses local authentication, but you need it to use Microsoft Entra ID. What is the most likely reason the authentication provider is not set correctly?

⚠ Common exam trap

PL-900 often tests whether candidates know that portal authentication is configured through identity provider settings in the deployment template, so the trap is choosing a plausible-sounding but irrelevant factor like region or URL.

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 'authentication' property should be 'identityProviders' with the correct configuration.

When deploying a Power Pages site via ARM template, the authentication configuration is driven by the 'identityProviders' property in the site's configuration, not a generic 'authentication' property. If the template specifies local authentication or omits the Entra ID provider block, the portal defaults to local auth. Correcting the template to declare the Entra ID identity provider with the proper client ID, tenant, and metadata resolves the issue.

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 portal URL must be changed to use Microsoft Entra ID.
Why it's wrong here
Changing the portal URL has no bearing on which identity provider is configured; authentication settings are defined by site settings and the portal's identity provider records, not its address. It is tempting because the URL does appear in redirect URIs registered in Microsoft Entra ID, but that registration is a consequence of configuration, not its cause.
✓
The 'authentication' property should be 'identityProviders' with the correct configuration.
Why this is correct
ARM deployments of Power Pages read the identityProviders property to set authentication; supplying an 'authentication' property instead leaves the default local provider in place. Correcting the property name and its Microsoft Entra ID configuration resolves the mismatch described in the stem.
✗
The portal location must be in a region that supports Microsoft Entra ID.
Why it's wrong here
Microsoft Entra ID authentication is available in every Power Pages region, so the deployment region never determines the provider. It is tempting because some Power Platform services have regional feature gaps, making region a plausible culprit, but the actual cause lies in the ARM template's authentication site settings, not geography.
✗
The portal only supports local authentication when deployed via ARM.
Why it's wrong here
ARM-deployed Power Pages sites support Microsoft Entra ID, OpenID Connect and other providers exactly as portal-deployed ones do; the deployment method does not restrict authentication. It is tempting because ARM templates require explicit configuration of identity provider records, which are easy to omit, but the platform itself imposes no such local-only limitation.

Visual reference

Go deeper

PL-900 Practice Question: Refer to the exhibit

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question