Topic information and question formats
Nine areas from the skills outline that are easy to under-prepare — either because Microsoft has recently renamed the product surface, because two similarly named services get confused, or because the correct answer is more nuanced than it first appears. Everything here is drawn from the published Learn path, the skills outline, and current Microsoft product documentation.
- Single-answer questions usually test a decision rule — configure vs. extend vs. build, managed vs. unmanaged, tool vs. knowledge source, autonomous vs. human-in-the-loop.
- Multiple-response questions usually test a set — the components of a design, the steps of a deployment, the metrics on a dashboard, the settings an admin must enable.
- The skills outline is written in terms of product surfaces, so knowing where a setting lives (the Copilot Studio Monitor page, Power Platform admin center, Application Insights, Azure Key Vault) matters as much as knowing what it does.
- Scenario stems are long but the last sentence carries the requirement. Read it first, then scan the stem only for the constraint it names — cost, latency, compliance, region, or existing licences.
- Product naming has shifted recently (Copilot Credits not messages, Monitor not Analytics, customer service representative not agent). Learn both the old and the current term; documentation and any current assessment will use the current one.
- Check the official skills measured document before you sit — it is versioned, and Microsoft publishes the change log when it is updated.
Answering multiple-response questions
This is the format candidates practise least and lose most on. There is normally no partial credit, so a near-miss scores the same as a blank.
- Count the answers you are asked for. "Select two" and "select all that apply" behave differently — the second gives no clue how many are correct.
- Assume no partial credit. Three right out of four scores zero, so an extra plausible-but-wrong tick is as costly as a missing one.
- Test each option independently against the stem, as a true/false question in its own right. Do not compare options with each other.
- Reject options that are true in general but not required by the scenario. This is the most common multiple-response trap: a correct statement that does not answer the question asked.
- Watch for two options that say the same thing differently. If both cannot be wrong and both cannot be right, one of them is worded to fail on a detail — usually a wrong product, wrong environment, or wrong lifecycle stage.
- Prefer the complete, governed set. If one option covers monitoring, one covers alerting and one covers dashboards, the intended answer is often all three, not the single most powerful one.
- On "which components would you include" questions, include the security and lifecycle components. It is easy to remember the agent and the data source and forget the connection reference, environment variable, or DLP policy.
The nine topics
Each links to the study page that covers it and to the official Microsoft documentation, so you can verify anything that looks out of date.
Azure Monitor, Application Insights and Log Analytics
Three services with overlapping names that candidates routinely mix up. The useful knowledge is which service does what, and how telemetry gets out of Copilot Studio in the first place — not how to write a query.
What you need to know
- Azure Monitor is the umbrella observability platform (metrics, logs, traces, alerts, dashboards, workbooks). Application Insights is its application performance monitoring capability. A Log Analytics workspace is the underlying data store for log and trace tables. Queries are written in Kusto Query Language (KQL).
- Agent-level telemetry: in Copilot Studio,
Settings → Advanced → Application Insights, paste the Application Insights connection string. Optional toggles log messages and events, conversation details, sensitive activity properties and node execution. Test-pane traffic is included unless you filter ondesignMode. - Environment-level export (preview): in the Power Platform admin center,
Manage → Data export → App Insights → New data export, for a Managed Environment. Choose Copilot Studio, Power Automate or Dataverse diagnostics and a target Application Insights resource. First delivery can take up to 24 hours. - Environment-level Copilot Studio export writes OpenTelemetry-aligned spans —
InvokeAgent,ExecuteTool,OutputMessages— mostly into thedependenciestable.operation_Idcorrelates one turn;gen_ai.conversation.idjoins turns into a conversation. - The Power Platform admin center Monitor area gives operational health, logs, alerts and recommendations across apps, flows and agents. Copilot Studio agents there are public preview; recommendations need Managed Environments; the data is aggregated, not real time.
- For performance specifically, watch: request and run volume, throughput, p50/p95/p99 latency, tool and dependency duration, success and error rate, exceptions, timeouts, HTTP 429 throttling, queue backlog, token use and Copilot Credit consumption.
- Act on it with KQL log alerts, Azure Monitor alert rules and action groups, Application Insights workbooks and dashboards. Copilot Studio ships a Copilot Studio Dashboard workbook covering conversations, latency, exceptions, tool usage and topic analytics.
Applying it to a scenario
- "Which service stores the logs?" → the Log Analytics workspace. "Which service do you configure in the agent?" → Application Insights (via its connection string). "Which platform raises the alert?" → Azure Monitor.
- If a scenario mentions a Managed Environment and tenant-wide reporting, the fit is the admin-center data export, not per-agent configuration.
- If it mentions diagnosing one slow tool call, the fit is Application Insights dependencies / the activity map — not the Copilot Studio Monitor page.
The Copilot Studio analytics surface — testing and evaluation
Microsoft renamed and restructured this surface recently, so a lot of older study material is now actively wrong. Worth relearning from current documentation rather than memory.
What you need to know
- The page is now documented as Monitor (some UI still says Analytics). Its areas are Summary, Overview, Savings, Custom metrics, Effectiveness and Use.
- Current conversational metrics: Average DAU/MAU; conversation outcomes of
Resolved,Escalated,AbandonedandUnengaged(with resolved split into confirmed and implied); reactions (thumbs up/down and comments); Satisfaction score as a CSAT average out of 5; Sentiment (preview); connected/child agent calls, success rate and status; answer rate and answer quality (Good/Poor); knowledge source use and errors. - Autonomous agents are measured differently: run outcomes, run duration, trigger use, tool use and knowledge source error rate — not conversational resolution.
- The Savings calculator estimates time or money saved per run or per tool against a comparison method. This is the in-product ROI instrument.
- Test your agent pane: interactive conversation, node highlighting, cross-topic tracking, variable inspection, connection management and downloadable diagnostic snapshots. Generative orchestration adds a real-time activity map showing the plan, inputs, outputs, errors and execution time.
- Agent evaluations are GA. A test set holds up to 100 cases, authored manually, captured from test chat, drawn from production themes, generated from knowledge and topics, or imported from CSV. Single-response and multi-turn evaluations are both supported.
- Graders: General quality (relevance, groundedness, completeness, abstention), Compare meaning, Tool use, Keyword match, Text similarity, Exact match, Custom. Evaluations can compare agent versions and be automated via Power Automate or the Power Platform REST API.
Applying it to a scenario
- Pre-deployment quality gate → agent evaluations against a test set. Post-deployment quality signal → Monitor outcomes, reactions and answer quality.
- "High engagement, low resolution" → a knowledge gap or unclear instructions, diagnosed from unresolved outcomes and transcripts.
- Proving savings to a sponsor → the Savings calculator plus adoption data, not raw session counts.
Connections and connection references after a production deployment
A precise, factual distinction that is easy to get half-right. "Does this solution have connections, and what has to be reconfigured in production?" is a genuine architecture question, and the answer is more nuanced than most people expect.
What you need to know
- A connection stores the authentication credentials for a connector. It is environment-specific and is *not* a solution component.
- A connection reference *is* a solution component. It is the indirection layer that apps, flows and agents point at, so the artefact does not hard-code a credential.
- On export and import, the connection reference metadata travels with the solution; the underlying connection does not. Every connection reference must be bound to a valid connection that exists in the target environment.
- That binding can be supplied three ways: chosen interactively during import, supplied by a Power Platform pipeline stage, or prepopulated from a deployment settings JSON file (
ConnectionId/ConnectorIdvalues) in an automated pipeline. - So the precise position is: yes, connections must be configured for production — but not necessarily manually after the fact. A properly automated deployment binds them during import, and an existing valid connection in the target can be reused.
- Environment variables are a different mechanism: they parameterise configuration (URLs, IDs, JSON, data source parameters), not connector authentication. A solution normally needs both.
- Secrets never go in the solution or the settings file. Keep them in Azure Key Vault and use a secret-type environment variable that stores the vault and secret reference only.
Applying it to a scenario
- "What must you configure in the target environment?" → connection references bound to connections, environment variable values, and security roles.
- "How do you avoid manual steps on every deployment?" → a deployment settings file with pipelines or Azure DevOps / GitHub Actions.
- "Where does the API key go?" → Azure Key Vault, referenced by an environment variable.
ALM — managed solutions in production
The companion topic to connection references, and the place where "what would you actually do" and "what is technically possible" diverge most sharply.
What you need to know
- Unmanaged is the development and source-control form. Managed is the build artefact you ship to test, UAT and production. The answer to "managed in production?" is yes.
- Inside a managed solution components cannot be edited directly, managed solutions cannot be exported, and uninstalling one removes its customisations — which is what makes clean rollback possible.
- Managed is not absolute immutability: editing a managed component through an unmanaged solution creates an unmanaged layer above it, which then shadows future updates. This is the classic production-drift failure.
- Managed properties let the publisher restrict what downstream customisers may change.
- Power Platform pipelines give in-product governed deployment with sequential stages, approvals, pre-validation and target configuration — and they deploy connections, connection references and environment variables alongside the solution.
- Azure DevOps Power Platform Build Tools (v2 is PAC CLI based) and GitHub Actions for Power Platform cover source control, export/unpack/build/import, solution checker and environment provisioning for a fuller CI/CD pipeline.
Applying it to a scenario
- Small team, wants governance without building a pipeline → Power Platform pipelines.
- Enterprise with existing engineering practice and source control → Azure DevOps or GitHub Actions with the build tools.
- "A maker fixed a bug directly in production" → an unmanaged layer was created; remove it and redeploy from source.
Dynamics 365 design components — Field Service and Customer Service
Choosing the components of a Dynamics 365 design depends on knowing the real, current feature names — and this area has had a lot of renaming and several retirements, so half-remembered names will let you down.
What you need to know
- Field Service Copilot covers: natural-language questions in the web app via the Copilot side pane; work order and booking summaries; AI-powered work order update on mobile (preview); inspection template creation; form fill assistance; AI filtering and charting of views; row summaries; timeline highlights; and the agent feed (preview).
- Field Service side pane requires at least the Field Service – Dispatcher or Field Service – Resource role and is on by default unless disabled. Work order summaries need a paid environment — trials are not supported — and admins can replace the default summary with custom configurations.
- The named scheduling agent is the Scheduling Operations Agent. There is no current "Work Order Agent" in the Field Service Copilot overview.
- Retired — no longer current capabilities: the Field Service Outlook add-in, Field Service Teams app, Viva Connections and Planner integrations became unsupported after 30 October 2025, and the Field Service plugin for Copilot in Teams was removed in January 2025. Creating work orders from Outlook email via the add-in is therefore not a current option.
- Customer Service representative-facing Copilot: the help pane's Ask a question, Write an email and Draft a response, plus optional immersive Copilot (preview), translation, suggested prompts and enhanced case analysis. Case summaries draw on case and customer fields, emails, notes and prior conversation summaries; conversation summaries can fire on join, on end, or on demand.
- Named Customer Service / Contact Center agents: Customer Support Agent (representative-facing), Case Management Agent (Customer Service only — creates, updates, resolves and closes cases; needs pay-as-you-go), Customer Knowledge Management Agent (turns resolved cases into draft knowledge articles), Customer Intent Agent (builds an intent library from interactions), Customer Assist Agent, Quality Assurance Agent, Service Operations Agent, and the Admin Management Agent (preview).
- Dynamics 365 Contact Center supplies the omnichannel engagement layer — voice, chat, digital messaging, routing, workstreams, queues, supervision — standalone or embedded. Customer Service supplies the CRM case and knowledge management layer.
- Custom agents are built in Copilot Studio, connected to the omnichannel instance and added to a push-based workstream/queue. One agent per workstream. One agent serves multiple channels without channel-specific code, and transfers transcript plus collected variables on escalation.
- Admin configuration is a recurring set: enable Copilot features in the Power Platform admin center, opt in per feature in the Copilot Service admin center, publish knowledge sources, assign experience profiles, grant Copilot table privileges to custom roles, and enable cross-region data movement where required.
Applying it to a scenario
- "Which components make up the solution?" → name the agent, the channel/workstream, the knowledge source, the connection reference, and the security role. Component questions reward completeness.
- "Configure or build?" → if a named prebuilt agent covers it (case management, knowledge drafting, intent), configure that. Build in Copilot Studio only when no prebuilt agent fits.
- Watch region wording: several Copilot features are GA in North America and preview elsewhere.
Voice in a Copilot Studio agent
Voice is explicitly in scope and is genuinely a different design problem from text — the modality, the telephony stack and the conversation design all change. It is easy to skip while revising.
What you need to know
- A voice-enabled agent uses the Speech & DTMF modality, which is mutually exclusive with Text. It gains voice system topics for silence, unrecognised speech and unknown keypad input. Enabling voice authoring is not enough — you must also configure the Telephony channel and publish.
- Two documented voice agent types: a basic voice agent (classic, deterministic — speech-to-text → NLU → topic flow → text-to-speech) and a real-time agent (generative, context aware, low latency).
- Telephony: the standard path connects the agent to a Dynamics 365 Contact Center voice workstream, with the phone number obtained or reused through Azure Communication Services. Existing carrier infrastructure connects via ACS Direct Routing through a certified Session Border Controller using TLS/SIP with number-pattern voice routes.
- DTMF supports global single-key commands, mapped menu options, multi-digit collection, optional
*/#termination, interdigit and termination timeouts, caching, and a customisable *Unknown dial pad press* topic. - Speech handling (basic voice): customised recognition from trigger phrases, speech sensitivity, utterance-end timeout, recognition timeout and silence detection. Real-time agents trade these controls for natural turn-taking and much lower latency.
- Barge-in lets speech or DTMF interrupt playback, controllable per message. Disable it for essential or compliance messages; leave it on for long familiar menus.
- Latency controls: silence timeout and reprompts, latency-message delay, minimum playback time. Use a latency message around long-running actions, and a static greeting to cut first-response time.
- SSML is supported on voice-channel message nodes. GPT-Realtime offers a limited built-in voice set; GPT-5-Chat (preview) uses Microsoft Neural TTS with a broader catalogue and custom branded voices, at higher latency.
- Escalation: Transfer Conversation routes to a representative or an external phone number, passing conversation history and variables. Recording/transcription is configured per voice workstream; Copilot Studio still produces an agent transcript even when Contact Center recording is off, and recording requires consent where law demands it.
- Design guidance for voice: short turns, one question at a time, deterministic confirmation before acting, tool-grounded facts, explicit escalation, standardised closing. On Error should transfer or end the call rather than leave the caller in silence.
Applying it to a scenario
- Existing SIP trunks → ACS Direct Routing with a certified SBC, rather than porting numbers.
- Callers interrupting a compliance disclosure → disable barge-in on that message only.
- Long backend lookup → a latency message, plus a check on the tool's own timeout.
- Caller must enter an account number → DTMF multi-digit collection with a termination key, not free speech.
ROI — which tool measures what
ROI at architect level is rarely arithmetic. It is knowing which Microsoft surface produces which number, for which audience — and that is a mapping worth memorising.
What you need to know
- Copilot Studio → Monitor → Savings: estimated time or money saved per run or per tool, against a stated comparison method. Best for per-agent business cases.
- Microsoft Copilot Dashboard in Viva Insights: readiness, adoption, impact and sentiment, with benchmarks, surveys and group-level analysis. Best for organisation-wide value reporting to a sponsor.
- Microsoft 365 admin center Copilot usage report: enabled users, active users and rate, prompts submitted, prompts per user, adoption by app, trends and agent engagement. Best for adoption tracking.
- Power Platform admin center → Licensing → Copilot Studio: prepaid and pay-as-you-go consumption, trends by environment, product and agent, billed versus non-billable credits, limits and nearing-limit status. Best for cost control. Capacity separately covers Dataverse database, file and log storage.
- Microsoft Cost Management for Azure-side pay-as-you-go spend, with budgets, anomaly detection, exports and alerts.
- The consumption unit is Copilot Credits, not "messages". Rates are feature-based — for example 1 credit for a classic answer, 2 for a generative answer, 5 for an agent action, 10 for tenant graph grounding, with separate rates for agent flow actions, AI tools and tokens, content processing and voice. One interaction can consume several credit categories.
- Build the business case on baseline → intervention → measured delta, and report business outcomes (deflection, handle time, cycle time, task completion) rather than technical outputs.
Applying it to a scenario
- Audience is an executive sponsor → Copilot Dashboard / business outcome language. Audience is an admin watching spend → PPAC licensing and capacity. Audience is the product owner of one agent → Monitor → Savings.
- "Costs are higher than forecast" → check credit consumption by agent in PPAC, then look at what the agent does per turn (generative answers, graph grounding, tool calls).
Model router
A specific named Foundry capability that answers cost-and-latency optimisation questions — and that is easy to confuse with load balancing, failover or fine-tuning.
What you need to know
- A model router in Microsoft Foundry is itself a deployed, trained model that selects an eligible underlying model per request.
- Modes: Balanced weighs quality against cost; Cost accepts a wider quality band to reduce spend; Quality always selects the highest-rated model.
- It removes the need to hand-write routing logic, and can improve both cost and latency while holding quality roughly comparable — but Microsoft explicitly recommends evaluating it against your own workload rather than assuming the gain.
- It fits when a workload has a mix of easy and hard requests. It does not fit when every request needs the same frontier-model quality, or when the real problem is grounding rather than model choice.
Applying it to a scenario
- Mixed workload, cost pressure, quality must not regress → model router in Balanced mode, validated with an evaluation set.
- High-volume, narrow, latency-sensitive task → a small language model (SLM) is often the better fit.
- Answers are wrong or uncited → that is grounding, not routing. Fix the knowledge source.
Semantic indexing
A grounding and permissions concept that shares a word with a completely different Azure AI Search feature. The confusion is extremely common and worth deliberately clearing up.
What you need to know
- Semantic indexing builds a conceptual, contextual representation of Microsoft 365 and connected external content so retrieval can match on meaning and relationships rather than exact keywords.
- Copilot grounds by reaching organisational data through Microsoft Graph in the signed-in user's context. It only ever surfaces content that user is already authorised to see — indexing does not grant tenant-wide visibility.
- Synced Copilot connectors ingest and index external content into Microsoft Graph and support semantic indexing. Federated connectors retrieve at query time (via MCP) and do not semantically index into Graph. External item ACLs must be configured to control visibility.
- Retrieval and generation are separate stages: semantic index retrieval supplies passages, the model then generates the grounded answer. That is the retrieval half of RAG.
- Current documentation increasingly uses Work IQ for the broader permission-aware workplace intelligence layer spanning Microsoft 365 and external systems. Semantic indexing remains an active term in connector documentation, and the two are not exact synonyms — Work IQ is broader than an index.
- Azure AI Search semantic ranker is a different thing. It reranks an initial BM25 or RRF result set at query time using language understanding models, and can return captions, answers and rewritten queries. It runs over an Azure AI Search index that *you* build and manage.
Applying it to a scenario
- "An agent surfaced a document the user shouldn't see" → a permissions/ACL failure at the source, not an indexing failure.
- External system, content must be searchable by meaning inside Microsoft 365 Copilot → a synced Copilot connector with ACLs.
- External system, data must always be live and must not be copied → a federated connector (no semantic index in Graph).
- Improve relevance of results from an Azure AI Search index → semantic ranker, not the Microsoft 365 semantic index.
Last-week revision order
If time is short, work down this list rather than re-reading all eleven modules.
- Connection references and environment variables — what moves with a solution and what does not. Precise, factual, and easy to half-learn.
- Managed vs. unmanaged, and unmanaged layers. Pair it with pipelines and the deployment settings file.
- Azure Monitor vs. Application Insights vs. Log Analytics workspace, and the two routes for getting Copilot Studio telemetry into them.
- The Copilot Studio Monitor page and agent evaluations — current metric names, and evaluation as a pre-deployment gate.
- Dynamics 365 named capabilities and prebuilt agents for Field Service and Customer Service, including which ones are retired.
- Voice agent design — Speech & DTMF modality, telephony via Contact Center and ACS, barge-in, latency messages, escalation.
- Copilot Credits and the ROI toolset — which surface answers which audience's question.
- Semantic indexing vs. Azure AI Search semantic ranking, and synced vs. federated connectors.
- Model router modes, and when an SLM is the better answer.
- Finally, re-read the cram sheet golden rules — they resolve most of the judgement-based scenarios the topics above do not cover.
Unofficial study aid written from the public Microsoft Learn path, the published skills outline, and Microsoft product documentation. Not affiliated with or endorsed by Microsoft — though the Learn modules and the video course it links out to are official Microsoft material. Contains no exam content: no real exam items are reproduced, paraphrased, or recalled.