Hard Difficulty Questions

Use the 'Peek code' feature to review the flow definition.

Why it fails: 'Peek code' only displays the underlying JSON definition; it exposes no throttling metrics or run history, so it cannot confirm a service protection limit. It is tempting because inspecting the definition helps debug malformed expressions, which is the right scenario for diagnosing a broken action, not throttling.

Check the gateway status for the shared mailbox.

Why it fails: Gateway status concerns on-premises data connectivity, not cloud mailbox throttling, so it reveals nothing about missed emails. It is tempting because gateways genuinely cause failures when a flow reaches on-premises resources, which is the correct scenario for checking gateway health rather than service limits.

Pause the flow and restart it.

Why it fails: Restarting clears transient failures but leaves no record of which runs hit the throttling threshold, so the missed emails stay unexplained. Pausing is tempting because it briefly stops error buildup during an outage, yet the flow's run history already holds the diagnostic evidence needed.

Edit the flow directly in the Production environment.

Why it fails: Direct edits bypass validation.

Create a new flow in Production based on a copy of the Dev flow.

Why it fails: Copying does not enforce validation.

Export the flow as a ZIP file from Dev and import to Production.

Why it fails: Flows are exported as solutions, not ZIPs.

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.

Custom AI model training from scratch

Why it fails: Power Platform's AI Builder consumes prebuilt or custom-trained models; it does not train foundation models from scratch, which requires Azure Machine Learning compute and data science tooling. It is tempting because AI Builder does support custom model training on your own data, but that is narrow, task-specific modelling rather than from-scratch training.

Replacement of all custom coding

Why it fails: Power Platform augments development through low-code connectors, flows and apps; it does not replace custom coding, and pro-code extensions remain necessary for complex logic. It is tempting because makers can build solutions without writing code, but that describes citizen-developer enablement, not the elimination of custom development.

The connection reference is not shared with the users.

Why it fails: Connection references apply to Power Automate flows, not canvas app data connections, so sharing them does not govern who can submit SharePoint items. It is tempting because connection ownership genuinely blocks flow runs, but canvas apps authenticate each user directly against SharePoint.

The SharePoint list has exceeded its item limit.

Why it fails: Exceeding the SharePoint list item limit blocks all users, not a few, and typically surfaces as throttling or view errors rather than 'Access denied'. It is tempting because list limits are a real SharePoint constraint, but the per-user pattern points to individual list permissions instead.

The app is shared with 'Can edit' permission but not 'Can view'.

Why it fails: Sharing an app with only 'Can edit' still grants viewing, so this cannot produce 'Access denied' for some users. App-level sharing permissions are the tempting focus, but the failure lies in each user's own SharePoint list permissions, which the app inherits at runtime.

Migrate the app to a model-driven app

Why it fails: Migrating to a model-driven app would require a significant rewrite and may not address the performance issue caused by inefficient queries.

Replace the app with a Power BI dashboard

Why it fails: Replacing the app with a Power BI dashboard would lose interactive inventory management capabilities and is not a direct performance fix.

Increase the network bandwidth at each store

Why it fails: Increasing network bandwidth could help if bandwidth is the bottleneck, but if the app makes excessive or inefficient data requests, it won't solve the root cause.

The environment creation will fail because 8 GB exceeds the default environment capacity of 5 GB.

Why it fails: Default environment capacity is a tenant default, not a per-environment maximum.

The environment will be created but the user must have a Power Apps license assigned.

Why it fails: Licensing is separate from capacity allocation.

The environment creation will fail because UserAllocation mode requires at least 15 GB.

Why it fails: UserAllocation mode does not impose a minimum capacity requirement.

Configure audit logging and DLP policies individually for each environment

Why it fails: Manual configuration does not auto-apply to new environments.

Create a tenant-level DLP policy that warns users about data transmission

Why it fails: A warning does not block data transmission as required.

Enable audit logging in the Prod environment and create a DLP policy for Dev and Test only

Why it fails: Audit must be in all environments, and DLP must cover all.

PowerShell cmdlets

Why it fails: PowerShell is powerful but not a single graphical interface.

Power Apps Maker Portal

Why it fails: This portal is for makers, not for administration across tenants.

Microsoft 365 admin center

Why it fails: The M365 admin center does not have full Power Platform management.

Delete old audit logs

Why it fails: Audit logs consume storage but may not be the primary issue.

Disable unused plugins

Why it fails: Disabling plugins may affect functionality and doesn't free storage.

Add more storage to the environment

Why it fails: This increases cost rather than freeing space.

Create a support ticket with Microsoft to block regions.

Why it fails: Microsoft does not block regions on request; the admin center provides this control.

Implement capacity limits that prevent creation in disallowed regions.

Why it fails: Capacity limits are not region-specific.

Set the default environment region in tenant settings to the allowed region.

Why it fails: This sets the default but does not block creation in other regions.

Object detection in images

Why it fails: Object Detection is not a prebuilt AI Builder model; it requires custom model training or integration with Azure Cognitive Services, so it is incorrect.

Predictive forecasting

Why it fails: Predictive Forecasting is not an AI Builder feature; it is part of Power BI or other services, so it is incorrect.

Manual trigger (e.g., from a button)

Why it fails: Incorrect. While manual (instant) triggers are a valid type, the question asks for two types and both scheduled and event-based are more commonly paired. Manual triggers are also valid but are not selected here.

Webhook trigger (e.g., from an external service)

Why it fails: Incorrect. Webhooks are a subtype of automated/event-based triggers, not a separate primary type.

Approval trigger (e.g., when an approval is requested)

Why it fails: Incorrect. Approval triggers are a specific type of automated trigger, not a separate primary type.

Power Platform CLI

Why it fails: Power Platform CLI is useful for automating solution management but is not the primary tool for tenant-to-tenant migration of solution components.

Configuration Migration tool

Why it fails: Configuration Migration tool is designed for moving data and configuration data (e.g., entity records), not solution components like Canvas apps and flows. It is often confused with solution migration.

Solution Checker

Why it fails: Solution Checker is a validation tool that analyzes solutions for best practices, not a migration tool.

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.

The save operation will be blocked

Why it fails: Incorrect. The policy does not include a 'Block save' action; it only sets a field value.

A task will be created for the account owner

Why it fails: Incorrect. The action is to set description, not to change revenue.

The revenue field will be updated to 1,000,000

Why it fails: Incorrect. The action is to set an attribute, not to create a task.

Use a web API call to fetch filtered courses from Dataverse.

Why it fails: A web API call adds JavaScript complexity and requires table permissions and portal configuration, whereas Liquid's fetchXML query filters server-side directly. It is tempting because web API suits interactive client-side operations, and would be correct when the page must create, update, or delete Dataverse records from the browser.

Use a basic form configured with a filter on the Courses table.

Why it fails: Basic forms render create, edit, or read-only record layouts, not filtered lists inside a custom Liquid loop. It is tempting because forms respect table permissions and can filter records, and would be correct when users must view or edit a single Course record rather than iterate a filtered collection.

Add a Liquid if condition inside the for loop to skip inactive courses.

Why it fails: A Liquid if condition still retrieves every Course row from Dataverse before discarding inactive ones, so the slow query remains. It is tempting because conditional rendering is simple and needs no query changes, and would be correct when filtering a small already-retrieved collection on a display attribute.

Increase the flow run frequency to every minute.

Why it fails: Run frequency governs how often the flow triggers, not how the PDF parser interprets layout. Non-standard invoices fail at extraction regardless of cadence, so more runs simply produce more failures. Higher frequency suits latency-sensitive triggers, such as near-real-time alerts, where throughput timing matters rather than document comprehension.

Add a condition to route non-parsed invoices for manual approval.

Why it fails: Routing unparsed invoices to manual approval handles the exception after parsing has already failed; it does not raise extraction accuracy for non-standard layouts. It tempts because approval workflows are a standard Power Automate pattern for human oversight, and they are correct when the requirement is governance sign-off rather than automated data capture.

Change the trigger to a manual button in Power Apps.

Why it fails: A manual Power Apps button changes who initiates the flow, not how PDFs are parsed. Non-standard layouts still defeat the same extractor, so accuracy is unchanged. Manual triggers suit on-demand user-initiated actions, such as a technician submitting a request, where scheduled or automated triggering is undesirable.

Create a data loss prevention (DLP) policy that blocks external users.

Why it fails: DLP policies govern connector and data-flow usage within Power Platform, not who may authenticate to a portal, so external users remain unaffected. It is tempting because DLP restricts data movement, and would be correct for preventing connectors from leaking data between environments.

Restrict access to the portal by IP address using a web application firewall.

Why it fails: An IP-based firewall restriction filters by network origin, not by authenticated identity or email domain, so users on any network could still reach the portal. It is tempting because firewalls control perimeter access, and would be correct for blocking known malicious ranges rather than verifying external user domains.

Share the portal URL only with users from the allowed domains.

Why it fails: Obscuring the URL provides no authentication or domain verification; anyone who obtains the link can access the portal. It is tempting because limiting distribution feels like access control, and would be correct for unlisted public content where secrecy, not identity, is the requirement.