Wednesday, August 19, 2026

Interview Preparation Guide

Microsoft Power Platform · Power Automate Desktop (RPA) · Power BI · Copilot Studio · Azure · Azure AI · AI Foundry · Generative & Agentic AI

Target roles: Senior Developer · Technical Lead · Solution Architect · Power Platform Architect · AI Solution Architect

§	Section	§	Section
0	How to use this guide	15	Azure AI Foundry
1	Power Platform positioning	16	Generative AI
2	Power Apps	17	RAG architecture
3	Microsoft Dataverse	18	Agentic AI
4	Power Automate (cloud flows)	19	Microsoft Graph
5	Power Automate Desktop & RPA	20	Integration architecture patterns
6	Power Pages	21	Troubleshooting bank (50)
7	Power BI	22	Security question bank
8	Power Platform governance	23	Comparison question bank (25)
9	ALM / DevOps	24	Scenario-based architect questions (50)
10	Microsoft Copilot Studio	25	Certification-based question sets
11	Azure core & architecture	26	Top 100 must-know questions
12	Azure integration patterns	27	100 rapid-fire questions
13	Azure & platform security	28	Mock interview
14	Azure AI services	A	Appendix — cheat sheets

0. How to use this guide

If you have	Do this
7 days	Follow the study plan in §0.4, one block per day
2 days	Read §23 Comparisons, §26 Top 100, §27 Rapid-Fire, §24 Scenarios
2 hours	Read §27 Rapid-Fire + §23 Comparisons only
Interview tomorrow	Read §0.2 framework, §26 Top 100, and rehearse 5 scenarios out loud

Answer style used throughout: Question → Short Answer → Keywords → Deeper points → Real-world example. Sections 1–20 use the full format. Sections 21–27 are deliberately compressed (answer + keywords) because they are drill material, not reading material.

0.1 What is actually being scored

Interviewers at this level are not testing recall. They score five things:

Signal	What it sounds like	What kills it
Decision-making	"I'd use X because Y; the trade-off is Z"	"X is better than Y" with no reason
Scale awareness	Naming limits, throughput, throttling	Answers that only work for 100 rows
Security instinct	Mentioning identity, least privilege, secrets, DLP unprompted	Waiting to be asked about security
Operability	Logging, monitoring, retry, rollback, alerting	Building it but never running it
Honesty	"I haven't used that; here's how I'd approach it"	Bluffing a feature that doesn't exist

0.2 The 5-part answer framework

Direct answer — one sentence. Never open with "It depends" alone; open with a position, then qualify.
Keywords — 3–6 correct product terms so the interviewer can tick their sheet.
Why / when — the decision rule.
Trade-off — what you give up. This is the single biggest differentiator at architect level.
Evidence — a real project, one or two lines, with a number in it.

Template for architecture questions: "Requirements → I'd assume X, Y, Z. Options are A and B. I'd choose A because of [constraint]. Key risks are [risk], mitigated by [control]. I'd measure success with [metric]."

Template for troubleshooting questions: "First I'd reproduce and scope it — is it all users or one, all records or some, always or intermittently. Then I'd check [telemetry source]. Most likely causes in order are 1, 2, 3. I'd fix the immediate issue, then add [control] so it can't recur."

0.3 Phrases to avoid, and what to say instead

Avoid	Say instead
"It depends." (alone)	"It depends on the transaction volume — under X I'd do A, above X I'd do B."
"Power Automate can do anything."	"Power Automate is the right tool up to roughly this throughput; beyond it I'd move to Functions or Logic Apps Standard."
"We used SharePoint lists for everything."	"We used SharePoint for document-centric data and Dataverse where we needed relational integrity and row-level security."
"AI handles that."	"The model drafts it; a deterministic step validates it and a human approves anything above threshold."
"I'd give it Global Admin."	"I'd use a service principal with the minimum application permission, secrets in Key Vault."

0.4 Seven-day study plan

Day	Focus	Sections
1	Power Apps + Dataverse	2, 3
2	Power Automate cloud + ALM	4, 9
3	PAD / RPA architecture	5
4	Power BI + Governance	7, 8
5	Copilot Studio + Azure AI + AI Foundry	10, 14, 15
6	Azure core, integration, security	11, 12, 13
7	GenAI, RAG, Agentic AI + full mock	16, 17, 18, 28

Every day: 20 minutes of §27 Rapid-Fire out loud, and one §24 scenario answered on a whiteboard.

0.5 Currency of terminology — say the new name

Using an old product name is the fastest way to sound out of date. Using the old name and flagging the rename sounds current.

Old / legacy name	Current name
Common Data Service (CDS)	Microsoft Dataverse
Azure Active Directory (Azure AD)	Microsoft Entra ID
Azure Cognitive Services	Azure AI Services
Azure Cognitive Search	Azure AI Search
Form Recognizer	Azure AI Document Intelligence
Power Virtual Agents	Microsoft Copilot Studio
Azure AI Studio	Azure AI Foundry
Power BI dataset	Semantic model
Power BI Premium (P SKU) capacity	Fabric capacity (F SKU)
Power Apps portals	Power Pages
Flow / Microsoft Flow	Power Automate (cloud flows)
UI flows	Desktop flows (Power Automate Desktop)
Bot Framework Composer scenarios	Copilot Studio / Azure AI Foundry Agent Service

0.6 Accuracy note — read this before quoting numbers

Service limits, licensing, SKU names and AI product surfaces in this space change every few months. Every architectural pattern, comparison and decision rule in this guide is durable. The specific numeric limits (request caps, row limits, timeout values, capacity units) and licensing statements are the volatile part.

Before the interview, re-verify these against Microsoft Learn:

Power Platform request limits and API entitlements per licence
Power Automate flow run duration, action counts, and pagination caps
Dataverse API service protection limits (per user, per server, sliding window)
Power BI / Fabric capacity SKU behaviour and Direct Lake fallback rules
Copilot Studio message/capacity packs and Azure AI Foundry model availability by region

In an interview, the safe phrasing is: "The limit is in the low thousands of requests per five minutes per user — I'd confirm the current number, but the design implication is that I must batch and back off." Naming the implication scores higher than naming the number.

1. Power Platform — Positioning

Q1.1 Where does Power Platform stop and Azure start?

Short answer: Power Platform is the right choice when the logic is business-owned, the data volume is moderate, and speed of delivery matters. I move to Azure when I need custom compute, high throughput, long-running or stateful processing, complex transformations, or protocol-level control.

Keywords: low-code, citizen vs pro developer, throughput, service limits, fusion teams

If pushed deeper:

The boundary is usually drawn by request limits and run duration, not by capability.
Fusion team pattern: Power Apps for UI, Dataverse for data, Azure Functions/Service Bus for heavy lifting behind a custom connector.
Cost inverts at scale — per-user licensing is cheap for hundreds of users, expensive for machine-to-machine volume, where Azure consumption wins.

Real-world example: An intake app in Power Apps writing to Dataverse, with a plug-in publishing to Service Bus; an Azure Function does the 2-million-row reconciliation nightly and writes results back. Business users own the front half, engineering owns the back half.

2. Power Apps

Q2.1 Canvas vs model-driven — how do you actually choose?

Short answer: Canvas when the UX is prescribed, task-focused, or mobile-first and data may be multi-source. Model-driven when the data model is the application — Dataverse-based, relational, record-management heavy, with security and forms driven by metadata.

Keywords: Power Fx, metadata-driven, Dataverse, responsive, business process flows

If pushed deeper:

Model-driven gives you security roles, views, charts, BPFs and audit almost for free; canvas makes you build them.
Canvas gives pixel control and non-Dataverse sources; model-driven does not.
Custom pages let you embed canvas inside model-driven — the usual answer for "we need one bespoke screen inside a CRM-style app."

Real-world example: A field inspection app was canvas (offline, camera, GPS, one screen per step); the back-office case management on the same Dataverse tables was model-driven.

Q2.2 Explain delegation and why it matters at scale

Short answer: Delegation means the query is pushed down to the data source instead of being evaluated in the client. If a function isn't delegable, Power Apps pulls only the first N rows (default 500, max 2000) and filters locally — so you get silently wrong results, not an error.

Keywords: delegable functions, data row limit, source-specific delegation, silent truncation

If pushed deeper:

Delegation support varies by connector: Dataverse and SQL are strong, SharePoint is partial, Excel and collections are not delegable at all.
Common non-delegable traps: Search() on some sources, in operator, complex If() inside Filter(), calculated columns.
Fixes: reshape the filter to delegable operators, add filtered views/stored procedures at the source, or pre-aggregate.

Real-world example: A 400k-row SharePoint list returned only 2000 records in a "total open items" count. We moved the aggregate to a Dataverse rollup and had the app read a single value.

Q2.3 A canvas app takes 25 seconds to load. How do you fix it?

Short answer: Measure first with Monitor, then attack in this order: reduce OnStart work, remove non-delegable and unfiltered queries, cut the number of controls and nested galleries, replace ClearCollect-everything with on-demand loading, and enable delayed load / concurrent calls.

Keywords: Monitor, OnStart vs App.StartScreen, Concurrent, delayed load, ClearCollect, N+1 lookups

If pushed deeper:

Classic killers: pulling reference data for the whole tenant into collections at start; galleries with lookups inside labels (N+1 calls); images stored as base64 in the data source.
Use Concurrent() for independent calls; set App.StartScreen instead of Navigate in OnStart.
Move calculated logic to Dataverse (rollups, calculated columns, views) so the client does less.

Real-world example: An app loading 12 collections at start dropped from 25s to 4s by loading only the two needed for screen one, and lazy-loading the rest on navigation.

Q2.4 How do you implement role-based security in Power Apps?

Short answer: Enforce it at the data layer, never in the UI. In Dataverse that's security roles, business units, teams, field-level security and hierarchy; the app only reflects those permissions by hiding controls the user can't use anyway.

Keywords: security roles, business units, owner/access teams, field-level security, least privilege

If pushed deeper:

UI-only security is a finding in every audit — the connector is callable directly.
For non-Dataverse sources, security lives in the source (SharePoint permissions, SQL row-level security) plus a service layer.
Use User() and role lookup tables sparingly and only for cosmetics.

Real-world example: Salary fields were hidden with a Visible formula until a pen test read them through the Dataverse Web API. We moved them to field-level security profiles.

Q2.5 How do you handle large datasets in a canvas app?

Short answer: Don't move the data to the app — move the question to the data. Use delegable filters, server-side views, search-as-you-type with a minimum character count, paging galleries, and pre-computed aggregates.

Keywords: delegation, views, rollups, paging, indexed columns, search patterns

Real-world example: A 2-million-row product catalogue was surfaced through a Dataverse view plus a search box requiring 3 characters, returning the top 50 matches.

Q2.6 What's your ALM approach for Power Platform?

Short answer: Everything in a solution, source-controlled, deployed by pipeline. Unmanaged only in Dev; managed in Test/UAT/Prod. Environment variables and connection references for anything environment-specific, and no manual changes downstream.

Keywords: solutions, managed vs unmanaged, environment variables, connection references, Power Platform Pipelines, PAC CLI, solution checker

If pushed deeper:

Publisher and prefix decided on day one; changing later is painful.
Separate solutions by lifecycle, not by team — core data model, shared components, app-specific.
Solution checker in the build gate; export unpacked solution to Git for real diffs.

Real-world example: Moving from manual export/import to Azure DevOps with Power Platform Build Tools cut a release from a half-day of clicking to a 20-minute pipeline with rollback.

Q2.7 Component libraries and PCF — when do you build one?

Short answer: Component library when the reuse is a composition of existing controls and Power Fx. PCF when you need a control the platform doesn't have — custom rendering, third-party JS libraries, or heavy client-side interaction.

Keywords: component library, PCF, TypeScript, code components, versioning

If pushed deeper:

PCF carries a maintenance and ALM cost: build tooling, dependency updates, browser testing.
Component library updates are versioned; consuming apps must accept the update explicitly.

Real-world example: A Gantt-style scheduler needed PCF; a branded header/footer and toast pattern went in a component library used by 14 apps.

Q2.8 How do you handle errors properly in a canvas app?

Short answer: Wrap data operations in IfError/Patch result checks, surface a user-friendly message, log the technical detail somewhere queryable, and never let a silent failure look like success.

Keywords: IfError, Errors(), error handling, telemetry, Application Insights

If pushed deeper:

Enable Application Insights on the app for real user telemetry and unhandled errors.
Distinguish validation errors (fix in UI), business errors (show and stop), and system errors (log, retry, escalate).

Real-world example: A submit button that "worked" but silently failed on a required-field violation was found only after we wired IfError to an Application Insights custom event.

Q2.9 Offline in canvas apps — how far does it go?

Short answer: Offline works for capture-and-forward scenarios: cache reference data locally with SaveData/LoadData, queue user submissions, and sync when connectivity returns with conflict handling. It does not give you a full offline relational database.

Keywords: SaveData/LoadData, Connection.Connected, sync queue, conflict resolution, offline-first (mobile)

Real-world example: Warehouse scanning app queued up to 500 scans offline, deduplicated on sync by a client-generated GUID so retries were idempotent.

Q2.10 Power Apps vs Power Pages — when do you use Pages?

Short answer: Power Pages when the audience is external and unauthenticated or authenticated via an external identity provider, and you need public, SEO-capable web pages over Dataverse. Power Apps for internal, licensed users.

Keywords: external users, table permissions, web roles, authentication providers, anonymous access

If pushed deeper:

Pages security is its own model: web roles + table permissions + page permissions. It is not the same as Dataverse security roles for internal users.
Never expose a Dataverse table to Pages without explicitly scoped table permissions — global read is the classic breach.

Real-world example: A supplier onboarding portal used Power Pages with Entra External ID, table permissions scoped by contact-to-account relationship.

3. Microsoft Dataverse

Q3.1 Where should business logic live in Dataverse?

Short answer: Push logic as close to the data as the requirement allows. Business rules for simple field-level validation, calculated/rollup columns for derived values, plug-ins for transactional and integrity-critical logic, Power Automate for orchestration and long-running or cross-system work.

Keywords: business rules, calculated/rollup columns, plug-ins, real-time workflow, cloud flows

Decision rule:

Requirement	Use
Must be enforced regardless of entry point	Plug-in (sync)
Must roll back with the transaction	Plug-in (sync, in transaction)
Simple show/hide/require/default	Business rule
Derived value on the record	Calculated / rollup column
Cross-system, approvals, long-running	Cloud flow
Reusable server-side operation with a contract	Custom API

Real-world example: Credit-limit enforcement lived in a synchronous pre-operation plug-in so it applied to the app, the API and the data migration equally.

Q3.2 Synchronous vs asynchronous plug-ins

Short answer: Synchronous runs inside the user's transaction — it can block and roll back the operation, but it adds latency and has a hard timeout (2 minutes). Asynchronous runs after commit via the async service — it can't stop the operation but it can be slower and retried.

Keywords: pipeline stages, pre-validation, pre-operation, post-operation, transaction, 2-minute limit, async job

If pushed deeper:

Pre-validation runs outside the transaction (use for cheap guard checks and for cases where you must inspect state before the DB transaction begins).
Long-running work in a sync plug-in is an anti-pattern — call out to a queue instead and process asynchronously.
Never call an external HTTP endpoint synchronously in a plug-in unless you accept its latency and failure as your own.

Real-world example: An ERP sync originally in a sync plug-in caused user-visible 8-second saves; we changed it to post-operation async publishing to Service Bus.

Q3.3 Plug-in vs Power Automate — how do you decide?

Factor	Plug-in	Cloud flow
Execution	In-transaction, server-side, ms	Out of band, seconds
Rollback	Yes (sync)	No
Skill required	C#, pro-dev, ALM	Low-code
Bypassable	No	Yes (fires on data events only)
Best for	Integrity, validation, complex logic	Orchestration, approvals, connectors
Timeout	2 minutes	30 days (flow), 120s per HTTP action

Short answer: Plug-in when correctness and atomicity matter; flow when the work is orchestration across systems or needs human interaction. If the rule must never be bypassed and must be instant, it is a plug-in.

Q3.4 Dataverse vs SharePoint vs SQL

Short answer: Dataverse for relational business data needing row-level security, auditing and business logic. SharePoint for documents and lightweight lists. Azure SQL when you need full T-SQL power, very high volumes, or existing schema ownership.

Keywords: relational integrity, RLS, audit, throughput, licensing, delegation

If pushed deeper:

Cost: Dataverse capacity and per-user licences vs SharePoint "included" vs SQL consumption. Interviewers like hearing cost as a design factor.
Hybrid is common and correct: Dataverse for transactional records, SharePoint for the document body, linked by document location.
Virtual tables let Dataverse surface SQL/external data without copying it — good for read-mostly reference data, weak for heavy write scenarios.

Real-world example: Case records in Dataverse, case attachments in SharePoint via server-side document integration — kept Dataverse storage cost down by an order of magnitude.

Q3.5 Explain the Dataverse security model end to end

Short answer: Access is the union of: security roles (privileges per table per access level), business unit scope, team membership (owner and access teams), record sharing, field-level security for sensitive columns, and hierarchy security for manager access.

Keywords: privileges, access levels (User/BU/Parent-child BU/Org), owner team, access team, sharing, field security profile, hierarchy security

If pushed deeper:

Roles are additive — you cannot subtract with a second role. Least privilege means designing the base role carefully, not layering.
Access teams scale better than sharing for ad-hoc collaboration; owner teams for structural ownership.
Modern approach in large tenants: matrix data access with business units decoupled from the org chart (a record's owning BU no longer has to match the user's).

Real-world example: A regional model used BU-per-region plus access teams for cross-region deal collaboration, avoiding thousands of individual shares.

Q3.6 Virtual tables vs standard tables vs elastic tables

	Standard	Virtual	Elastic
Storage	Dataverse	External source	Dataverse (NoSQL-backed)
Best for	Transactional relational data	Read-mostly external data, no copy	Very high volume, high write throughput, semi-structured
Relationships	Full	Limited	Limited
Transactions	Full	Depends on provider	Eventual consistency characteristics
Watch out for	Storage cost	Latency, provider limits, filtering/sorting pushdown	Feature gaps vs standard tables

Short answer: Standard by default; virtual to avoid duplicating an authoritative external source; elastic when you have IoT-style or telemetry-style volumes that would crush a standard table.

Q3.7 Dataverse is throwing service protection (429) errors. What do you do?

Short answer: Respect the Retry-After header with exponential backoff, reduce concurrency, batch with $batch or ExecuteMultiple, and spread work across identities/time rather than hammering with one service principal.

Keywords: service protection limits, 429, Retry-After, ExecuteMultiple, $batch, concurrency, backoff

If pushed deeper:

Limits are per user per server over a sliding window — number of requests, execution time, and concurrent requests.
Bulk operations: CreateMultiple/UpdateMultiple messages are far more efficient than row-by-row.
Design fix: move bulk loads out of interactive paths entirely and schedule them.

Real-world example: A nightly 300k-row sync was rewritten from per-row Create to CreateMultiple batches of 100 with jittered backoff; runtime went from 6 hours to 40 minutes and 429s disappeared.

Q3.8 How do you optimise a slow Dataverse query?

Short answer: Reduce columns, filter server-side, avoid link-entity explosion, add or verify indexes on filter/sort columns, avoid contains on large text, and check whether the cost is really in the query or in the calling loop.

Keywords: FetchXML, OData $select/$filter, indexes, link-entity, plug-in trace log, N+1

Real-world example: A view filtering on a non-indexed custom text column took 40 seconds; adding an index and switching from contains to startswith brought it to under a second.

Q3.9 Custom API vs custom action vs Power Automate

Short answer: Custom API is the modern, solution-aware, code-first way to expose a server-side operation with a defined contract and privilege binding. Custom actions are the legacy equivalent. Power Automate is for orchestration, not for exposing a reusable transactional operation.

Keywords: custom API, request/response parameters, privilege binding, plug-in-backed, ALM

Real-world example: "Recalculate entitlement" was exposed as a custom API so the canvas app, the portal and a nightly job all called the same logic with the same validation.

Q3.10 How do you migrate 5 million records into Dataverse?

Short answer: Stage and cleanse outside Dataverse, load in dependency order using alternate keys for upsert, use bulk messages with controlled parallelism, disable non-essential plug-ins/flows/audit during load, and reconcile with counts and checksums afterwards.

Keywords: alternate keys, upsert, CreateMultiple, bulk load, disable async plug-ins, audit off, reconciliation

If pushed deeper:

Sequence: reference/lookup tables → parents → children → relationships → attachments.
Alternate keys make the load idempotent — you can rerun a failed batch safely.
Turn auditing off for the migration window or your storage bill and performance both suffer.

Real-world example: A 5M-row CRM migration ran in 9 hours over a weekend with 8 parallel streams, alternate-key upserts and a reconciliation report by source system ID.

Q3.11 Alternate keys — why do architects care?

Short answer: They give you a natural business key for upsert and integration, so external systems don't need to know Dataverse GUIDs — which makes integrations idempotent and re-runnable.

Keywords: alternate key, upsert, idempotency, integration key, index

Q3.12 Auditing and duplicate detection — the practical view

Short answer: Enable auditing selectively per table and column, because it consumes storage fast; use duplicate detection rules for user-driven entry, and alternate keys/upsert for system-driven entry.

Keywords: audit, log storage, retention, duplicate detection rules, alternate keys

Real-world example: Auditing enabled tenant-wide consumed the whole log capacity in three months; we scoped it to 6 tables and 30 columns that compliance actually required.

4. Power Automate — Cloud Flows

Q4.1 What makes a flow "enterprise-grade"?

Short answer: Solution-aware, environment-variable driven, connection references not personal connections, structured error handling with scopes and run-after, retry with backoff, idempotent processing, secure inputs/outputs, centralised logging, and monitoring with alerts.

Keywords: solutions, connection references, environment variables, scopes, run-after, retry policy, idempotency, secure inputs, service principal

If pushed deeper:

Run under a service principal or service account, never a person's identity — the flow dies when they leave.
Every flow should answer: what happens if it runs twice? what happens if the target is down? who finds out it failed?
Child flows for reusable logic; keep the parent readable.

Real-world example: We standardised a "Try / Catch / Finally" scope pattern with a shared child flow that writes failures to a Dataverse error table and raises a Teams alert with the run URL.

Q4.2 How do you implement error handling in a flow?

Short answer: Use scopes as Try/Catch/Finally: put work in a Try scope, add a Catch scope configured to run after "has failed / timed out / is skipped", capture result() of the Try scope for detail, log it, and then terminate with a proper status.

Keywords: scope, configure run after, result(), Terminate, error table, correlation ID

Deeper points:

result('TryScope') gives you per-action status, inputs, outputs and error messages in one object.
Terminate with Failed so the run shows as failed in analytics — swallowing errors makes monitoring lie.
Add a correlation ID (workflow().run.name) to every log entry so support can trace end to end.

Q4.3 A flow must process 1 million records. How do you design it?

Short answer: Don't loop a million times in one run. Use a dispatcher/worker split: one flow pages the source and writes work items to a queue (Service Bus or a Dataverse queue table), and workers process batches idempotently with concurrency control and checkpointing.

Keywords: pagination, batching, queue, dispatcher/performer, concurrency control, idempotency, checkpoint, throttling

If pushed deeper:

Apply-to-each has item caps and concurrency limits; run duration and action counts are finite.
Honest architect answer: at that volume Power Automate is the orchestrator, not the engine — Azure Functions, Durable Functions or Data Factory does the work.
Checkpoint progress so a failure resumes rather than restarts.

Real-world example: 1.2M invoice lines: a scheduled flow queued 12k batches of 100 to Service Bus; a Durable Function fan-out processed them in 25 minutes with dead-lettering for poison messages.

Q4.4 How do you prevent duplicate processing?

Short answer: Make the operation idempotent: use a business key with upsert (alternate keys in Dataverse), maintain a processed-items table or dedupe key, and use trigger conditions plus concurrency control so the same record can't be picked up twice.

Keywords: idempotency, alternate key, upsert, dedupe table, trigger conditions, concurrency, optimistic locking

Real-world example: A payment flow used the source system's transaction ID as an alternate key; retries and duplicate triggers became harmless no-ops.

Q4.5 How do you handle throttling and API limits?

Short answer: Design for it rather than react to it: batch requests, reduce per-item calls, set retry policy to exponential with jitter, respect Retry-After, lower apply-to-each concurrency, and spread load across time or identities.

Keywords: 429, Retry-After, exponential backoff, jitter, degree of parallelism, request limits, batching

If pushed deeper:

Default retry policy is fixed/exponential with a small count — for flaky downstreams, raise it deliberately rather than accepting defaults.
Watch the hidden multiplier: a loop of 10,000 items with 3 actions each is 30,000 API calls.

Q4.6 Power Automate vs Logic Apps

Factor	Power Automate	Logic Apps
Audience	Business users, in-tenant	Engineers, Azure subscription
Licensing	Per user / per flow	Consumption or Standard hosting
ALM	Solutions, Power Platform pipelines	ARM/Bicep, Azure DevOps
Networking	Limited (data gateway)	VNet integration (Standard), private endpoints
Best for	User-triggered, M365-centric, approvals	High volume, system integration, network isolation

Short answer: Same underlying engine and connector set; different governance, hosting and networking. If it needs VNet integration, high throughput or subscription-level cost control, it's Logic Apps.

Q4.7 When do you use a child flow?

Short answer: For reuse of a defined operation (logging, notification, a shared transformation), to keep parent flows readable, and to isolate error handling. They must live in the same solution and require a connection reference strategy.

Keywords: child flow, solution-aware, reuse, run-only permissions, response action

Watch out: child flow calls count toward limits too, and debugging spans two run histories — use a correlation ID.

Q4.8 Service principal vs service account for flows

Short answer: Service principal (application user in Dataverse) is the correct answer for unattended, machine-to-machine work — no licence, no password, no MFA problem, secret in Key Vault. Service accounts persist only where a connector genuinely can't do app-only auth.

Keywords: application user, app registration, client secret/certificate, Key Vault, managed identity, least privilege

Real-world example: Migrating 60 flows from a shared service account to an application user removed a password-rotation outage that hit us twice a year.

Q4.9 How do you monitor flows in production?

Short answer: Don't rely on run history. Emit structured logs to a central store (Dataverse table, Log Analytics, or Application Insights), alert on failure rate and duration, and use the CoE starter kit or Power Platform admin analytics for tenant-level view.

Keywords: run history, Application Insights, Log Analytics, CoE Starter Kit, alerting, SLA, correlation ID

Q4.10 Explain trigger conditions and why they matter

Short answer: Trigger conditions filter at the trigger so the flow doesn't start at all — saving runs, API calls and licence consumption, and preventing loops where a flow's own update re-triggers it.

Keywords: trigger condition, infinite loop prevention, modifiedby filter, run consumption

Real-world example: A flow updating the record it triggered on looped until we added a trigger condition excluding updates made by the flow's own service principal.

Q4.11 Secure inputs/outputs and DLP — the practical answer

Short answer: Turn on secure inputs/outputs for any action handling secrets or personal data so values are masked in run history; enforce connector separation with DLP policies so business data can't flow to consumer connectors.

Keywords: secure inputs/outputs, DLP, business/non-business/blocked, connector groups, run history exposure

Watch out: run history is visible to anyone with flow access — that is the leak path people forget.

Q4.12 How do you troubleshoot a flow that fails intermittently?

Short answer: Scope it — which action, which inputs, what time of day. Check for throttling (429), downstream timeouts, data-shape variation (null or missing properties in Parse JSON), and concurrency collisions. Add logging of the failing input, then reproduce with that payload.

Keywords: run history, 429, Parse JSON schema mismatch, null handling, timeout, concurrency

Common causes, in order: throttling → schema variation → expired connection → downstream outage → race condition.

5. Power Automate Desktop & RPA Architecture

Q5.1 When is RPA the right answer — and when is it a mistake?

Short answer: RPA is right when the target system has no API, the process is rule-based and stable, and the business case is short-term or bridging. It's a mistake when an API exists, when the process changes constantly, or when RPA is used to avoid fixing a broken process.

Keywords: API-first, surface automation, brittleness, process stability, technical debt

Real-world example: We automated a legacy claims mainframe screen because no API existed, but replaced an "RPA into SharePoint" bot with a Graph API call in week two.

Q5.2 Explain dispatcher/performer architecture

Short answer: The dispatcher reads the source of work and writes individual transaction items into a queue; performers pick items up one at a time, process them, and set the outcome. It decouples discovery from processing, enables parallel bots, gives per-item retry, and makes the run auditable.

Keywords: dispatcher, performer, work queue, transaction item, retry, parallelism, decoupling

If pushed deeper:

One failure no longer kills the batch — only that item fails.
You can scale performers horizontally without touching the dispatcher.
Queue item status (queued / in-progress / success / business exception / system exception / retried) is your audit trail.
In Power Platform this is work queues in Power Automate (or a Dataverse table acting as a queue) plus desktop flows on machine groups.

Real-world example: Nightly invoice posting: dispatcher extracts 8,000 invoices to a work queue at 19:00; four unattended performers on a machine group process them by 23:00 with per-item retry.

Q5.3 Design an unattended solution processing 100,000 transactions nightly

Short answer: Dispatcher → queue → horizontally scaled performers on a machine group, with idempotent transactions keyed on a business ID, per-item retry with a cap, exception classification, checkpointing, monitoring/alerting, and a reconciliation report at the end of the window.

Architecture points to say out loud:

Concern	Design decision
Throughput	Measure single-item time, divide the window, derive bot count; add 30% headroom
Scaling	Machine group, unattended licences, cloud-hosted machines if elastic capacity is needed
Reliability	Per-item retry (max 2–3), then route to exception queue for human review
Idempotency	Business key checked in target before write
Recovery	Queue state survives restart; performer resumes with next item
Security	Credentials in Key Vault / Azure Key Vault-backed environment variables, never in the flow
Observability	Every item logs start/end/outcome; dashboard on queue depth and failure rate
Business continuity	If the window is missed, a catch-up run must be safe to execute

Reality check to mention: at 100k items, first ask whether an API or database-level integration exists. RPA at that volume is a cost and fragility decision, not a default.

Q5.4 Business exception vs system exception

Short answer: A business exception means the data is invalid for the process — retrying won't help, so route it to a human queue. A system exception is environmental — the app hung, the network dropped — so retry, and only escalate after the retry cap.

Keywords: business exception, system exception, retry policy, exception queue, human-in-the-loop

Real-world example: "Invoice already posted" is a business exception (skip, log); "SAP GUI not responding" is a system exception (kill process, relaunch, retry).

Q5.5 A bot fails randomly. How do you troubleshoot it?

Short answer: Randomness usually means timing, environment or state — not logic. Check for hard waits instead of dynamic waits, changed UI selectors, session/lock-screen issues on unattended machines, popups, slow application load, and residual state from the previous transaction.

Diagnostic order:

Is it the same step every time, or different steps? Same step = selector/timing; different = environment.
Screenshots/logs at failure — PAD captures these; make sure logging is on.
Machine state — is the session locked, is another process holding focus, was the machine patched?
Selector robustness — replace index/position-based selectors with attribute-based ones.
Reset state at the start of every transaction ("init" step: close apps, clear temp, fresh login).

Keywords: dynamic wait, UI selectors, session lock, popup handling, state reset, screenshots

Q5.6 How do you make UI automation robust?

Short answer: Prefer non-UI paths first (API, database, file drop). Where UI is unavoidable: use stable attribute-based selectors, wait for elements rather than sleeping, handle popups explicitly, verify the outcome after each critical action, and reset application state per transaction.

Keywords: selector strategy, wait for element, verification step, popup handling, state reset, retries

Q5.7 How do you manage credentials securely in PAD?

Short answer: Never in the flow. Use Azure Key Vault referenced via environment variables or a Key Vault connector, or the platform's credential store; rotate automatically; scope each bot identity to only the systems it needs; and use separate identities per process for auditability.

Keywords: Key Vault, environment variables, credential store, rotation, least privilege, per-process identity, no hardcoded secrets

Watch out: logging inputs can leak a secret — turn on secure inputs/outputs for actions handling credentials.

Q5.8 Attended vs unattended vs hosted machines

	Attended	Unattended	Hosted / hosted group
Runs	With a signed-in user present	On its own, no user	Microsoft-provisioned VM, no user
Best for	Assisting a person in real time	Batch/back-office volume	Elastic capacity without managing VMs
Licence	Attended user	Unattended add-on per bot	Unattended + hosted capacity
Risk	Interrupts the user's desktop	Session/lock handling, error visibility	Networking/domain-join constraints

Q5.9 How do you migrate from another RPA platform (UiPath/Blue Prism/Automation Anywhere) to PAD?

Short answer: Treat it as re-implementation with process improvement, not a code port. Inventory and rationalise processes first, kill anything an API can replace, map framework concepts (REFramework → dispatcher/performer + work queues), rebuild the shared framework once, then migrate highest-value/lowest-complexity processes first.

Keywords: process inventory, rationalisation, REFramework mapping, work queues, pilot, parallel run, cutover

If pushed deeper:

Expect 30–50% of processes not to be worth migrating.
Run old and new in parallel for a cycle and reconcile outputs before decommissioning.
Rebuild reusable components (logging, exception handling, config, retry) as a shared template before migrating anything.

Real-world example: 42 bots audited, 14 replaced by Graph/API calls, 21 migrated, 7 retired; the shared "framework" desktop flow template was built and tested before any process moved.

Q5.10 How do you build logging and auditability into an RPA estate?

Short answer: Every transaction writes a structured record: process name, run ID, transaction key, start/end, outcome, exception type, message. Store it centrally (Dataverse or Log Analytics), and report queue depth, throughput, success rate, average handling time and exceptions by type.

Keywords: structured logging, transaction ID, correlation, Dataverse/Log Analytics, dashboards, SLA, audit trail

Real-world example: A Power BI dashboard over the RPA log table showed FTE-hours saved and exception hot spots — it was what secured the following year's budget.

Q5.11 How do you handle a failed transaction mid-process?

Short answer: Classify it, roll the application back to a known state, mark the queue item with the outcome and reason, retry if it's a system exception up to the cap, and never leave the target system half-updated — design each transaction to be atomic or compensatable.

Keywords: atomicity, compensation, known state, retry cap, queue item status, dead letter

Q5.12 PAD performance — how do you speed up a slow bot?

Short answer: Remove fixed sleeps, minimise UI interaction (use Excel/CSV/SQL/API paths where possible), avoid opening and closing applications per transaction, batch reads, and parallelise across performers rather than optimising a single bot to death.

Keywords: dynamic waits, bulk read, session reuse, parallel performers, UI interaction cost

6. Power Pages

Q6.1 How is Power Pages security designed?

Short answer: Three layers: authentication (Entra External ID, Azure B2C, or another provider), web roles assigned to contacts, and table permissions scoped by relationship (contact, account, or self) with page permissions on top.

Keywords: web roles, table permissions, contact/account scope, anonymous role, page permissions, WebAPI

Watch out: Global-scope table permissions on a public-facing site are the classic data-exposure incident. Scope by relationship and test as an anonymous user.

Q6.2 Power Pages performance and scale

Short answer: Cache aggressively, minimise Liquid queries per page, use the Web API for client-side data instead of rendering everything server-side, use CDN for static assets, and load-test before go-live because external traffic is unpredictable.

Keywords: Liquid, FetchXML, caching, Web API, CDN, capacity

7. Power BI

Q7.1 Import vs DirectQuery vs Direct Lake

Factor	Import	DirectQuery	Direct Lake
Where data lives	In-memory model (VertiPaq)	Source system	OneLake Delta tables
Freshness	As of last refresh	Real-time	Near real-time from lakehouse
Performance	Fastest	Depends on source	Near-import speed, no refresh
Model features	Full DAX	Restricted	Broad, with fallback rules
Best for	Most reports	Huge/volatile data, compliance on no-copy	Fabric lakehouse workloads

Short answer: Import by default because it's fastest and gives full DAX. DirectQuery when the data is too large to import or must be real-time. Direct Lake when you're on Fabric and the data already lives in OneLake — you get import-like speed without a refresh cycle.

Watch out: Direct Lake can fall back to DirectQuery under certain conditions (model size, unsupported operations) — know that fallback exists and that it changes performance characteristics.

Q7.2 Measure vs calculated column

Short answer: Calculated columns are computed at refresh, stored in the model, evaluated in row context — they cost memory. Measures are computed at query time in filter context and cost nothing until used. Default to measures.

Keywords: row context, filter context, VertiPaq storage, query time, context transition

Rule of thumb: if you need to slice/group by it, it's a column; if it aggregates, it's a measure.

Q7.3 Explain filter context, row context and context transition

Short answer: Filter context is the set of filters applied to the model when a measure evaluates. Row context exists when iterating a table row by row (calculated columns, SUMX). CALCULATE converts row context into filter context — that's context transition.

Keywords: CALCULATE, filter context, row context, context transition, iterators (SUMX/FILTER)

Interview tip: be able to say "CALCULATE is the only function that modifies filter context" and give a one-line example: CALCULATE([Sales], Product[Category]="Bikes").

Q7.4 Why star schema, and what breaks without it?

Short answer: Star schema (fact + dimensions, single-direction relationships) is what the VertiPaq engine and DAX are optimised for. Snowflaked or flat models cause slower queries, ambiguous relationship paths, wrong totals with bidirectional filters, and unmaintainable measures.

Keywords: fact, dimension, cardinality, single vs bidirectional, ambiguity, role-playing dimension

Real-world example: A 14-table flat model with 6 bidirectional relationships produced wrong totals; refactoring to a star with a date dimension fixed both correctness and a 22-second visual.

Q7.5 How do you optimise a slow Power BI report?

Short answer: Diagnose first with Performance Analyzer and DAX Studio — separate visual rendering time from DAX query time from source query time. Then: fix the model (star schema, reduce cardinality, remove unused columns), fix the DAX (avoid FILTER over whole tables, avoid nested iterators), and reduce visuals per page.

Diagnostic order:

Performance Analyzer → which visual, and is time in DAX or in rendering?
DAX Studio → server timings; storage engine vs formula engine split.
High formula engine time = bad DAX; high storage engine time = model/cardinality problem.
Reduce columns (especially high-cardinality text and datetime), split datetime into date + time.
Aggregations, incremental refresh, or composite model if the source is the bottleneck.

Keywords: Performance Analyzer, DAX Studio, VertiPaq Analyzer, cardinality, formula engine, storage engine, aggregations

Q7.6 RLS vs OLS

Short answer: RLS filters rows by a DAX predicate per role; OLS hides entire columns or tables from a role. RLS controls what data you see; OLS controls what the model even exposes.

Keywords: row-level security, object-level security, USERPRINCIPALNAME(), dynamic RLS, roles

Deeper: dynamic RLS uses a user-mapping table and USERPRINCIPALNAME() so you maintain one role instead of dozens. Test with "View as role". RLS does not apply to users with edit permission on the workspace.

Q7.7 Incremental refresh — when and how?

Short answer: When a large fact table has an immutable history and only a recent window changes. Define RangeStart/RangeEnd parameters in Power Query, set the archive and refresh windows, and ensure the source folds the query so partitions filter at source.

Keywords: RangeStart/RangeEnd, query folding, partitions, archive period, detect data changes

Watch out: if query folding breaks, incremental refresh silently pulls everything — verify folding.

Q7.8 Power Query vs DAX — where should transformation happen?

Short answer: As far upstream as possible: source system > Power Query (M) > DAX. Shaping, cleansing, type-setting and joins belong in Power Query; business calculations that must respond to slicers belong in DAX.

Keywords: query folding, ETL vs analytics, M language, measures, upstream principle

Q7.9 Deployment pipelines and Power BI ALM

Short answer: Dev → Test → Prod workspaces with deployment pipelines, parameterised data sources rebound per stage, semantic models separated from reports so multiple reports share one governed model, and source control via Fabric Git integration.

Keywords: deployment pipelines, workspaces, dataset/report separation, parameters, Git integration, XMLA endpoint

Q7.10 Gateway architecture — what does an architect need to say?

Short answer: Use a standard mode gateway in a cluster for high availability, sized on memory and concurrency, placed close to the data source, with separate clusters for production and dev, and monitored for queue length and failures.

Keywords: on-premises data gateway, cluster, high availability, personal mode (avoid), throughput, mashup engine memory

Q7.11 Dashboard vs report vs semantic model vs app

Short answer: Semantic model = the data and logic. Report = multi-page interactive analysis over a model. Dashboard = single-page pinned tiles across multiple reports (Power BI Service only). App = the packaged, permissioned distribution unit for consumers.

Keywords: semantic model, report, dashboard, app, workspace, audience

Q7.12 Give a DAX answer that shows seniority

Short answer example — YoY growth:

Sales YoY % =
VAR CurrentSales = [Total Sales]
VAR PriorSales =
    CALCULATE ( [Total Sales], SAMEPERIODLASTYEAR ( 'Date'[Date] ) )
RETURN
    DIVIDE ( CurrentSales - PriorSales, PriorSales )

Points to make: use VAR for readability and single evaluation; use DIVIDE not / to handle divide-by-zero; time intelligence requires a marked date table with contiguous dates.

Common performance anti-pattern to call out:

-- Slow: iterates and filters the whole table
Bad = CALCULATE ( [Sales], FILTER ( ALL ( Sales ), Sales[Amount] > 100 ) )

-- Better: predicate pushed to the storage engine
Good = CALCULATE ( [Sales], KEEPFILTERS ( Sales[Amount] > 100 ) )

8. Power Platform Governance

Q8.1 Design Power Platform governance for a 20,000-user enterprise

Short answer: Four pillars: environment strategy, data loss prevention, managed environments with controlled sharing, and a Centre of Excellence for visibility and adoption. Governance should make the paved road the easiest road, not block makers.

The structure I'd present:

Pillar	Decisions
Environments	Personal productivity (default, locked down), team dev, project Dev/Test/UAT/Prod, sandbox refresh policy
Default environment	Restrict creation, apply strictest DLP, treat as personal-productivity only
DLP	Business / non-business / blocked connector groups; separate policies per environment tier; block custom connectors in default
Managed environments	Sharing limits, weekly digest, maker welcome content, solution checker enforcement
Identity	Service principals for automation; no personal connections in production
ALM	Solutions + pipelines mandatory for anything business-critical
Monitoring	CoE Starter Kit, admin analytics, capacity alerts, orphaned-object cleanup on leaver events
Support model	Tiered: personal → departmental → IT-supported, with promotion criteria
Enablement	Maker onboarding, templates, champions, office hours

Keywords: environment strategy, DLP, managed environments, CoE Starter Kit, tenant settings, capacity, service principals, paved road

Trade-off to state: over-restriction pushes makers to shadow IT (personal tenants, Excel macros). Governance is a risk-appetite conversation, not a technical one.

Q8.2 What does DLP actually control — and what does it not?

Short answer: DLP controls which connectors can be used together in the same app or flow, by classifying connectors as business, non-business or blocked. It does not inspect data content, does not classify records, and does not stop a user copying data by hand.

Keywords: connector classification, cross-group blocking, endpoint filtering, environment-scoped policies, custom connector control

Q8.3 How do you handle a maker who leaves the company?

Short answer: Orphaned objects are found and reassigned proactively: CoE inventory identifies apps/flows owned by disabled accounts, ownership is reassigned to a service principal or team, and connection references are re-bound. Production automation should never have been on a personal identity in the first place.

Keywords: orphaned apps/flows, ownership reassignment, service principal, connection references, leaver process

Q8.4 Capacity and licensing — the architect's view

Short answer: Know the three cost drivers: user licences, Dataverse capacity (database/file/log), and API request entitlements. Design decisions that inflate any of them — auditing everything, storing attachments in Dataverse, per-row API calls — are cost decisions.

Keywords: per-user/per-app licensing, Dataverse capacity, API request entitlement, pay-as-you-go, capacity alerts

Verify current licensing on Microsoft Learn before quoting specifics — this changes often.

9. ALM / DevOps

Q9.1 Describe your end-to-end ALM pipeline

Short answer: Dev environment (unmanaged) → export unpacked solution to Git → build pipeline runs solution checker and packs → deploy managed to Test → automated/UAT validation → deploy managed to Prod, with environment variables and connection references supplying environment-specific values, and a documented rollback.

Keywords: unmanaged in dev, managed downstream, PAC CLI, Power Platform Build Tools, solution checker, environment variables, connection references, deployment settings file

Pipeline stages to name:

Stage	Actions
Commit	Export solution, unpack, commit to Git branch, PR review
Build	Pack solution, run Solution Checker, fail on high-severity
Deploy Test	Import managed, apply deployment settings, run smoke tests
Deploy UAT	Same artifact, business validation
Deploy Prod	Same artifact, change ticket, post-deploy verification
Rollback	Restore prior managed solution version / environment backup

Q9.2 Managed vs unmanaged solutions

	Unmanaged	Managed
Editable	Yes	No (except allowed customisations)
Use in	Dev only	Test / UAT / Prod
Uninstall	Doesn't remove components cleanly	Removes its components
Layering	Base layer	Layers on top, supports patches/upgrades

Short answer: Unmanaged is source; managed is a deployment artifact. Importing unmanaged into production is the single most common ALM mistake — it makes the environment unmaintainable because you can no longer cleanly upgrade or remove.

Q9.3 Why environment variables and connection references?

Short answer: They externalise environment-specific configuration so the same managed artifact moves through every stage. Without them you either edit in production or maintain divergent solutions — both break repeatability.

Keywords: deployment settings file, configuration as data, no hardcoding, same artifact promotion

Q9.4 How do you roll back a bad Power Platform release?

Short answer: Re-import the previous managed solution version, or restore the environment from a system/manual backup taken pre-deployment for data-affecting changes. The real answer is that rollback must be tested, and data migrations need a forward-fix plan because you can't un-migrate rows.

Keywords: solution version, environment backup/restore, forward fix, pre-deploy backup, change window

Q9.5 How do you source-control Power Platform properly?

Short answer: Export and unpack the solution with PAC CLI so components become individual files, commit those, and review real diffs in pull requests. Committing a .zip gives you storage, not version control.

Keywords: pac solution unpack, Git, meaningful diffs, branch strategy, PR review, Fabric/Power Platform Git integration

10. Microsoft Copilot Studio

Q10.1 What is Copilot Studio and where does it fit?

Short answer: Copilot Studio is the low-code platform for building conversational agents that combine authored topics, generative answers over enterprise knowledge, and actions via connectors, Power Automate and Dataverse — governed by Power Platform ALM, DLP and environment strategy.

Keywords: agents, topics, generative answers, knowledge sources, actions, orchestration, channels

Positioning line to use: "Copilot Studio is where the business owns the agent; Azure AI Foundry is where engineering owns it."

Q10.2 Copilot Studio vs Azure AI Foundry vs Azure OpenAI

	Copilot Studio	Azure AI Foundry	Azure OpenAI (direct)
Audience	Makers, business teams	AI engineers	Developers
Build style	Low-code, topics + generative orchestration	Code-first + portal, agents, prompt flow, evaluations	API calls, you build everything
Governance	Power Platform (DLP, environments, solutions)	Azure RBAC, networking, Azure Policy	Azure RBAC
Channels	Teams, M365 Copilot, web, voice, out of the box	You build the surface	You build everything
Best for	Enterprise assistants over M365/Dataverse content	Custom AI apps, multi-agent, evaluation-heavy	Full control, bespoke stacks

Short answer: Copilot Studio for fast, governed, channel-ready enterprise agents. AI Foundry when you need custom orchestration, model choice, evaluation pipelines, tracing and deeper Azure integration. Direct Azure OpenAI when you're building the whole application yourself.

Q10.3 Topic-based vs generative orchestration

Short answer: Topics are deterministic — a trigger phrase leads to a defined dialog, and you can guarantee behaviour. Generative orchestration lets the model choose which topics, knowledge and actions to use to fulfil a request. Use deterministic topics where compliance or transactions demand certainty; generative where the question space is open.

Keywords: trigger phrases, deterministic dialog, generative orchestration, tool/action selection, guardrails

Architect line: "High-risk actions stay in authored topics with explicit confirmation; open Q&A goes generative."

Q10.4 How do you prevent hallucinations in an enterprise agent?

Short answer: Ground it: restrict answers to approved knowledge sources, turn off general model knowledge where accuracy matters, require citations, set a confidence/fallback path to "I don't know, here's how to reach a human", and evaluate against a test set before and after every change.

Keywords: grounding, RAG, knowledge sources, citations, fallback topic, content moderation level, evaluation set, human escalation

If pushed deeper:

Most "hallucination" complaints in production are actually retrieval failures — bad chunking, missing documents, or poor source hygiene.
Curate sources: one authoritative version of each document, remove drafts and duplicates.
Log unanswered and low-confidence questions; that log is your content backlog.

Real-world example: An HR agent's accuracy went from ~70% to ~92% not by changing models but by de-duplicating a SharePoint library and re-chunking policies by section heading.

Q10.5 How do you secure an enterprise copilot?

Short answer: Authenticate users with Entra ID, honour source-level permissions so answers respect what the user can already see, scope actions with least-privilege connections, apply DLP to connectors, keep it in a governed environment with ALM, and log conversations for audit.

Keywords: Entra authentication, security trimming, least privilege, DLP, environment isolation, audit, PII handling

The critical point: if an agent runs actions under a single service identity, it can leak data across users. Either use the user's identity, or filter results by the user's permissions explicitly.

Q10.6 How do you connect an agent to Dataverse and to Power Automate?

Short answer: Dataverse can be a knowledge source for retrieval and a data source for actions; Power Automate flows are called as actions with typed inputs and outputs, letting the agent perform transactions the model itself can't be trusted to do.

Keywords: actions, flow inputs/outputs, Dataverse knowledge, connectors, authentication context

Design rule: the model decides what to do; a deterministic flow decides whether it's allowed and performs it.

Q10.7 How do you do ALM and analytics for Copilot Studio?

Short answer: Agents are solution components — build in Dev, export managed, deploy through pipelines with environment variables for knowledge source URLs and connection references for actions. Use built-in analytics for resolution rate, escalation rate, engagement and abandoned sessions, and pair it with a manual quality review.

Keywords: solutions, environment variables, connection references, analytics, resolution rate, escalation rate, CSAT

Q10.8 Design an enterprise support agent

Short answer structure:

Layer	Decision
Channels	Teams first (where users are), then web widget
Identity	Entra SSO; agent knows who is asking
Knowledge	Curated SharePoint/knowledge base, security-trimmed, chunked by heading
Deterministic topics	Password reset, ticket status, high-risk actions with confirmation
Generative answers	Open how-do-I questions with citations
Actions	Create/update ticket via ServiceNow or Dataverse through Power Automate
Escalation	Confidence threshold or user request → live agent with transcript handoff
Guardrails	Blocked topic list, content moderation, no PII echo, action allowlist
Measurement	Containment rate, deflection, accuracy sample, CSAT, cost per conversation
ALM	Solutions, pipelines, evaluation set run per release

11. Azure — Core & Architecture

Q11.1 App Service vs Functions vs Container Apps vs AKS

	App Service	Functions	Container Apps	AKS
Model	Managed web apps	Event-driven, serverless	Serverless containers, microservices	Full Kubernetes
Scale	Instance-based	Per-execution, scale to zero	KEDA-based, scale to zero	You control it
Ops burden	Low	Lowest	Low-medium	High
Use when	Classic web APIs/sites	Short event-driven work, glue	Containerised microservices without K8s ops	You need full K8s control/ecosystem

Short answer: Default to the most managed option that meets the requirement. Functions for event-driven glue, App Service for standard web workloads, Container Apps for containerised microservices without Kubernetes overhead, AKS only when you genuinely need Kubernetes primitives.

Q11.2 Service Bus vs Event Grid vs Event Hubs

	Service Bus	Event Grid	Event Hubs
Purpose	Enterprise messaging (commands)	Event routing / reactive notifications	High-throughput event streaming/ingestion
Guarantees	Ordering (sessions), transactions, dead-letter, at-least-once	At-least-once delivery, retry	Partitioned stream, consumer offsets, replay
Volume	Moderate, high value per message	Discrete events	Millions of events/sec
Use for	Order processing, decoupled workflows	"Blob created → do something"	Telemetry, IoT, logs, analytics pipelines

One-liner: Service Bus = "do this"; Event Grid = "this happened, react"; Event Hubs = "here's a firehose".

Q11.3 Managed identity vs service principal

Short answer: Managed identity is a service principal, but Azure manages its credential lifecycle — no secrets to store or rotate. Use system-assigned for a single resource's identity, user-assigned when several resources share one identity or the identity must outlive the resource. Only use an app registration with a secret/certificate when the caller is outside Azure.

Keywords: system-assigned, user-assigned, no secrets, RBAC, federated credentials, workload identity

Extra credit: mention workload identity federation to eliminate secrets for GitHub Actions/external workloads.

Q11.4 How do you secure traffic between Power Platform and Azure?

Short answer: Authenticate with Entra ID (service principal or managed identity) rather than API keys, expose the Azure service through API Management with policies and rate limits, use a custom connector with OAuth, and where the connector supports it use private endpoints or the Power Platform's VNet support; secrets stay in Key Vault.

Keywords: OAuth 2.0, custom connector, API Management, Key Vault, private endpoint, VNet integration, DLP, IP firewall

Honest caveat to state: connector-level networking has limits — check current support for VNet/private endpoint from Power Platform before promising it.

Q11.5 API Management vs Application Gateway vs Front Door

	API Management	Application Gateway	Front Door
Layer	API gateway (L7, API-aware)	Regional L7 load balancer + WAF	Global L7 entry point + WAF + CDN
Adds	Policies, throttling, versioning, subscriptions, developer portal	Path routing, SSL offload, WAF	Global routing, failover, caching, acceleration
Scope	API lifecycle	Regional	Global/multi-region

Short answer: They compose rather than compete: Front Door for global entry and failover, Application Gateway for regional L7/WAF, API Management for API policy, security and lifecycle. If the question is "expose and govern an API", it's APIM.

Q11.6 Storage redundancy — LRS, ZRS, GRS, RA-GRS, GZRS

Short answer: LRS = three copies in one datacentre. ZRS = across availability zones in one region. GRS = LRS plus async copy to a paired region. RA-GRS = GRS with read access to the secondary. GZRS = ZRS plus geo-replication. Choose by RPO/RTO and cost, not by habit.

Keywords: durability, availability zones, paired region, RPO/RTO, failover, read access secondary

Q11.7 Design a highly available Power Platform + Azure solution

Short answer structure:

Front end: Power Apps / Power Pages (platform-managed HA).
Data: Dataverse (geo-redundant by design) as system of record; Azure SQL with zone-redundant configuration and geo-replication for the reporting store.
Integration: Service Bus (premium, zone-redundant) with dead-lettering; retries with backoff everywhere.
Compute: Functions on a zone-redundant plan or Container Apps, stateless, idempotent handlers.
Global entry: Front Door for multi-region failover of custom APIs.
Ops: health probes, Application Insights availability tests, alerts, runbooks, tested DR with documented RPO/RTO.

Say this: "HA is about surviving component failure; DR is about surviving region loss. They need different designs and different budgets — I'd get the business to state RPO and RTO before choosing."

Q11.8 Durable Functions — when and why?

Short answer: When you need stateful orchestration in code: fan-out/fan-in over thousands of items, long-running workflows with checkpoints, human interaction with timeouts, or chained steps that must survive restarts.

Keywords: orchestrator, activity functions, fan-out/fan-in, event sourcing, checkpointing, eternal orchestration

Real-world example: Batch processing of 12,000 queue items fanned out across activity functions with automatic checkpointing — a host restart resumed instead of restarting.

12. Azure Integration Patterns

Q12.1 Which integration pattern do you pick?

Pattern	Use when	Azure services
Request/response	Caller needs an immediate answer	APIM + Functions/App Service
Fire and forget / queue	Decoupling, load levelling, retries	Service Bus queue
Publish/subscribe	Many consumers, independent scaling	Service Bus topics, Event Grid
Streaming	High-volume telemetry, replay	Event Hubs
Batch / ETL	Scheduled bulk movement	Data Factory, Synapse, Fabric pipelines
Change data capture	React to source changes	Event Grid, CDC, Dataverse events

Q12.2 How do you integrate Power Platform with Service Bus?

Short answer: Dataverse can publish events to Service Bus via the service endpoint registration (plug-in registration tool), giving you reliable, decoupled downstream processing without polling. Flows and Functions consume from the queue with dead-lettering for poison messages.

Keywords: service endpoint, plug-in registration, async publishing, dead letter queue, decoupling, at-least-once

Q12.3 Power Automate vs Azure Functions

Short answer: Power Automate for connector-rich orchestration with low code and business ownership; Functions for custom logic, high volume, precise performance and cost control. In practice a flow calls a Function for the heavy part.

Keywords: connectors vs code, throughput, cost model, cold start, maintainability, fusion team

Q12.4 How do you design idempotent integrations?

Short answer: Every message carries a unique business key; the receiver checks or upserts on that key; state transitions are safe to repeat; and you assume at-least-once delivery everywhere. Idempotency is what makes retries safe, and retries are what make distributed systems reliable.

Keywords: idempotency key, upsert, at-least-once, deduplication window, exactly-once illusion, compensating transaction

13. Azure & Platform Security

Q13.1 Explain Zero Trust as it applies to this stack

Short answer: Verify explicitly, use least privilege, assume breach. Practically: Entra ID with Conditional Access and MFA for every identity including service identities where possible, RBAC scoped to resource, network isolation with private endpoints, secrets in Key Vault, and full telemetry so you can detect and contain.

Keywords: Conditional Access, least privilege, JIT/PIM, private endpoint, Key Vault, Defender for Cloud, segmentation

Q13.2 OAuth 2.0 and OpenID Connect in one answer

Short answer: OAuth 2.0 is authorisation — it issues access tokens so an app can call an API on a user's or its own behalf. OIDC is an identity layer on top of OAuth that adds an ID token so the app knows who the user is. Delegated permissions act as the user; application permissions act as the app.

Keywords: authorisation code flow with PKCE, client credentials, delegated vs application permissions, scopes, ID token vs access token, consent

Q13.3 How do you protect against prompt injection and AI data leakage?

Short answer: Treat model output as untrusted input. Separate instructions from retrieved content, filter and validate model output before acting on it, keep tools/actions on an allowlist with least-privilege identities, require confirmation for high-impact actions, and never rely on the system prompt alone as a security control.

Keywords: prompt injection, indirect injection via documents, output validation, tool allowlist, least privilege, human-in-the-loop, content filters, grounding boundaries

Say this: "The system prompt is a guideline, not a security boundary. The security boundary is the permission on the tool."

Q13.4 How do you handle sensitive data in an AI solution?

Short answer: Classify first, then minimise: don't send what isn't needed, redact or tokenise PII before it reaches the model, keep data in-region, disable or scope logging that would persist prompts, apply source-level security trimming to retrieval, and document the data flow for privacy review.

Keywords: data classification, PII redaction, data residency, retention, security trimming, purview, DLP, abuse-monitoring opt-out considerations

14. Azure AI Services

Q14.1 Map the Azure AI portfolio in one answer

Need	Service
Extract data from forms, invoices, IDs	Azure AI Document Intelligence
Read text from images/scans	Azure AI Vision (OCR)
Classify, summarise, extract entities, detect PII	Azure AI Language
Speech to text, text to speech, translation	Azure AI Speech
Retrieval for RAG (keyword + vector + semantic)	Azure AI Search
Frontier/LLM models, chat, embeddings	Azure OpenAI in Azure AI Foundry
Custom ML training and MLOps	Azure Machine Learning
Build, evaluate, monitor AI apps and agents	Azure AI Foundry
Filter harmful content, jailbreak detection	Azure AI Content Safety

Q14.2 Design an enterprise document-processing solution

Short answer: Ingest → classify → extract → validate → integrate, with a human-in-the-loop path and full audit.

Reference flow to describe:

Documents land in Blob Storage or arrive via email/SharePoint.
Event Grid triggers processing.
Azure AI Document Intelligence extracts fields (prebuilt model where one exists, custom model where it doesn't).
Confidence scoring: high confidence auto-posts; low confidence routes to a review queue in Power Apps.
Business validation rules run deterministically (totals, dates, duplicate check by invoice number).
Results written to Dataverse/ERP with the source document linked.
Metrics: straight-through-processing rate, field-level accuracy, exception reasons.

Keywords: Document Intelligence, prebuilt vs custom model, confidence threshold, human-in-the-loop, straight-through processing, audit trail

Trade-off to state: "The business will ask for 100% automation. I'd target a confidence threshold that gives high precision, and measure straight-through-processing rate as the real KPI."

Q14.3 Embeddings, vector search, semantic search, hybrid search

Short answer: An embedding is a numeric vector representing meaning. Vector search finds nearest neighbours by similarity. Keyword search matches terms. Hybrid runs both and fuses the results, and semantic ranking re-ranks the top results with a language model. Hybrid + semantic ranking is usually the best default for enterprise RAG.

Keywords: embedding model, cosine similarity, ANN/HNSW, BM25, hybrid retrieval, reciprocal rank fusion, semantic reranker

Why it matters: pure vector search fails on exact identifiers (part numbers, policy codes); pure keyword fails on paraphrase. Hybrid covers both.

15. Azure AI Foundry

Q15.1 What is Azure AI Foundry?

Short answer: Azure's unified platform for building, evaluating, deploying and monitoring AI applications and agents — model catalog and deployment, prompt/agent orchestration, tool integration, evaluation and tracing, content safety, and enterprise controls like RBAC, networking and observability, organised into projects.

Keywords: projects, model catalog, agents, tools, evaluations, tracing, content safety, governance

Q15.2 Foundry vs "just calling Azure OpenAI"

Short answer: Calling Azure OpenAI directly gives you inference. Foundry gives you the lifecycle around it: model comparison and choice, agent and tool orchestration, systematic evaluation, tracing of multi-step runs, safety configuration and monitoring. For anything going to production and being iterated on, the lifecycle is the point.

Keywords: lifecycle, evaluation, observability, model choice, governance, deployment

Q15.3 How do you evaluate an AI application?

Short answer: Build a golden dataset of representative inputs with expected outputs, then measure with both automated metrics and human review: groundedness, relevance, retrieval quality, coherence, safety, and task success. Run evaluation as a gate on every prompt, model or index change — treat prompts as code.

Keywords: golden dataset, groundedness, relevance, retrieval precision/recall, LLM-as-judge, regression testing, A/B, human review

If pushed deeper:

Separate retrieval metrics from generation metrics — most failures are retrieval.
Track cost and latency alongside quality; a 3% accuracy gain for 4× cost is a business decision.
Online evaluation matters too: sample production traffic, log user feedback, monitor drift.

Real-world example: A 120-question golden set caught a 9-point groundedness regression when a model version changed — before users saw it.

Q15.4 How do you monitor an AI application in production?

Short answer: Trace every request end to end (prompt, retrieved chunks, tool calls, tokens, latency, output), log user feedback, dashboard quality and cost metrics, and alert on failure rate, latency, refusal rate and content-safety triggers.

Keywords: tracing, spans, token usage, latency, drift, feedback loop, content safety signals, Application Insights

Q15.5 How do you secure an enterprise AI application?

Short answer: Managed identity for service-to-service auth, private endpoints and disabled public network access, data kept in-region, content filters configured per use case, tool permissions on least privilege, prompts and outputs logged with PII handling agreed, and RBAC scoped per project.

Keywords: managed identity, private endpoint, network isolation, RBAC, content filters, data residency, key rotation, Key Vault

16. Generative AI

Q16.1 RAG vs fine-tuning

	RAG	Fine-tuning
Adds	Knowledge, current facts	Behaviour, format, style, domain tone
Freshness	Immediate (update the index)	Requires retraining
Cost	Retrieval + longer prompts	Training + hosting
Traceability	Citations possible	None
Best for	Enterprise knowledge, policies, docs	Consistent structured output, niche language, latency/token reduction

Short answer: RAG when the problem is knowledge; fine-tuning when the problem is behaviour. Most enterprise problems are knowledge problems, so start with RAG plus good prompting; fine-tune only when you can show prompting and retrieval have hit a ceiling.

Q16.2 How do you reduce hallucinations?

Short answer: Ground answers in retrieved content, instruct the model to answer only from context and to say when it doesn't know, require citations, lower temperature for factual tasks, validate output structure, and evaluate groundedness continuously. Fix retrieval before blaming the model.

Keywords: grounding, citations, refusal path, temperature, structured output, groundedness metric, chunking quality

Q16.3 How do you reduce token cost and latency?

Short answer: Right-size the model per task (small model for classification/routing, large only where reasoning is needed), trim prompts and retrieved context, cache repeated results, use streaming for perceived latency, batch where possible, and set max token limits.

Keywords: model routing, context trimming, prompt caching, semantic cache, streaming, max_tokens, small language models

Real-world example: Routing 70% of traffic (simple FAQ) to a small model and reserving the large model for complex cases cut cost roughly in half with no measurable quality drop on the evaluation set.

Q16.4 How do you select a model?

Short answer: Define the task and the constraints first — accuracy target, latency budget, cost per 1,000 calls, context length, region availability, data-handling requirements — then benchmark two or three candidates on your evaluation set. Never select on leaderboard scores alone.

Keywords: evaluation set, latency, cost per token, context window, region/data residency, modality, model lifecycle/deprecation

Q16.5 Temperature, top-p, context window, tokens — the crisp answers

Term	One-line answer
Token	The unit the model reads and generates; roughly ¾ of a word in English
Context window	Maximum tokens of prompt + response the model can consider at once
Temperature	Randomness of sampling; low for factual/deterministic, higher for creative
Top-p	Nucleus sampling — sample from the smallest set of tokens whose cumulative probability exceeds p
System prompt	Instructions setting role, constraints and output format for the whole conversation
Few-shot	Providing examples in the prompt to demonstrate the desired pattern

17. RAG Architecture

Q17.1 Describe a production RAG architecture

Short answer: Ingest → chunk → embed → index → retrieve → rerank → generate with citations → evaluate and monitor. Security trimming applies at retrieval, not after generation.

Detail worth saying:

Stage	Decisions
Ingestion	Source of truth per document, incremental sync, change detection, deletion handling
Chunking	Semantic/heading-based chunks with overlap; size tuned to the content, not copied from a blog
Metadata	Source, permissions, date, document type — this is what enables filtering and trimming
Index	Azure AI Search with vector + keyword fields; hybrid retrieval
Retrieval	Hybrid search, metadata filters, top-K tuned, semantic reranking
Generation	Answer only from context, cite sources, refuse when unsupported
Evaluation	Retrieval precision/recall + groundedness + answer relevance
Ops	Reindex pipeline, freshness monitoring, unanswered-question log

Q17.2 RAG retrieves irrelevant documents. How do you fix it?

Diagnostic order:

Is the right chunk even in the index? (ingestion/permission/filter problem)
Is it retrieved but ranked low? (switch to hybrid, add semantic reranker, raise top-K then rerank)
Are chunks too large or split mid-concept? (re-chunk on headings, add overlap)
Is the query poorly formed? (query rewriting, expand acronyms, use conversation history)
Is the embedding model wrong for the domain? (test alternatives on a labelled set)

Keywords: chunking strategy, hybrid search, reranking, query rewriting, metadata filters, top-K, embedding model choice

Q17.3 How do you keep RAG answers permission-aware?

Short answer: Store the ACL or group identifiers as index metadata and filter at query time by the caller's groups, or use a search platform feature that trims by identity. Never retrieve broadly and filter after generation — the content is already in the prompt by then.

Keywords: security trimming, ACL metadata, group claims, filter at retrieval, per-user index vs filtered index

18. Agentic AI

Q18.1 What is an agent, and how is it different from a chatbot or a workflow?

Short answer: A chatbot responds. A workflow executes predefined steps. An agent is given a goal and decides which tools and steps to use to achieve it, observing results and adapting — with memory, tool access and a stopping condition.

Keywords: goal-directed, planning, tool/function calling, observation loop, memory, autonomy, termination condition

Q18.2 Agent vs deterministic workflow — when do you choose which?

Short answer: Deterministic workflow when the path is known, repeatable and auditable — which covers most business processes. Agent when the path varies by input, the decision space is large, or the work requires interpretation. In practice, use an agent to decide and a workflow to execute.

Decision table:

Signal	Choose
Regulated, must be reproducible	Workflow
Same steps every time	Workflow
High cost of a wrong action	Workflow (or agent + human approval)
Unstructured input, variable path	Agent
Requires synthesis across sources	Agent
Needs cost predictability	Workflow

Say this: "Autonomy is a cost — you pay for it in predictability, testability and audit. I only buy it where variability justifies it."

Q18.3 Design an agent that reads emails, analyses requests, retrieves knowledge, updates Dataverse and requests approval

Answer structure:

Layer	Design
Trigger	Graph subscription / shared mailbox flow; message queued for processing
Understand	Model classifies intent, extracts entities, scores confidence
Retrieve	RAG over policy/knowledge base with security trimming
Decide	Agent selects tool: create case, update record, ask clarifying question, escalate
Act	Deterministic Power Automate/Custom API performs the write — never free-form writes
Guardrails	Tool allowlist, per-tool permission, value threshold requiring approval, no destructive tools
Human-in-the-loop	Approval request with the evidence and the proposed action shown
Memory	Conversation/thread state in Dataverse, keyed to the email conversation ID
Observability	Trace every step: input, retrieved chunks, tool calls, output, tokens, latency
Failure path	Low confidence or tool failure → route to human queue with context
Evaluation	Golden set of past emails with correct outcomes; accuracy and false-action rate

Keywords to hit: function calling, tool allowlist, least privilege, human-in-the-loop, idempotency, tracing, confidence thresholds, escalation

Q18.4 How do you stop an agent taking an unauthorised action?

Short answer: Constrain capability, not just instructions: give the agent a small allowlist of tools, run each tool under a least-privilege identity, validate parameters server-side, require confirmation or approval above a risk threshold, cap iterations and spend, and log every call for audit.

Keywords: tool allowlist, least privilege identity, server-side validation, approval threshold, iteration cap, budget cap, audit log, kill switch

Line that lands: "I assume the prompt can be subverted. The control that holds is the permission on the tool and the validation in the API."

Q18.5 Multi-agent systems — when are they justified?

Short answer: When tasks genuinely decompose into specialised roles with different tools or knowledge, and the coordination cost is worth it. Otherwise a single well-instructed agent with good tools is cheaper, faster and far easier to debug.

Keywords: orchestrator/worker, specialisation, handoff, shared state, coordination overhead, debuggability, cost multiplication

Trade-off: every extra agent multiplies tokens, latency and failure modes. Start single-agent; split only when you can name the specialisation.

Q18.6 How do you handle agent memory?

Short answer: Distinguish short-term (conversation context, trimmed or summarised), long-term (facts persisted deliberately in a store like Dataverse or a vector index), and episodic (past runs and outcomes). Persist only what has a defined purpose and retention, because memory is a privacy surface.

Keywords: context window management, summarisation, persistent store, retrieval-based memory, retention policy, PII

Q18.7 How do you evaluate and observe agents?

Short answer: Evaluate at three levels: did it pick the right tool, did each step succeed, and did the overall task complete correctly. Trace the full trajectory, and measure task success rate, tool-selection accuracy, steps per task, cost per task, escalation rate and unsafe-action rate.

Keywords: trajectory evaluation, tool-selection accuracy, task success rate, cost per task, tracing, regression suite

19. Microsoft Graph

Q19.1 How do you integrate Power Platform with Microsoft Graph?

Short answer: Register an app in Entra ID, grant the minimum Graph permissions (delegated if acting as the user, application if unattended), store the secret or certificate in Key Vault, and call Graph either through a custom connector with OAuth or from an HTTP action / Azure Function. Handle paging, throttling and consent properly.

Keywords: app registration, delegated vs application permissions, admin consent, custom connector, Key Vault, @odata.nextLink, 429/Retry-After

If pushed deeper:

Application permissions are tenant-wide — scope them with Graph application access policies (e.g. restricting mail or calendar access to specific mailboxes).
Always follow @odata.nextLink for paging; use $select to reduce payload; use $batch to combine requests.
Prefer delta queries and change notifications (webhooks) over polling.

Real-world example: A joiner/leaver automation used application permissions scoped by an access policy, delta queries for changed users, and $batch to cut request volume by 60%.

Q19.2 Delta query vs change notifications vs polling

	Polling	Delta query	Change notifications
How	Repeated full/filtered reads	Token-based "what changed since"	Webhook push to your endpoint
Latency	Interval-bound	Interval-bound but cheap	Near real-time
Cost	High	Low	Lowest
Use for	Simple, low volume	Sync jobs	Reactive automation

Watch out: notifications may not include the payload (or may be resource-data with validation requirements) and subscriptions expire — you must renew them, and you need a reconciliation job because webhooks can be missed.

Q19.3 Common Graph interview traps

Trap	Correct answer
"I'd use Global Admin"	Use least-privilege Graph permissions; admin consent is not the same as admin rights
Ignoring paging	Follow `@odata.nextLink` until null
Ignoring throttling	Honour `Retry-After`, backoff, reduce concurrency
Storing the secret in the flow	Key Vault, or use certificate/managed identity where supported
Assuming delegated = unattended	Delegated needs a signed-in user; unattended needs application permissions

20. Integration Architecture — Pattern Reference

Integration	Recommended approach	Watch out for
Power Apps → Dataverse	Native connector, delegable queries, views	Delegation limits, N+1 lookups
Power Automate → Azure Functions	Custom connector or HTTP with Entra auth	120s sync HTTP limit — go async for long work
Power Automate → Graph	Custom connector, app registration, least privilege	Paging, throttling, consent
Dataverse → Azure	Service endpoint to Service Bus/Event Grid, or plug-in	Don't do long-running work in-transaction
Power Platform → SQL	Gateway or Azure SQL with private networking, views/stored procs	Delegation, connection identity, credential management
Copilot Studio → Dataverse	Knowledge source + actions via flows	Security trimming, user identity vs service identity
Copilot Studio → Azure AI	Foundry-backed models/knowledge, or actions to a custom API	Governance boundary, data residency
Power BI → Dataverse	Native connector, or TDS endpoint, or export to Fabric/Lakehouse	Query volume against transactional store
Power BI → Fabric	OneLake, Direct Lake semantic models	Capacity sizing, fallback behaviour
Power Platform → SharePoint	Documents in SharePoint, records in Dataverse, linked	List thresholds, delegation gaps
Power Platform → D365	Same Dataverse — extend, don't duplicate	Solution layering, upgrade safety
RPA → any system	Prefer API; PAD only where no API exists	Brittleness, credential handling

Architect framing to use: "I'd choose the integration style by coupling and volume: synchronous where the caller needs an answer, queued where the systems must be independent, streamed where volume is high, and batch where latency doesn't matter."

21. Troubleshooting Bank (50)

Format: Problem → Likely causes → How to diagnose → Fix. Keep answers to this shape in the interview; it demonstrates method, which is what's being scored.

21.1 Power Apps

#	Problem	Likely causes	Diagnose	Fix
1	App loads slowly	Heavy OnStart, too many collections, control count	Monitor tool, network trace	Trim OnStart, `Concurrent()`, lazy load, fewer controls
2	Gallery shows only 500/2000 rows	Non-delegable query	Blue delegation warning; check functions used	Rewrite with delegable operators, filter at source
3	Data saves but doesn't appear	Cached collection not refreshed	Check `Refresh()`/collection use	`Refresh(source)` after patch, or patch the collection too
4	Users see data they shouldn't	Security in UI only	Test via connector/Web API directly	Move to Dataverse security roles / field security
5	Patch fails silently	Required field, type mismatch, permission	`Errors()`, `IfError` capture	Validate inputs, surface error, log to App Insights
6	Slow gallery scrolling	Lookups inside gallery (N+1), images inline	Monitor per-item calls	Pre-join with a view, use thumbnails/URLs
7	App works for maker, fails for users	Missing share on connection/table/role	Compare role assignments	Share app + connection, assign security role
8	Offline data lost	`SaveData` not called or size limit	Test airplane mode	Save on change, cap dataset size, GUID keys for dedupe

21.2 Dataverse

#	Problem	Likely causes	Diagnose	Fix
9	429 service protection errors	Too many requests/concurrency	Trace logs, request counts	Backoff on `Retry-After`, batch, `CreateMultiple`, reduce parallelism
10	Plug-in timeout (2 min)	External call, unbounded loop	Plug-in trace log	Move work to async/queue, optimise queries
11	Slow view / query	Missing index, `contains`, link-entity explosion	FetchXML review, query timing	Index, `startswith`, reduce joins/columns
12	Infinite plug-in/flow loop	Update triggers itself	Trace by initiating user/depth	Depth check, filtering attributes, trigger conditions
13	Duplicate records from integration	No idempotency key	Compare source IDs	Alternate key + upsert
14	Storage cost spike	Audit on everything, attachments in Dataverse	Capacity analytics	Scope audit, move files to SharePoint/Blob
15	Rollup column stale	Rollups recalc on a schedule	Check last-calculated field	Accept the lag or use a plug-in/real-time calc
16	Import fails on relationships	Wrong load order, missing lookups	Error log by row	Load parents first, use alternate keys

21.3 Power Automate (cloud)

#	Problem	Likely causes	Diagnose	Fix
17	Flow times out	Long sync HTTP call, huge loop	Run history duration per action	Async pattern (202 + polling), split into child flows/queue
18	Flow throttled	Request volume, connector limits	429 in run history	Batch, reduce per-item actions, backoff, spread load
19	Parse JSON fails	Schema mismatch, nulls	Compare payload to schema	Regenerate schema, make properties nullable, defensive `coalesce`
20	Flow ran twice	Duplicate trigger, retry	Run history + trigger details	Idempotency key, concurrency control, trigger conditions
21	Connection expired	Personal connection, password change	Connection status	Service principal / service account, connection references
22	Flow slow with big loops	Sequential apply-to-each	Duration per iteration	Increase concurrency carefully, batch, filter array earlier
23	Flow disabled unexpectedly	Repeated failures, owner disabled	Admin center, run history	Fix root cause, reassign owner, alerting
24	Sensitive data in run history	Secure inputs/outputs off	Inspect a run	Enable secure inputs/outputs, restrict flow access

21.4 Power Automate Desktop / RPA

#	Problem	Likely causes	Diagnose	Fix
25	Desktop flow fails randomly	Timing, popups, session state	Screenshots/logs at failure	Dynamic waits, popup handling, state reset per transaction
26	Browser automation breaks after update	Selectors changed, driver mismatch	Compare selector to current DOM	Attribute-based selectors, pin/refresh driver, resilience checks
27	Unattended run does nothing	Session locked, credentials, machine offline	Machine status, run history	Correct unattended setup, credential rotation, machine group health
28	Excel automation fails	File locked, wrong sheet, add-ins	Try manual open on the machine	Close instances first, use explicit paths, prefer file/API access
29	Duplicate transactions	No queue item status handling	Compare queue vs target	Mark in-progress, idempotent write on business key
30	Bot too slow	Fixed sleeps, per-item app restart	Step timings	Dynamic waits, reuse session, parallel performers
31	Credentials exposed in logs	Logging inputs	Inspect logs	Key Vault, secure inputs, mask values
32	Queue grows faster than processing	Under-provisioned performers	Queue depth trend	Add bots/machine group capacity, or move to API integration

21.5 Power BI

#	Problem	Likely causes	Diagnose	Fix
33	Report slow	Bad model, heavy DAX, too many visuals	Performance Analyzer, DAX Studio	Star schema, fix DAX, fewer visuals, aggregations
34	Measure slow	`FILTER(ALL(...))`, nested iterators	Server timings — formula engine heavy	`KEEPFILTERS`, variables, push filters to storage engine
35	Refresh takes hours	Full refresh of large fact table	Refresh history	Incremental refresh with folding verified
36	Wrong totals	Bidirectional filters, ambiguity	Model view, test measures	Single-direction relationships, star schema
37	Gateway failures	Memory, credentials, single node	Gateway logs, monitoring	Cluster for HA, size memory, service account credentials
38	RLS not applied	User has workspace edit rights	Test "view as role" and as user	Move users to app/viewer role
39	Direct Lake behaves like DirectQuery	Fallback conditions hit	Check fallback/telemetry	Simplify model, size capacity, remove unsupported operations
40	Dataset refresh fails after schema change	Source column renamed/removed	Refresh error detail	Version source contracts, use views to insulate the model

21.6 Azure, AI and identity

#	Problem	Likely causes	Diagnose	Fix
41	Azure Function timeout	Long sync work, wrong plan	App Insights traces	Durable Functions, queue-based async, correct hosting plan
42	Service Bus messages stuck	Handler exception, lock expiry	Dead-letter queue inspection	Fix handler, extend lock/renew, DLQ replay process
43	Authentication failure (401/403)	Wrong scope, missing consent, expired secret	Token claims, Entra sign-in logs	Correct scope/permission, admin consent, rotate to certificate/MI
44	Managed identity fails	Identity not assigned, no RBAC, wrong resource	Token acquisition logs	Assign identity, grant RBAC at right scope, use correct client ID
45	Private endpoint unreachable	DNS not resolving to private IP	`nslookup` from inside VNet	Private DNS zone linked to VNet, correct A record
46	Copilot gives wrong answers	Retrieval failure, duplicate/outdated sources	Inspect citations for each answer	Curate sources, re-chunk, hybrid search + reranking
47	RAG returns irrelevant docs	Chunking, ranking, query form	Test retrieval independently of generation	Hybrid + semantic rerank, query rewriting, metadata filters
48	Agent took an unauthorised action	Over-permissive tools	Trace tool calls	Allowlist tools, least-privilege identity, approval threshold
49	AI cost spike	Large context, retries, wrong model	Token telemetry per endpoint	Trim context, route to smaller model, cache, cap max tokens
50	Model output breaks downstream	Unstructured/varying output	Log failures with raw output	Structured output/JSON schema, validate before acting, retry with repair prompt

22. Security Question Bank

#	Question	Short answer
1	What is least privilege in practice here?	Minimum Graph/Dataverse/Azure permissions per identity, per environment, reviewed periodically — not "Global Admin because it works"
2	Where do secrets live?	Key Vault, referenced by managed identity; never in flows, apps, code or environment variables in plain text
3	How do you secure a custom connector?	OAuth 2.0 with Entra, no API keys in the definition, scoped permissions, DLP classification, APIM in front
4	How do you stop data exfiltration via connectors?	DLP policies separating business/non-business connectors, blocking consumer connectors, endpoint filtering
5	Field-level security vs security roles	Roles control table/record access; field security profiles control specific sensitive columns for users/teams
6	How do you protect an external-facing portal?	Scoped table permissions, web roles by relationship, no global permissions, WAF, test as anonymous
7	Conditional Access relevance	Enforces MFA/device/location conditions on access to Power Platform and Azure resources
8	How do you audit access?	Dataverse auditing (scoped), Purview audit logs, Azure activity logs, agent conversation logs
9	Prompt injection defence	Untrusted output assumption, tool allowlists, server-side validation, human approval for high impact
10	PII in AI systems	Classify, minimise, redact before inference, control logging/retention, keep in-region, document the flow
11	Service principal secret rotation	Prefer certificates or managed identity/federated credentials; automate rotation; alert before expiry
12	Network isolation for AI services	Private endpoints, public network access disabled, DNS zones, egress control

23. Comparison Question Bank

1. Canvas vs model-driven app

Feature	Canvas	Model-driven	When to use
UI control	Pixel-level	Metadata-driven	Canvas for bespoke UX
Data	Any connector	Dataverse only	Model-driven for relational CRM-style apps
Security	Source-enforced	Dataverse roles built in	Model-driven when security is complex
Build speed	Medium	Fast for standard patterns	Model-driven for record management

2. Power Apps vs Power Pages

Feature	Power Apps	Power Pages	When
Audience	Internal, licensed	External / anonymous	Pages for customers, suppliers, citizens
Security	Dataverse roles	Web roles + table permissions	Pages needs its own security design
SEO / public	No	Yes	Pages for public-facing content

3. Power Automate vs Logic Apps

Feature	Power Automate	Logic Apps	When
Owner	Business	Engineering	Follow the ownership model
Networking	Limited	VNet, private endpoints (Standard)	Logic Apps for isolated networks
Cost	Per user/flow	Consumption/hosting	Logic Apps for high volume

4. Cloud flow vs desktop flow

Feature	Cloud flow	Desktop flow	When
Runs on	Cloud service	Windows machine	Desktop only when no API
Integration	Connectors/APIs	UI automation	Cloud first, always
Reliability	High	Depends on UI stability	Prefer cloud

5. Dataverse vs SQL

Feature	Dataverse	Azure SQL	When
Security	Row/field/hierarchy built in	You build it (RLS)	Dataverse for complex business security
Logic	Plug-ins, business rules	T-SQL, app tier	Dataverse for business-app logic
Volume/cost	Capacity-priced	Compute-priced, higher scale	SQL for very large or analytical volumes

6. Dataverse vs SharePoint

Feature	Dataverse	SharePoint	When
Data shape	Relational	Lists + documents	Dataverse for related entities
Delegation	Strong	Partial	Dataverse for large data in apps
Documents	Links to SharePoint	Native	SharePoint for the file body

7. Power Automate vs Azure Functions

Feature	Flow	Function	When
Style	Low-code orchestration	Code	Function for custom/heavy logic
Volume	Moderate	High	Function above flow's practical limits
Connectors	1,000+	You write them	Flow for SaaS integration

8. Service Bus vs Event Grid

Feature	Service Bus	Event Grid	When
Semantics	Commands, ordered, transactional	Event notifications	Service Bus for business messages
Delivery	Pull, sessions, DLQ	Push, retry	Event Grid for reactive triggers

9. Event Grid vs Event Hubs

Feature	Event Grid	Event Hubs	When
Volume	Discrete events	Millions/sec streams	Event Hubs for telemetry
Replay	No	Yes (offsets)	Event Hubs when you need replay

10. API Management vs Application Gateway

Feature	APIM	App Gateway	When
Focus	API policy/lifecycle	L7 routing + WAF	APIM to govern APIs
Features	Throttle, transform, version, portal	Path routing, SSL, WAF	App Gateway for regional web ingress

11. Azure OpenAI vs Azure AI Foundry

Feature	Azure OpenAI	AI Foundry	When
Scope	Model inference	Full AI app lifecycle	Foundry for production apps
Adds	—	Evaluation, tracing, agents, catalog	Foundry when you must iterate safely

12. AI Foundry vs Copilot Studio

Feature	AI Foundry	Copilot Studio	When
Audience	AI engineers	Makers	Copilot Studio for speed and M365 reach
Control	Deep	Guardrailed	Foundry for custom orchestration
Governance	Azure RBAC/network	Power Platform DLP/environments	Follow the ownership model

13. RAG vs fine-tuning — see §16.1.

14. AI agent vs chatbot

Feature	Chatbot	Agent	When
Behaviour	Responds	Plans and acts	Agent when actions are needed
Tools	Few/none	Tool calling	Agent for multi-step tasks
Risk	Low	Higher — needs guardrails	Chatbot when Q&A is enough

15. Agent vs workflow — see §18.2.

16. Power BI Import vs DirectQuery vs Direct Lake — see §7.1.

17. Measure vs calculated column — see §7.2.

18. RLS vs OLS — see §7.6.

19. Managed vs unmanaged solution — see §9.2.

20. Managed identity vs service principal — see §11.3.

21. Synchronous vs asynchronous plug-in — see §3.2.

22. Plug-in vs Power Automate — see §3.3.

23. Virtual vs standard vs elastic tables — see §3.6.

24. Custom API vs custom action vs flow — see §3.9.

25. Delegated vs application permissions

Feature	Delegated	Application	When
Acts as	Signed-in user	The app itself	Delegated for user context
Scope	User's own access	Tenant-wide unless restricted	Application for unattended jobs
Risk	Bounded by user rights	Broad — needs access policies	Always scope application permissions

24. Scenario-Based Architect Questions (50)

Answer each with: assumptions → options → choice → trade-off → how I'd measure it. The one-line answers below are the spine of the answer, not the whole answer.

A. Power Platform architecture

S1. A Power App used by 3,000 field staff is unusable on 4G. — Reduce payload: delegable queries, on-demand loading, image compression, offline caching of reference data, and measure with Monitor on a throttled connection.

S2. The business wants one app for 12 countries with different processes. — One data model, configuration-driven variation (country config table), shared components; avoid 12 forks. Trade-off: configuration complexity vs maintainability; I'd cap variation and push outliers to separate flows.

S3. Leadership wants to replace 200 Excel trackers. — Rationalise first: cluster by process, kill duplicates, build 5–8 templated solutions, not 200 apps. Governance and a maker enablement track matter more than the build.

S4. A critical app is owned by a contractor who left. — Reassign ownership to a service principal/team, move to a managed solution with pipelines, document, and add the leaver process to governance.

S5. Two teams built conflicting solutions on the same tables. — Establish solution layering and ownership: one core data-model solution owned centrally, feature solutions layered on top, publisher/prefix standard, and a change-review forum.

S6. Dataverse capacity is nearly full. — Analyse by table: move attachments to SharePoint/Blob, purge audit history, archive closed records to Azure (Data Lake/SQL), review log storage. Then set alerts so it never surprises you again.

S7. Business demands a go-live in 3 weeks for a compliance deadline. — Scope to the compliant minimum, use out-of-the-box components, defer nice-to-haves, and be explicit about the technical debt register and when it's paid down.

S8. An app must work for 50,000 external users. — Power Pages with scoped table permissions, capacity sizing and load testing, caching, CDN, and an authentication decision (Entra External ID) made early.

B. Automation and RPA

S9. A flow processes 1M records nightly. — Dispatcher/queue/worker; Power Automate orchestrates, Durable Functions or Data Factory executes; checkpointing and idempotency.

S10. Design nightly unattended RPA for 100k transactions. — See §5.3: queue + horizontally scaled performers + retry + reconciliation + monitoring.

S11. A bot fails 15% of the time. — Classify failures first: if mostly business exceptions the process is wrong, not the bot; if system exceptions, fix waits/selectors/state reset. Report by exception type before changing anything.

S12. Finance wants RPA into SAP; SAP has an OData API. — Use the API. RPA on a system with an API is technical debt with a per-transaction cost.

S13. Migrate 40 bots from another RPA platform. — Inventory, rationalise, rebuild shared framework, migrate by value/complexity, parallel run, decommission.

S14. A flow must not process the same invoice twice, ever. — Business key + alternate key upsert + processed-ledger table + trigger conditions; assume at-least-once delivery.

S15. An approval flow is stuck because the approver left. — Delegation/escalation design: timeout with reassignment to a role/queue rather than a person, plus reminders and an admin reassignment path.

S16. Automation must run within a 4-hour window and currently takes 7. — Profile per-transaction time, remove UI where possible, parallelise performers, and pre-stage data; if still short, the answer is an API/database integration, not more bots.

C. Data and BI

S17. A Power BI report takes 40 seconds. — Performance Analyzer → DAX Studio → model fixes (star schema, cardinality) → DAX fixes → aggregations/incremental refresh.

S18. Finance disputes numbers between two reports. — One certified semantic model as the single source, definitions documented, both reports rebound to it; reconcile with a lineage walkthrough.

S19. Data volume exceeds import capability. — Aggregations + composite model, or DirectQuery/Direct Lake on Fabric with proper capacity sizing.

S20. Every department wants its own workspace and model. — Hub-and-spoke: certified shared models in a governed workspace, departmental reports in their own workspaces, with endorsement and lineage.

S21. Sensitive salary data in a shared report. — OLS to hide columns, RLS to filter rows, sensitivity labels, and check that workspace roles don't bypass RLS.

D. AI, Copilot and agents

S22. Design an AI customer support agent. — See §10.8: channels, identity, curated knowledge, deterministic high-risk topics, generative Q&A with citations, actions via flows, escalation, evaluation, ALM.

S23. Design a RAG solution over 200k enterprise documents. — Ingestion pipeline with change detection, heading-based chunking, hybrid index in Azure AI Search with ACL metadata, semantic reranking, citations, golden-set evaluation, freshness monitoring.

S24. Copilot answers are confidently wrong. — Inspect citations: it's usually retrieval or source hygiene. De-duplicate sources, re-chunk, hybrid + rerank, restrict to approved knowledge, add refusal path, then re-evaluate.

S25. Legal asks whether the AI can be trusted with customer data. — Answer with the data flow: what leaves the tenant, where it's processed, residency, retention, logging, redaction, and the human review point. Then propose the control set, not a reassurance.

S26. The business wants an agent to issue refunds automatically. — Agent proposes; a deterministic API executes with validation; below a threshold auto-approve, above it human approval; full audit; kill switch. State the fraud and error blast radius explicitly.

S27. AI spend tripled in a month. — Token telemetry by endpoint → find the cause (context bloat, retries, wrong model, runaway loops) → model routing, context trimming, caching, caps and budget alerts.

S28. Two teams are building competing agents. — Define an agent registry and platform standards: shared knowledge layer, shared tool catalogue with permission policy, evaluation requirement before production, and a review board.

S29. An agent needs data the user isn't allowed to see. — It doesn't get it. Security trimming at retrieval, per-user identity, and if the use case truly requires elevated access it becomes a reviewed, logged, deterministic service — not an agent capability.

S30. Prove ROI of an AI assistant to the CFO. — Baseline first: volume, handling time, cost per contact. Then measure containment/deflection, time saved, error rate, and cost per conversation, with a control group if possible.

E. Azure and integration

S31. Design a secure Power Platform + Azure architecture. — Entra identity everywhere, service principals/managed identity, APIM in front of Azure services, Key Vault for secrets, private networking where supported, DLP policies, environment separation, full telemetry.

S32. Dataverse must notify 6 downstream systems. — Publish once to Service Bus topic (via service endpoint); each system subscribes independently with its own retry and DLQ. Avoids 6 point-to-point integrations.

S33. A partner API is unreliable. — Queue the request, retry with exponential backoff and jitter, circuit breaker, dead-letter for manual replay, and an SLA conversation with the partner backed by your telemetry.

S34. The integration must be real-time and also survive outages. — Async messaging with durable queue; "real-time" becomes "low latency with guaranteed delivery". Get the business to state acceptable latency in seconds.

S35. Data must never leave the region. — Region-pinned services, data residency verified per service (including AI), private networking, and documented evidence for compliance. Verify AI model availability per region early — it constrains design.

S36. Design DR for the platform. — Get RPO/RTO from the business, then: Dataverse platform capabilities plus exports, geo-replicated stores, IaC to rebuild Azure components, documented runbook, and a tested failover — untested DR is a document, not a capability.

S37. An Azure Function is the bottleneck at peak. — Check scaling limits/plan, dependency latency, cold start, and downstream throttling; move to queue-based load levelling so peaks buffer instead of failing.

S38. Company mandates zero secrets in code. — Managed identity everywhere in Azure, workload identity federation for pipelines, Key Vault for the rest, and a scanning gate in CI to enforce it.

F. Governance, ALM, people

S39. Shadow IT: 400 flows in the default environment. — Inventory with CoE, classify by criticality, migrate business-critical into governed environments with ALM, apply DLP, and give makers a supported path so the behaviour doesn't recur.

S40. Production changes are being made directly in prod. — Lock down prod (no maker access), enforce managed solutions, pipelines with approvals, and provide a fast-track emergency-change process so the rule survives contact with reality.

S41. Design multi-environment ALM for 6 parallel projects. — Dev per project, shared Test, shared UAT, single Prod; core-model solution centrally owned; branch strategy mapped to environments; automated builds; solution layering rules documented.

S42. A release broke production. — Immediate: roll back to prior managed version or restore backup. Then: post-incident review, add the missing test to the gate, and ask why it wasn't caught — the fix is process, not blame.

S43. Auditors ask who changed a record and when. — Dataverse auditing scoped to the relevant tables/columns, retention configured, plus Purview logs for access; demonstrate with a query, not a promise.

S44. Licensing cost is out of control. — Map usage: per-app vs per-user, unused licences, API-heavy patterns, pay-as-you-go options, and redesign the top cost drivers. Present options with numbers, not a single recommendation.

S45. Business wants "AI everywhere" with no clear use case. — Run a value/feasibility screen: volume × handling time × error cost, data readiness, and risk. Pick two pilots with measurable baselines; publish results honestly, including failures.

S46. A citizen developer built something critical and it's failing. — Stabilise first, then formally adopt it: assess, re-platform into a managed solution with ALM, transfer ownership, and add it to the supported catalogue with a support tier.

S47. Security wants to block all custom connectors. — Negotiate with controls rather than a ban: allowlist reviewed connectors, require Entra auth and APIM, DLP classification, and a review process. A blanket ban produces workarounds.

S48. Sponsor asks for a 2-year platform roadmap. — Sequence by capability: foundation (environments, DLP, ALM, identity) → delivery (templates, CoE, enablement) → advanced (integration platform, AI/agents) → optimisation (cost, monitoring, retirement), each with measurable outcomes.

S49. Two systems both claim to be the master for customer data. — Define system of record per attribute, not per system; direction of sync; conflict rules; and a reconciliation report. Governance decision first, integration second.

S50. You inherit an undocumented estate. — Inventory (CoE/PowerShell/admin APIs) → classify by business criticality → identify single points of failure (personal connections, orphaned owners, no ALM) → stabilise the top 10 → then modernise. Communicate the risk register early.

25. Certification-Based Question Sets

Certifications are used by interviewers as a topic map, not a script. For each, the table gives the domains they mine, the traps, and the question they actually ask.

Power Platform

Cert	Domains interviewers mine	Common trap	Question they actually ask
PL-900	Platform components, Dataverse basics, AI Builder, Copilot Studio basics	Confusing Dataverse with SharePoint lists	"When would you not use Power Platform?"
PL-100	App design, UX, data modelling	Building UI before the data model	"How do you gather requirements for a canvas app?"
PL-200	Dataverse config, security roles, BPFs, flows	Thinking roles can subtract privileges	"Design security for a regional sales org"
PL-400	Plug-ins, custom APIs, PCF, Web API, ALM	Long-running work in sync plug-ins	"Plug-in or flow, and why?"
PL-500	Desktop flows, queues, machine groups, exception handling	No distinction between business and system exceptions	"Design an unattended solution at scale"
PL-600	Solution architecture, requirements, environment strategy, integration	Jumping to technology before requirements	"How do you run a solution-architecture engagement?"

Azure

Cert	Domains	Trap	Question
AZ-900	Core services, cloud models, cost	Reciting definitions with no trade-offs	"IaaS vs PaaS for this workload?"
AZ-104	Identity, storage, networking, monitoring	Confusing NSG with firewall/WAF roles	"Troubleshoot private endpoint connectivity"
AZ-204	App Service, Functions, storage, Key Vault, messaging	Ignoring idempotency and retries	"How do you handle at-least-once delivery?"
AZ-305	Architecture: identity, data, BC/DR, governance	Designing without RPO/RTO	"Design HA and DR for this solution"
AZ-400	CI/CD, IaC, release strategy, monitoring	Manual steps in a "pipeline"	"Describe your rollback strategy"

AI

Cert	Domains	Trap	Question
AI-900	AI workloads, responsible AI, service mapping	Vague responsible-AI answers	"Which Azure AI service for this problem?"
AI-102	Language, vision, document intelligence, search, OpenAI, containers	Treating RAG as a checkbox	"Design and evaluate a RAG solution"
AI Foundry / agent-focused topics	Agents, tools, evaluation, tracing, safety, deployment	No evaluation strategy	"How do you know the agent got better?"

Universal certification-to-interview translation: every exam objective becomes "when would you use it, what does it cost, how does it fail, and how would you know it failed?"

26. Top 100 Must-Know Questions

⭐⭐⭐⭐⭐ Critical · ⭐⭐⭐⭐ Important · ⭐⭐⭐ Useful

#	Question	Rating	Section
1	Canvas vs model-driven — how do you choose?	⭐⭐⭐⭐⭐	2.1
2	Explain delegation and its failure mode	⭐⭐⭐⭐⭐	2.2
3	How do you optimise a slow Power App?	⭐⭐⭐⭐⭐	2.3
4	Where should business logic live in Dataverse?	⭐⭐⭐⭐⭐	3.1
5	Sync vs async plug-ins	⭐⭐⭐⭐⭐	3.2
6	Plug-in vs Power Automate	⭐⭐⭐⭐⭐	3.3
7	Dataverse vs SharePoint vs SQL	⭐⭐⭐⭐⭐	3.4
8	Explain the Dataverse security model	⭐⭐⭐⭐⭐	3.5
9	How do you handle Dataverse 429s?	⭐⭐⭐⭐⭐	3.7
10	What makes a flow enterprise-grade?	⭐⭐⭐⭐⭐	4.1
11	Flow error handling pattern	⭐⭐⭐⭐⭐	4.2
12	Design a flow for 1M records	⭐⭐⭐⭐⭐	4.3
13	How do you prevent duplicate processing?	⭐⭐⭐⭐⭐	4.4
14	Handling throttling and API limits	⭐⭐⭐⭐⭐	4.5
15	Power Automate vs Logic Apps	⭐⭐⭐⭐	4.6
16	Service principal vs service account	⭐⭐⭐⭐⭐	4.8
17	Dispatcher/performer architecture	⭐⭐⭐⭐⭐	5.2
18	Design 100k-transaction nightly RPA	⭐⭐⭐⭐⭐	5.3
19	Business vs system exception	⭐⭐⭐⭐⭐	5.4
20	Why does a bot fail randomly?	⭐⭐⭐⭐⭐	5.5
21	Credential management in RPA	⭐⭐⭐⭐⭐	5.7
22	Attended vs unattended vs hosted	⭐⭐⭐⭐	5.8
23	Migrating from another RPA platform	⭐⭐⭐⭐	5.9
24	When is RPA the wrong answer?	⭐⭐⭐⭐⭐	5.1
25	Import vs DirectQuery vs Direct Lake	⭐⭐⭐⭐⭐	7.1
26	Measure vs calculated column	⭐⭐⭐⭐⭐	7.2
27	Filter context, row context, context transition	⭐⭐⭐⭐⭐	7.3
28	Why star schema?	⭐⭐⭐⭐⭐	7.4
29	Optimise a slow Power BI report	⭐⭐⭐⭐⭐	7.5
30	RLS vs OLS, and dynamic RLS	⭐⭐⭐⭐⭐	7.6
31	Incremental refresh and query folding	⭐⭐⭐⭐	7.7
32	Power Query vs DAX	⭐⭐⭐⭐	7.8
33	Power BI ALM / deployment pipelines	⭐⭐⭐⭐	7.9
34	Gateway HA design	⭐⭐⭐	7.10
35	Design enterprise governance	⭐⭐⭐⭐⭐	8.1
36	What does DLP actually control?	⭐⭐⭐⭐⭐	8.2
37	Handling a maker who leaves	⭐⭐⭐⭐	8.3
38	Capacity and licensing drivers	⭐⭐⭐⭐	8.4
39	Describe your ALM pipeline	⭐⭐⭐⭐⭐	9.1
40	Managed vs unmanaged solutions	⭐⭐⭐⭐⭐	9.2
41	Environment variables and connection references	⭐⭐⭐⭐⭐	9.3
42	Rollback strategy	⭐⭐⭐⭐⭐	9.4
43	Source control for Power Platform	⭐⭐⭐⭐	9.5
44	What is Copilot Studio and where does it fit?	⭐⭐⭐⭐⭐	10.1
45	Copilot Studio vs AI Foundry vs Azure OpenAI	⭐⭐⭐⭐⭐	10.2
46	Topic-based vs generative orchestration	⭐⭐⭐⭐⭐	10.3
47	Preventing hallucinations in an enterprise agent	⭐⭐⭐⭐⭐	10.4
48	Securing an enterprise copilot	⭐⭐⭐⭐⭐	10.5
49	Connecting an agent to Dataverse and flows	⭐⭐⭐⭐	10.6
50	Copilot Studio ALM and analytics	⭐⭐⭐⭐	10.7
51	Design an enterprise support agent	⭐⭐⭐⭐⭐	10.8
52	App Service vs Functions vs Container Apps vs AKS	⭐⭐⭐⭐	11.1
53	Service Bus vs Event Grid vs Event Hubs	⭐⭐⭐⭐⭐	11.2
54	Managed identity vs service principal	⭐⭐⭐⭐⭐	11.3
55	Securing Power Platform ↔ Azure traffic	⭐⭐⭐⭐⭐	11.4
56	APIM vs App Gateway vs Front Door	⭐⭐⭐⭐	11.5
57	Storage redundancy options	⭐⭐⭐	11.6
58	Design an HA Power Platform + Azure solution	⭐⭐⭐⭐⭐	11.7
59	Durable Functions use cases	⭐⭐⭐⭐	11.8
60	Choosing an integration pattern	⭐⭐⭐⭐⭐	12.1
61	Dataverse → Service Bus integration	⭐⭐⭐⭐	12.2
62	Power Automate vs Azure Functions	⭐⭐⭐⭐	12.3
63	Designing idempotent integrations	⭐⭐⭐⭐⭐	12.4
64	Zero Trust in this stack	⭐⭐⭐⭐	13.1
65	OAuth 2.0 vs OIDC; delegated vs application	⭐⭐⭐⭐⭐	13.2
66	Prompt injection and AI data leakage defence	⭐⭐⭐⭐⭐	13.3
67	Handling sensitive data in AI solutions	⭐⭐⭐⭐⭐	13.4
68	Mapping the Azure AI portfolio	⭐⭐⭐⭐	14.1
69	Design a document-processing solution	⭐⭐⭐⭐⭐	14.2
70	Embeddings, vector, hybrid, semantic search	⭐⭐⭐⭐⭐	14.3
71	What is Azure AI Foundry?	⭐⭐⭐⭐⭐	15.1
72	Foundry vs calling Azure OpenAI directly	⭐⭐⭐⭐	15.2
73	How do you evaluate an AI application?	⭐⭐⭐⭐⭐	15.3
74	How do you monitor AI in production?	⭐⭐⭐⭐⭐	15.4
75	Securing an enterprise AI application	⭐⭐⭐⭐⭐	15.5
76	RAG vs fine-tuning	⭐⭐⭐⭐⭐	16.1
77	Reducing hallucinations	⭐⭐⭐⭐⭐	16.2
78	Reducing token cost and latency	⭐⭐⭐⭐⭐	16.3
79	How do you select a model?	⭐⭐⭐⭐	16.4
80	Temperature, top-p, context window, tokens	⭐⭐⭐	16.5
81	Describe a production RAG architecture	⭐⭐⭐⭐⭐	17.1
82	Fixing irrelevant RAG retrieval	⭐⭐⭐⭐⭐	17.2
83	Permission-aware RAG	⭐⭐⭐⭐⭐	17.3
84	Agent vs chatbot vs workflow	⭐⭐⭐⭐⭐	18.1
85	When to use an agent vs deterministic workflow	⭐⭐⭐⭐⭐	18.2
86	Design an email-processing enterprise agent	⭐⭐⭐⭐⭐	18.3
87	Preventing unauthorised agent actions	⭐⭐⭐⭐⭐	18.4
88	When are multi-agent systems justified?	⭐⭐⭐⭐	18.5
89	Agent memory design	⭐⭐⭐⭐	18.6
90	Evaluating and observing agents	⭐⭐⭐⭐⭐	18.7
91	Integrating Power Platform with Graph	⭐⭐⭐⭐⭐	19.1
92	Delta query vs notifications vs polling	⭐⭐⭐⭐	19.2
93	Delegated vs application permissions	⭐⭐⭐⭐⭐	19.3
94	Virtual vs standard vs elastic tables	⭐⭐⭐⭐	3.6
95	Custom API vs custom action vs flow	⭐⭐⭐⭐	3.9
96	Migrating 5M records into Dataverse	⭐⭐⭐⭐	3.10
97	Why alternate keys matter	⭐⭐⭐⭐	3.11
98	Power Pages security model	⭐⭐⭐⭐	6.1
99	Where does Power Platform stop and Azure start?	⭐⭐⭐⭐⭐	1.1
100	How do you prove ROI of a platform or AI investment?	⭐⭐⭐⭐⭐	24 (S30)

27. 100 Rapid-Fire Questions

Say these out loud. One to two sentences each, no hedging.

#	Q	A
1	What is Dataverse?	Microsoft's cloud business data platform — relational storage with security, logic, auditing and APIs.
2	What is delegation?	Pushing query processing to the data source instead of evaluating locally.
3	Default delegation row limit?	500 by default, configurable up to 2000.
4	Power Fx?	The low-code, Excel-like expression language of Power Platform.
5	Collection vs variable?	Collection is an in-memory table; variable holds a single value or record.
6	Global vs context variable?	`Set()` is app-wide; `UpdateContext()` is screen-scoped.
7	What is a component library?	A shared, versioned set of reusable canvas components.
8	What is PCF?	Power Apps Component Framework — code components in TypeScript for custom controls.
9	Business rule?	Declarative field-level logic that runs on the form and optionally server-side.
10	Business process flow?	A guided, stage-based process across records in model-driven apps.
11	Calculated vs rollup column?	Calculated derives from fields on demand; rollup aggregates related records on a schedule.
12	Alternate key?	A business-unique key enabling upsert and integration without GUIDs.
13	Polymorphic lookup?	A lookup that can reference more than one table type (e.g. Customer).
14	Owner team vs access team?	Owner team can own records; access team grants ad-hoc access without ownership.
15	Field-level security?	Restricts specific sensitive columns via field security profiles.
16	Hierarchy security?	Grants managers access to their reports' records via manager or position hierarchy.
17	Plug-in pipeline stages?	Pre-validation, pre-operation, post-operation.
18	Plug-in timeout?	Two minutes.
19	Virtual table?	A Dataverse table backed by external data, not stored in Dataverse.
20	Elastic table?	A Dataverse table for very high-volume, semi-structured workloads.
21	Custom API?	A solution-aware, code-backed server-side operation with a defined contract.
22	Dataverse Web API?	The OData v4 REST API for Dataverse.
23	ExecuteMultiple?	Batching multiple requests into one round trip.
24	Service protection limits?	Per-user, per-server request/time/concurrency caps that return 429 with Retry-After.
25	What is a solution?	The ALM container for Power Platform components.
26	Managed vs unmanaged?	Unmanaged is editable source (dev); managed is the deployment artifact (test/prod).
27	Environment variable?	Externalised configuration so one artifact works in every environment.
28	Connection reference?	Externalised connection binding so flows aren't tied to a person's connection.
29	PAC CLI?	Power Platform CLI for solution, environment and pipeline automation.
30	Solution checker?	Static analysis that flags performance, security and maintainability issues.
31	DLP policy?	Classifies connectors into business/non-business/blocked to prevent data mixing.
32	Managed environment?	Premium governance features — sharing limits, digests, solution checker enforcement.
33	CoE Starter Kit?	Microsoft's toolkit for tenant inventory, governance and adoption reporting.
34	Trigger condition?	An expression that stops a flow from starting unless it's true.
35	Child flow?	A reusable solution-aware flow called by a parent flow.
36	Scope in a flow?	A grouping of actions used for Try/Catch/Finally patterns.
37	`result()` function?	Returns detailed status/outputs for actions in a scope — used in Catch blocks.
38	Concurrency control?	Setting parallel iterations in apply-to-each or limiting parallel runs.
39	Pagination in flows?	Retrieving all pages of a large result set instead of the first page.
40	Secure inputs/outputs?	Masks values in run history for sensitive actions.
41	Idempotency?	Repeating an operation produces the same result — makes retries safe.
42	Exponential backoff?	Increasing wait between retries, ideally with jitter, to relieve a throttled service.
43	429?	Too Many Requests — throttling; honour Retry-After.
44	Dispatcher?	Reads the work source and writes transaction items to a queue.
45	Performer?	Processes one queue item at a time and records the outcome.
46	Work queue?	Durable list of transaction items with status, enabling retry, parallelism and audit.
47	Business exception?	Data or rule problem — don't retry, route to a human.
48	System exception?	Environmental failure — retry, then escalate.
49	Attended automation?	Runs on a user's machine with them present.
50	Unattended automation?	Runs without a signed-in user, typically scheduled and scaled.
51	Machine group?	A pool of machines that share desktop-flow workload.
52	Why avoid fixed waits in PAD?	They're either too short (flaky) or too long (slow) — use dynamic waits.
53	Semantic model?	The Power BI data model — tables, relationships, measures (formerly "dataset").
54	Import mode?	Data loaded into VertiPaq memory; fastest, needs refresh.
55	DirectQuery?	Queries sent to the source at report time; fresh but slower.
56	Direct Lake?	Reads Delta tables in OneLake directly — import-like speed without refresh.
57	Star schema?	Central fact table with surrounding dimensions; the model shape DAX expects.
58	Measure vs column?	Measure computes at query time in filter context; column stores at refresh in row context.
59	Context transition?	`CALCULATE` converting row context into filter context.
60	`CALCULATE`?	The only DAX function that modifies filter context.
61	`DIVIDE` vs `/`?	`DIVIDE` handles divide-by-zero safely.
62	RLS?	Row-level security filtering rows per role via a DAX predicate.
63	OLS?	Object-level security hiding tables or columns from a role.
64	Query folding?	Power Query translating steps into a native source query.
65	Incremental refresh?	Refreshing only recent partitions using RangeStart/RangeEnd.
66	Aggregations?	Pre-summarised tables that satisfy queries without hitting detail rows.
67	Deployment pipeline?	Dev→Test→Prod promotion for Power BI/Fabric content.
68	Copilot Studio?	Low-code platform for building governed conversational agents.
69	Topic?	An authored dialog triggered by phrases or events.
70	Generative answers?	Model-generated responses grounded in configured knowledge sources.
71	Generative orchestration?	The model choosing which topics, knowledge and actions to use.
72	Grounding?	Constraining responses to retrieved, authoritative content.
73	Action in Copilot Studio?	A connector or flow the agent can call to do something.
74	Azure AI Foundry?	Azure's platform for building, evaluating, deploying and monitoring AI apps and agents.
75	Azure AI Search?	The retrieval service — keyword, vector, hybrid and semantic ranking.
76	Document Intelligence?	Extracts structured fields from forms, invoices and documents.
77	Content Safety?	Filters harmful content and detects jailbreak attempts.
78	Token?	The unit models read/generate — roughly ¾ of an English word.
79	Context window?	Max tokens of input plus output the model can consider at once.
80	Temperature?	Sampling randomness — low for factual, higher for creative.
81	Top-p?	Nucleus sampling from the smallest token set exceeding cumulative probability p.
82	System prompt?	Standing instructions defining role, constraints and output format.
83	Few-shot prompting?	Including examples in the prompt to show the desired pattern.
84	Embedding?	A vector representation of meaning used for similarity search.
85	Vector search?	Nearest-neighbour retrieval over embeddings.
86	Hybrid search?	Combining keyword and vector retrieval, then fusing results.
87	Semantic reranker?	A model that re-orders top results for relevance.
88	RAG?	Retrieve relevant content, then generate an answer grounded in it.
89	Fine-tuning?	Training a model on examples to change behaviour, style or format.
90	Hallucination?	Fluent output not supported by the source or reality.
91	Groundedness?	The degree to which an answer is supported by retrieved context.
92	Golden dataset?	A curated evaluation set of inputs with expected outputs.
93	LLM-as-judge?	Using a model to score outputs against criteria, validated against human labels.
94	AI agent?	A goal-directed system that plans, calls tools and adapts to results.
95	Function/tool calling?	The model requesting a defined function with structured arguments.
96	Human-in-the-loop?	A required human decision point before or after a high-impact action.
97	Prompt injection?	Untrusted content manipulating model behaviour or tool use.
98	Managed identity?	An Azure-managed service principal with no secret to store or rotate.
99	Delegated vs application permission?	Acts as the user vs acts as the app; the latter is tenant-wide unless scoped.
100	Private endpoint?	A private IP in your VNet for a PaaS service, removing public exposure.

28. Mock Interview

28.1 How to run this

Paste the prompt below into a new chat, then answer one question at a time. Answers are deliberately not provided in this section — look them up in §1–§20 only after you've attempted them.

Mock interview prompt
You are interviewing me for a Senior Power Platform / AI Solution Architect role. Use the round list I give you. Ask one question at a time and wait for my answer. After each answer:
Rate it 1–10.
State what I got right.
State what I missed.
Give the ideal short interview answer (under 120 words).
List the keywords I should have said.
Ask the next question.
Do not reveal answers before I respond. Increase difficulty if I score 8+, and probe follow-ups if I score below 6. Start with Round 1, Question 1.

Self-scoring rubric:

Score	Meaning
9–10	Correct, concise, with a trade-off and an example
7–8	Correct with keywords, missing trade-off or evidence
5–6	Broadly right, vague or missing the failure mode
3–4	Partially right, wrong terminology
1–2	Incorrect or invented a feature

Round 1 — Power Platform fundamentals (20)

What problem does Power Platform solve that Azure doesn't? 2. Canvas vs model-driven. 3. What is Dataverse? 4. Dataverse vs SharePoint. 5. What is a solution? 6. Managed vs unmanaged. 7. What is delegation? 8. Delegation limits and consequences. 9. Global vs context variable. 10. When do you use a collection? 11. Component library vs PCF. 12. Business rule vs Power Fx. 13. What is a BPF? 14. Environment types and purposes. 15. Connection reference purpose. 16. Environment variable purpose. 17. Who should own the default environment? 18. What is DLP? 19. Power Apps vs Power Pages. 20. Name three Power Platform cost drivers.

Round 2 — Power Platform advanced (20)

Where should logic live in Dataverse? 2. Sync vs async plug-in. 3. Plug-in vs flow. 4. Custom API vs custom action. 5. Explain the Dataverse security model. 6. Owner vs access teams. 7. Field-level security use case. 8. Virtual vs elastic tables. 9. How do you migrate 5M records? 10. Alternate keys and idempotency. 11. Handling 429s. 12. Optimising a slow Dataverse query. 13. Optimising a 25-second app load. 14. Handling 2M rows in a canvas app. 15. Offline strategy. 16. Error handling in canvas apps. 17. Auditing strategy and cost. 18. Rollup vs calculated column limits. 19. Designing security for a regional org. 20. Detecting and preventing plug-in/flow loops.

Round 3 — Power Automate Desktop / RPA (15)

When is RPA the wrong choice? 2. Dispatcher/performer. 3. Design 100k nightly transactions. 4. Business vs system exception. 5. Retry strategy and cap. 6. Diagnosing a randomly failing bot. 7. Making selectors robust. 8. Credential management. 9. Attended vs unattended vs hosted. 10. Queue design and item states. 11. Logging and auditability. 12. Preventing duplicate transactions. 13. Handling a mid-process failure. 14. Migrating from another RPA tool. 15. Speeding up a slow bot.

Round 4 — Power BI (15)

Import vs DirectQuery vs Direct Lake. 2. Measure vs calculated column. 3. Filter vs row context. 4. Context transition. 5. Why star schema. 6. Optimising a slow report. 7. Diagnosing formula vs storage engine time. 8. RLS vs OLS. 9. Dynamic RLS implementation. 10. Incremental refresh and folding. 11. Power Query vs DAX. 12. Aggregations and composite models. 13. Deployment pipelines. 14. Gateway HA. 15. Write a YoY measure and explain it.

Round 5 — Copilot Studio (15)

What is Copilot Studio? 2. Copilot Studio vs AI Foundry. 3. Topics vs generative orchestration. 4. Knowledge sources and grounding. 5. Preventing hallucinations. 6. Security trimming and identity. 7. Calling Power Automate as an action. 8. Dataverse as knowledge vs as action target. 9. ALM for agents. 10. Which analytics matter. 11. Escalation to human design. 12. Handling PII in conversations. 13. Multi-channel deployment considerations. 14. Testing and evaluating an agent. 15. Design an enterprise support agent end to end.

Round 6 — Azure (20)

App Service vs Functions vs Container Apps vs AKS. 2. Service Bus vs Event Grid vs Event Hubs. 3. Managed identity vs service principal. 4. APIM vs App Gateway vs Front Door. 5. Storage redundancy options. 6. Private endpoint vs service endpoint. 7. Key Vault access patterns. 8. RBAC scope design. 9. Durable Functions use cases. 10. Queue-based load levelling. 11. Circuit breaker and retry. 12. Idempotent consumers. 13. Dead-letter handling. 14. Zone vs region resilience. 15. Designing for RPO/RTO. 16. Cost optimisation levers. 17. Monitoring and alerting design. 18. IaC and environment parity. 19. Securing Power Platform ↔ Azure. 20. Design an HA architecture for this stack.

Round 7 — Azure AI / AI Foundry (20)

Map the Azure AI services to problems. 2. What is AI Foundry? 3. Foundry vs direct Azure OpenAI. 4. Model selection criteria. 5. Embeddings explained. 6. Vector vs keyword vs hybrid. 7. Semantic reranking. 8. Chunking strategy. 9. Designing a RAG pipeline. 10. Permission-aware retrieval. 11. Evaluating a RAG app. 12. Groundedness vs relevance. 13. Golden datasets and regression testing. 14. Tracing and observability. 15. Content safety configuration. 16. Reducing hallucinations. 17. Reducing cost and latency. 18. Document processing architecture. 19. Data residency and privacy. 20. Securing an AI application.

Round 8 — Agentic AI (15)

Agent vs chatbot vs workflow. 2. When to choose an agent. 3. Function/tool calling. 4. Tool allowlists and permissions. 5. Planning and termination conditions. 6. Memory types and retention. 7. Human-in-the-loop design. 8. Preventing unauthorised actions. 9. Prompt injection defence. 10. Multi-agent justification. 11. Agent observability. 12. Trajectory evaluation. 13. Cost control for agents. 14. Failure and escalation paths. 15. Design the email-processing agent.

Round 9 — Architecture (20)

How do you run a solution architecture engagement? 2. Gathering non-functional requirements. 3. Choosing an integration pattern. 4. System of record decisions. 5. Designing for idempotency. 6. Designing for observability. 7. HA vs DR. 8. Environment strategy. 9. ALM across six projects. 10. Rollback strategy. 11. Build vs buy vs configure. 12. Technical debt management. 13. Cost as a design constraint. 14. Security by design. 15. Handling conflicting stakeholder requirements. 16. Documenting architecture decisions (ADRs). 17. Migration strategy and parallel run. 18. Capacity planning. 19. Performance testing approach. 20. Designing a two-year platform roadmap.

Round 10 — Real-world scenarios (20)

Pick any 20 from §24 and answer them cold, timed at 3 minutes each.

Appendix A — Cheat Sheets

A.1 Expressions you should be able to write from memory

Power Fx

// Delegable filter with search
Filter(Accounts, StartsWith(Name, txtSearch.Text))

// Safe patch with error handling
IfError(
    Patch(Cases, Defaults(Cases), {Title: txtTitle.Text}),
    Notify("Save failed: " & FirstError.Message, NotificationType.Error)
)

// Concurrent load
Concurrent(
    ClearCollect(colTypes, Types),
    ClearCollect(colStatus, Statuses)
)

Power Automate expressions

// Null-safe access
coalesce(triggerOutputs()?['body/email'], 'unknown')

// Catch-block detail
result('Try_Scope')

// Correlation ID
workflow().run.name

// Date filter for OData
formatDateTime(addDays(utcNow(), -1), 'yyyy-MM-ddTHH:mm:ssZ')

DAX

Total Sales = SUMX ( Sales, Sales[Qty] * Sales[Price] )

Sales YTD = TOTALYTD ( [Total Sales], 'Date'[Date] )

Pct of Total =
DIVIDE ( [Total Sales], CALCULATE ( [Total Sales], ALLSELECTED ( Product ) ) )

OData / Graph

/api/data/v9.2/accounts?$select=name,revenue&$filter=revenue gt 100000&$top=50
https://graph.microsoft.com/v1.0/users?$select=displayName,mail&$top=999

A.2 Numbers to know (verify current values before interview)

Item	Order of magnitude	Design implication
Canvas delegation row limit	500 default / 2000 max	Never rely on client-side filtering
Plug-in execution timeout	2 minutes	No long-running or external calls in sync plug-ins
Flow HTTP action sync timeout	~120 seconds	Use async 202/polling pattern
Dataverse service protection	Thousands of requests per 5-min sliding window per user/server	Batch and back off
Apply-to-each item and concurrency caps	Thousands of items, low tens of parallel branches	Queue and fan out instead
SharePoint list view threshold	5,000	Index columns, filter server-side
Model context window	Tens to hundreds of thousands of tokens by model	Trim context; don't dump whole documents

A.3 Architecture decision record template

Field	Content
Decision	What was decided
Context	Requirement and constraints
Options	Considered alternatives
Rationale	Why this one
Trade-offs	What we accept losing
Consequences	Operational/cost impact
Review date	When to revisit

Mentioning ADRs unprompted in an architecture interview is a strong signal.

A.4 Questions to ask your interviewer

What does the platform estate look like today — environments, ALM maturity, CoE?
Where is the biggest current pain: delivery speed, governance, cost, or reliability?
How are AI initiatives governed — who approves an agent going to production?
Is the architect role advisory or accountable for delivery?
How do fusion teams work here — who owns what between makers and engineering?
What does success look like for this role in six months?

A.5 Final-day checklist

Can I give the 5-part answer for my top 10 questions without notes?
Can I draw the dispatcher/performer diagram in 60 seconds?
Can I draw the RAG pipeline in 60 seconds?
Can I state one trade-off for every technology I claim to know?
Do I have three project stories with numbers in them?
Have I re-verified the volatile limits in §0.6?
Do I have a prepared, honest answer for "what don't you know?"

==========================================================================

Power Platform · PAD/RPA · Power BI · Copilot Studio · Azure · Azure AI · AI Foundry · GenAI · Agentic AI

Verify volatile numbers (service limits, licensing, SKUs) on Microsoft Learn before the interview.