PL-900 common mistakes
PL-900 · Understand the traps and how to avoid them.
Treating Power Apps, Power Automate, Power BI, Power Pages and Copilot Studio as interchangeable 'Power Platform' features, so when asked which tool satisfies a scenario (e.g. 'notify a manager when a record is created'), they pick the wrong component.
The first domain is taught as a single product overview, so candidates memorise the suite name instead of building a one-to-one mapping between each component and the job it does. Under time pressure the names blur.
What to do instead
Build a five-row table in your own words - app building, process automation, reporting/visualisation, external-facing websites, conversational agents - and for each row write the component plus one scenario trigger phrase. Drill by reading only the scenario and naming the component before checking.
Answering 'business value' questions with feature descriptions (e.g. 'it has 400+ connectors') instead of the outcome the organisation gains (e.g. 'citizen developers deliver apps without waiting for IT').
Candidates revise from feature lists and product marketing pages, so features are the most retrievable content, and the stem's wording ('business value') is skimmed.
What to do instead
For each capability, practise writing a two-part sentence: capability → business outcome (reduced backlog, lower licensing cost, faster time to change, single source of truth). If an answer option describes a UI feature in a 'business value' stem, eliminate it immediately.
Assuming anything built in Power Platform lives in 'the' environment, and not recognising that environments are separate containers with their own data, apps, flows and security boundaries.
Trial and personal use normally happens in the auto-created default environment, so candidates never experience a second environment and model the platform as flat.
What to do instead
Memorise the definition: an environment is a container that separates apps, flows, data (Dataverse) and permissions, bound to a region and a tenant. Then practise classifying statements as 'true of environments' vs 'true of solutions' so the container/package distinction is automatic.
Confusing environment-level roles (Environment Admin, Environment Maker) with Dataverse security roles (System Administrator, System Customizer, and business-level roles), and picking one when the stem describes the other.
Both sets are described as 'roles' and both appear in the admin centre, so candidates collapse them into one mental model.
What to do instead
Anchor on scope: environment roles govern access to the environment itself and to making resources in it; Dataverse security roles govern record-level access to data inside that environment. Write the two lists side by side and tag each stem with 'environment access' or 'data access' before choosing.
Choosing a model-driven app for a scenario that needs pixel-perfect custom layout or offline field work, and choosing a canvas app where the requirement is a data-first app with consistent forms and views over Dataverse.
Both are 'Power Apps', so the stem's design signals ('pixel-perfect', 'drag anywhere', 'generated from the data model') get lost once the candidate is confident the answer is 'Power Apps'.
What to do instead
Learn three decision cues: canvas = designer-controlled layout and connector-driven; model-driven = built on Dataverse with auto-generated forms, views and business process flows; Power Pages = external/anonymous users via a website. Read the stem twice, underlining the cue word before looking at options.
Believing a canvas app always requires Dataverse, or that a canvas app cannot use SharePoint/Microsoft 365 data without Dataverse.
Dataverse is emphasised in the platform material, so candidates over-generalise it into a prerequisite for all apps.
What to do instead
State the rule explicitly: canvas apps can connect to many sources through connectors (SharePoint, Excel, SQL, Dataverse) and do not require Dataverse; model-driven apps do require Dataverse. Test yourself by listing two data sources for each app type.
Mixing up trigger types - labelling a button-pressed or manually started flow as 'automated', or a SharePoint 'when an item is created' flow as 'instant'.
Trigger names in the product are similar ('When an item is created' vs 'For a selected item'), and revision focuses on connectors rather than the trigger taxonomy.
What to do instead
Memorise the four families and one example each: automated (event-driven, e.g. item created), instant (manual/button, called from an app), scheduled (recurrence), desktop flow (attended/unattended RPA on a machine). For each practice stem, name the trigger family first, then the connector.
Answering approval questions with 'send an email' or 'create a task', instead of the dedicated approval action that pauses the flow and records a response.
Candidates who have only built notification flows map 'approval' onto the action they know best, and the stems describe approvals in plain business language.
What to do instead
Learn the pattern: the approval action sends the request and waits, the flow resumes only when a response (approve/reject) is recorded, and branches then act on that outcome. Practise describing an approval flow as trigger → approval action → condition on outcome → action.
Assuming a Copilot Studio agent answers only from hand-authored topics, and not recognising generative answers, knowledge sources, or actions that call Power Automate flows or connectors.
Tutorials lead with topic authoring because it is the visible designer surface, so the generative and action layers are under-revised and get missed in scenario stems.
What to do instead
Memorise the three building blocks: topics (trigger phrases plus authored conversation), knowledge/generative answers (grounded responses over supplied sources), and actions (call flows/connectors to do something). Tag each stem with which block it describes before selecting.
Forgetting that an agent must be published and connected to a channel before users can interact with it, and answering as if saving in the authoring canvas makes it live.
Authoring and testing happen in the same place with an in-canvas test pane, which looks like a live agent; publishing and channel configuration are a separate, easily skipped step.
What to do instead
Fix the sequence in memory: author → test in the test pane → publish → configure channel (e.g. a website or Teams) → users can chat. When a stem mentions 'end users cannot reach the agent', check publish status and channel configuration before anything else.