Refer to the Exhibit Practice Questions

The folder path is set to 'Inbox' but the email was moved to a different folder.

Why it fails: Folder path affects which mailbox folder is monitored, not the importance or attachment filters. Emails with attachments in the Inbox would still trigger if those conditions matched. This would be correct if the flow monitored a subfolder while messages arrived elsewhere, such as a rule-moved folder.

The trigger requires attachments, so emails without attachments are ignored.

Why it fails: The trigger's attachment condition is satisfied by these emails, so it cannot explain the failure; the stem's emails all have attachments. Attachment filtering is genuinely useful when you want to act only on mail carrying files, which is a valid design in other flows.

The trigger is set to 'When a new email arrives' but the email is already read.

Why it fails: Read status is unrelated: the flow fails on unread high-importance mail lacking the importance flag, and the trigger fires on arrival regardless. The read/unread distinction matters only when a flow must process previously opened messages.

The environment creation failed

Why it fails: The provisioningState is 'Succeeded', indicating success.

The environment has no security group assigned

Why it fails: A security group is assigned (ContosoUsers).

The environment is a personal productivity environment

Why it fails: The environment is the default environment, not a personal one.

When an email with an attachment arrives

Why it fails: The trigger fires on message arrival regardless of attachment presence; attachment handling would need a separate condition or property check. It is tempting because attachments often drive flows, but the JSON specifies only the arrival event, with no attachment filter in the trigger inputs.

When a high-importance email arrives

Why it fails: High importance is a message property, not the trigger's firing condition; the flow starts for every arriving email. It is tempting because importance filters are common, but the JSON defines arrival as the event, so no importance threshold is applied.

When an email is modified in the Inbox

Why it fails: The trigger fires on a new email arriving, not on modification of an existing item. Modified-item triggers exist for SharePoint and Dataverse, not the Outlook mail trigger. This would be correct if the JSON specified a 'When an existing email is modified' trigger with the Inbox folder.

The Office 365 connector is conflicting with the SQL connector.

Why it fails: Multiple connectors can coexist in a flow without conflict.

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.

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

Why it fails: All Azure regions support on-premises data gateways.

Add the credentials to the JSON configuration and redeploy

Why it fails: Embedding credentials in the JSON configuration and redeploying is not how Power BI stores data source secrets; credentials belong in the gateway or cloud connection settings, not the dataset definition. This would be the correct approach only for non-sensitive parameters, not authentication secrets.

Set the data source privacy level to Organizational

Why it fails: Privacy levels govern how Power Query combines data across sources, not whether credentials exist. The refresh error names missing data source credentials, which privacy settings cannot supply. Setting privacy levels would be the right step when data combination behaviour triggers formula firewall errors, not authentication failures.

Change the connection string to use SQL Server authentication

Why it fails: Switching to SQL Server authentication changes the authentication method, but the error states credentials are absent from the dataset configuration entirely. Supplying credentials is the required fix. SQL authentication would be the correct choice where the source rejects Windows integrated authentication and a database login is expected.

The database server has insufficient memory

Why it fails: Insufficient memory is not evidenced by the snapshot; the exhibit must show the actual contention or blocking delaying the report. It is tempting because memory pressure causes paging and slow queries, and would be correct if the snapshot showed low page life expectancy or heavy memory waits.

The SELECT query (SPID 55) is performing a table scan

Why it fails: A table scan alone does not explain the slowness; the snapshot must show the blocking or high-cost operation actually delaying the report. It is tempting because scans often indicate missing indexes, and would be correct if the exhibit showed that query consuming disproportionate reads or CPU.

The sleeping session (SPID 54) is using too much CPU

Why it fails: A sleeping session is idle, consuming no CPU, so it cannot cause the report's slowness. It is tempting because a session holding locks while sleeping can block others, which would be correct if the exhibit showed that session blocking the report's query.

Triggers when a .csv file is created in the 'Incoming' folder.

Why it fails: The trigger fires on file creation regardless of extension, so it cannot restrict execution to .csv files. Filtering by extension requires a condition or trigger setting. It would be correct if the exhibit included a file type or extension parameter limiting the trigger to comma-separated files.

Triggers when any file is created in the 'Incoming' folder.

Why it fails: The trigger monitors a specific folder, so it fires only for files created in 'Incoming', not any folder. The stem's wording overstates the scope. It would be correct if the exhibit omitted the folder path and monitored an entire drive or site library.

Triggers when a file is modified in the 'Incoming' folder.

Why it fails: The stem's trigger definition specifies a SharePoint or OneDrive event, not a folder-watch condition; 'Incoming' folder monitoring is not what the exhibit declares. It tempts because folder-based file triggers exist for SharePoint and OneDrive, and would be correct if the flow watched a named document library folder.

All connectors are allowed

Why it fails: Connectors placed in the Blocked group cannot be used in the environment, so a policy that blocks any connector cannot leave everything allowed. Allowing all connectors is what happens when no DLP policy is applied to the environment, or when every connector is assigned to the Business or Non-business group.

All connectors are blocked

Why it fails: A DLP policy assigns connectors to Blocked, Business, or Non-business groups; connectors omitted from every group remain allowed by default, so this outcome requires every connector to be explicitly listed as Blocked. Blocking all connectors is the intended result only when an organisation wants to prohibit all Power Platform connectivity outright.

The policy applies to all environments

Why it fails: DLP policies are scoped to selected environments, and a policy applied to the default environment affects only that environment unless explicitly extended. It is tempting because tenant-wide governance is a real goal, but that requires adding each environment to the policy's scope, not applying it to one.

A SQL Server table named Accounts

Why it fails: The manifest declares the data source as Microsoft Dataverse, entity accounts, so the gallery binds to that Dataverse table. A SQL Server table would appear as a SQL connector data source, which this JSON does not reference.

A SharePoint list named SalesData

Why it fails: The manifest declares the gallery's items as Filter(SalesData, ...) where SalesData maps to the Microsoft Dataverse accounts entity, not SharePoint. SharePoint lists are the source when the connector type is SharePoint and a site/list is bound, which this snippet does not show.

The raw Dataverse Accounts entity

Why it fails: The gallery's Items property applies Filter(SalesData, status = 'Active'), so it binds to a filtered subset of active account records, not the unfiltered entity. The raw Accounts entity is tempting because SalesData points at Dataverse accounts, and an unfiltered gallery would legitimately use that entity as its source.

The display-name-key is missing a translation

Why it fails: The display-name-key supplies the localised label shown in the maker interface; a missing translation affects only the visible name, not the control's runtime data binding. It is tempting because localisation errors are common in PCF manifests, but they never stop the control receiving or rendering dataset records.

The version number is incorrect

Why it fails: The version number governs solution upgrade and import behaviour; an incorrect value can block import or trigger an upgrade prompt, but once the control loads it still binds and renders data. It is tempting because version mismatches cause deployment failures, yet the stem states the control already appears.

The namespace is misspelled

Why it fails: A misspelled namespace breaks the manifest-to-code binding, so the control renders but its data methods never execute, leaving the display empty. It is tempting because namespace errors are a common PCF packaging fault, yet a wrong namespace typically prevents the control loading at all rather than showing blank data.

The portal URL must be changed to use Microsoft Entra ID.

Why it fails: 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 portal location must be in a region that supports Microsoft Entra ID.

Why it fails: 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 fails: 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.

The environment name parameter contains invalid characters.

Why it fails: Invalid characters in the environment name trigger a naming-validation error on that parameter, not an unsupported-resource-type message, so this cannot be the cause. It is tempting because naming rules do fail deployments; it would be correct if the error cited the name property, not the resource provider.

The environmentSku 'Production' is not a valid SKU.

Why it fails: An invalid SKU value produces a validation error naming the SKU property, not an unsupported-resource-type message, so this cannot explain the failure. It is tempting because SKU mistakes do break deployments; it would be correct if the error cited environmentSku, but the stem's error concerns resource provider registration.

The location parameter is set to an unsupported region.

Why it fails: An unsupported region yields a location or region-not-available error, not a resource-type-not-supported message, so this is not the cause. It is tempting because region mismatches do fail deployments; it would be correct if the error referenced the location parameter rather than the Microsoft.PowerApps resource type itself.

Total sales for the current year.

Why it fails: A measure returning current-year sales would filter the date table with YEAR or DATESYTD; the exhibit's expression aggregates a different column or time context, so its result diverges from that figure. It is tempting because year-to-date totals are a common DAX pattern, and such a measure would be right if the formula actually applied a current-year filter.

Running total of sales up to the selected year.

Why it fails: The measure aggregates sales across the entire year context rather than accumulating from the start of the period to the selected year, so it returns an annual total, not a running total. Running totals are tempting because cumulative patterns are common in DAX, but they require FILTER with ALLSELECTED or similar.

Year-over-year growth percentage.

Why it fails: The measure sums sales for the current year context without comparing against a prior-year baseline, so no growth ratio is produced. Year-over-year growth is tempting because it is a frequent DAX pattern, but it requires SAMEPERIODLASTYEAR or DATEADD plus a division to compute the percentage change.

The recurrence schedule is incorrectly formatted.

Why it fails: A malformed recurrence string would prevent the flow from ever triggering, yet the stem states it ran previously and stopped a week ago, so the schedule format itself was already valid. Recurrence formatting is the right focus when building a new flow that never fires at all.

The SharePoint site URL is invalid.

Why it fails: An invalid SharePoint site URL would cause the flow to fail at run time, and Power Automate records that failure in run history, so the schedule would still trigger. It is tempting because connection errors break flows, but a flow that never runs points to the recurrence trigger being disabled or the owner's credentials expiring.

The flow is in a 'Stopped' state.

Why it fails: Flows in Power Automate do not have a standalone 'Stopped' state. They are either turned on or off. The term 'Stopped' might refer to being turned off, but the proper term is 'Off', and option B is more specific and accurate.

Filter(Accounts, 'Active')

Why it fails: Filter requires a logical expression, not a bare string; 'Active' is passed as the condition itself, so no comparison against the Status column occurs. It is tempting because Filter's first argument is the data source, and Accounts is correctly placed there — that pattern would be right if the second argument were a boolean predicate.

Filter('Active', Accounts)

Why it fails: The arguments are reversed: Filter expects the data source first and the predicate second, so 'Active' is treated as the table and Accounts as the condition. It is tempting because both required elements appear, and swapping them would be correct if 'Active' named a collection of records to filter.

Filter(Status = 'Active', Accounts)

Why it fails: The predicate is placed first and the data source second, so Filter receives a boolean where a table is expected. It is tempting because the comparison Status = 'Active' is exactly the right condition, and would be correct if written as the second argument after Accounts.