AB-100 — Agentic AI Solutions Architect Scenario Practice Guide

AB-100 scenarios for the Microsoft Certified: Agentic AI Business Solutions Architect exam are not usually asking for a memorized phrase. They ask whether you can turn a business problem into a practical, secure, governable agentic AI solution.

The best answer is often the one that fits the stated outcome, respects the operating constraints, and avoids unnecessary complexity. Your job is to slow down long enough to identify the real decision point before comparing the answer choices.

This guide is an independent exam-preparation resource. Use it with current Microsoft Learn content, product documentation, hands-on labs, and full-length practice exams.

What AB-100 scenario questions are really testing

As a business solutions architect, you are expected to connect several layers of reasoning:

• Business outcome: What does the organization need to improve, automate, reduce, or control?
• Agent behavior: What should the AI agent know, decide, ask, trigger, escalate, or avoid doing?
• Microsoft environment: Which Microsoft services, platforms, identity controls, data sources, collaboration tools, or integration points are already in use?
• Security and governance: What data can the agent access, what actions can it perform, and how is that access controlled?
• Operational readiness: How will the solution be tested, monitored, improved, handed off, and governed over time?
• Trade-off management: What is the simplest architecture that satisfies the stated requirements without violating constraints?

A strong candidate reads the scenario as an architecture brief, not as a product-recognition puzzle.

Start by finding the decision point

Before reading every answer choice in detail, ask: What decision is the question actually asking me to make?

Common AB-100 decision points may include:

• Selecting the best agentic AI solution pattern
• Choosing how an agent should be grounded in enterprise data
• Deciding where to place human approval or escalation
• Selecting the right integration approach for systems, APIs, workflows, or business applications
• Applying least privilege, identity, compliance, or governance controls
• Choosing a deployment, evaluation, or monitoring approach
• Prioritizing requirements during solution design
• Resolving a symptom in an existing agentic AI solution

Do not solve the whole story at once. Convert the question into one sentence:

“Given this environment and these constraints, what is the best next design decision?”

That sentence keeps you from being pulled toward attractive but irrelevant answer choices.

Use a consistent scenario-reading sequence

1. Identify the business outcome

Read for the organization’s objective first. Agentic AI architecture should be justified by a business need, not by novelty.

Look for phrases such as:

• Reduce manual case handling
• Improve employee self-service
• Automate multi-step business processes
• Assist sellers, service agents, analysts, or operations teams
• Improve accuracy, consistency, or response time
• Enforce policy while allowing faster execution
• Summarize, classify, route, recommend, or act on information

Then ask:

• Is the goal assistance, automation, decision support, or autonomous action?
• Is the agent expected to provide information only, or also take actions?
• Is the primary value speed, quality, compliance, scale, cost reduction, or user experience?

If the scenario says the business needs recommendations only, an answer that grants broad write access may be too aggressive. If the business needs end-to-end process automation, an answer limited to static content search may be incomplete.

2. Identify the users and operating context

Agentic AI solutions behave differently depending on who uses them and where they run.

Extract:

• User type: employee, manager, customer service agent, seller, partner, administrator, customer
• Channel: Microsoft Teams, web app, business application, service desk, intranet, custom app, workflow interface
• Work pattern: ad hoc Q&A, repeated process, case resolution, approvals, analytics, document handling
• User skill level: technical, nontechnical, citizen developer, professional developer, operations team
• Volume and criticality: occasional support task versus business-critical workflow

The best answer should fit the people who will own and use the solution. A low-code configuration may be appropriate for a business-owned process. A pro-code or custom integration path may be more appropriate when there are complex APIs, strict lifecycle controls, or specialized runtime requirements.

3. Locate the current Microsoft environment

AB-100 scenarios often include environmental clues that narrow the answer.

Watch for references to:

• Microsoft 365, Teams, SharePoint, OneDrive, Exchange, or Viva
• Power Platform, Power Automate, Power Apps, Dataverse, or connectors
• Microsoft Copilot, Copilot Studio, or custom agents
• Azure AI services, Azure AI Foundry, Azure OpenAI, Azure Functions, or API Management
• Microsoft Entra ID, conditional access, managed identities, or role-based access control
• Microsoft Purview, sensitivity labels, data loss prevention, audit, retention, or compliance needs
• Dynamics 365, customer service, sales, finance, operations, or other line-of-business systems

Do not choose a tool just because it is familiar. Choose it because the scenario’s environment, data sources, governance requirements, and solution ownership model support it.

4. Separate hard constraints from preferences

A scenario may include both mandatory requirements and nice-to-have details. Treat them differently.

Hard constraints often sound like:

• “Must”
• “Required”
• “Cannot”
• “Only”
• “Without”
• “Minimize”
• “Ensure”
• “Comply with”
• “No custom code”
• “Use existing Microsoft 365 data”
• “Require human approval”
• “Prevent access to confidential information”

Preferences often sound like:

• “Prefer”
• “Would like”
• “If possible”
• “Currently uses”
• “Wants to reduce”
• “Plans to”

The best answer must satisfy the hard constraints first. A choice that satisfies a preference but violates a security, compliance, access, or architecture requirement is not defensible.

Build an AB-100 answer from the facts

Determine the agent’s role

Ask what the agent is actually responsible for.

• Informational agent: Answers questions from approved knowledge sources.
• Task assistant: Helps a user complete a process but keeps the user in control.
• Workflow agent: Triggers steps, routes items, creates records, or updates systems.
• Autonomous or semi-autonomous agent: Acts across tools based on goals, rules, and guardrails.
• Supervisor or coordinator pattern: Breaks work into steps or coordinates specialized agents or tools.

The more authority the agent has, the more important the controls become:

• Clear scope
• Approved data sources
• Least-privilege access
• Human approval for sensitive actions
• Logging and auditability
• Evaluation and monitoring
• Failure handling and escalation

A scenario about responding to policy questions does not need the same architecture as a scenario about updating customer records, issuing refunds, or triggering operational workflows.

Match grounding to the data requirement

Agentic AI solutions need reliable context. The scenario may describe where knowledge lives and how current it must be.

Ask:

• Is the answer based on enterprise documents, structured records, business application data, real-time operational data, or external sources?
• Does the data need to be filtered by user permissions?
• Does the agent need retrieval only, or does it need to call tools and update systems?
• Is the source authoritative?
• Does the organization need citations, traceability, or explainability?
• Are there sensitivity labels, retention rules, or data boundaries?

If the scenario emphasizes authoritative documents and permission-aware access, choose a grounding pattern that respects existing data controls. If it emphasizes transactional data or actions, look for integration with APIs, connectors, workflows, or business systems rather than static document ingestion alone.

Match actions to integration needs

Agentic AI becomes business architecture when it performs or initiates work.

Look for verbs in the scenario:

• Create a case
• Update an opportunity
• Submit an approval
• Send a notification
• Retrieve account details
• Route a request
• Generate a proposal
• Escalate to a specialist
• Invoke a backend process
• Check order status
• Open a service ticket

Each action implies an integration decision.

Ask:

• Is there an existing connector or workflow?
• Is a custom API required?
• Should the action run under the user’s identity, a service identity, or a managed identity?
• Does the action require approval?
• Is the action reversible?
• Does the action affect regulated, financial, customer, or employee data?
• How will errors be handled?

When two answers both “work,” prefer the one that uses existing governed integrations, scopes permissions tightly, and preserves auditability.

Decide where human-in-the-loop belongs

Agentic AI scenarios often include a tension between automation and control. Human approval is not always required, but it is often the best architectural choice when risk is high.

Human review is more likely when the agent will:

• Change customer, employee, financial, or legal records
• Send external communications
• Make decisions with compliance impact
• Trigger irreversible or costly actions
• Access sensitive or confidential data
• Operate in a newly deployed or unvalidated process
• Handle exceptions outside normal policy

Human review is less likely when the task is low-risk, reversible, internal, and already governed by existing permissions and workflow controls.

The strongest answer usually places human review at the risk point, not everywhere. Requiring approval for every low-risk answer can make a solution unusable. Allowing full autonomy for sensitive actions can make it unsafe.

Read security clues as architecture requirements

Security is not an afterthought in AB-100 scenarios. It is part of the design.

Least privilege

If the agent needs to access data or perform actions, identify the minimum required permissions.

Ask:

• What data does the agent need?
• Which users should be able to use it?
• What actions should it perform?
• Does it need read-only access, write access, or delegated user access?
• Should access be filtered based on the signed-in user?
• Are separate roles needed for authors, operators, administrators, and end users?

A broad administrator-level permission is rarely the best architecture unless the scenario explicitly justifies it.

Identity and access control

Microsoft scenarios may include identity details that point to Microsoft Entra ID, conditional access, managed identities, single sign-on, role assignments, or group-based access.

Focus on the principle:

The agent should authenticate clearly, authorize narrowly, and preserve accountability.

When comparing answers, favor the one that makes it possible to know who requested an action, what the agent did, and which policy allowed it.

Data protection and compliance

Watch for signals such as confidential information, regulated data, customer data, HR records, finance records, legal documents, or cross-region concerns.

The best answer may include:

• Sensitivity-aware access
• Data loss prevention controls
• Audit logs
• Retention or deletion alignment
• Environment separation
• Approved connectors
• Policy-based governance
• Monitoring for inappropriate access or use
• Limiting data exposure in prompts, responses, logs, or external systems

Do not choose an answer that solves the functional problem by copying sensitive data into a less governed location unless the scenario explicitly supports that design.

Choose the least complex solution that satisfies the requirements

AB-100 architecture questions often include more than one technically possible answer. The most defensible answer is usually the one that meets the requirements with the least unnecessary complexity.

Use this order:

1. Meets the business goal
2. Satisfies mandatory constraints
3. Fits the Microsoft environment
4. Protects data and access
5. Supports required actions and integrations
6. Can be governed and maintained
7. Avoids unnecessary custom development or operational burden

“Most advanced” is not the same as “best.” If an organization can meet the requirement with a governed, supported, low-code agent and existing connectors, a custom distributed architecture may be excessive. If the requirement involves complex orchestration, custom APIs, strict lifecycle control, or specialized evaluation, a simple out-of-the-box approach may be insufficient.

Interpret common scenario wording

Use wording clues to decide what the examiner is asking you to prioritize.

Work through answer choices defensibly

After reading the scenario, compare answer choices against the facts. Do not ask, “Could this work?” Ask, “Is this the best supported choice?”

First pass: eliminate violations

Remove answers that:

• Ignore a stated “must” requirement
• Violate least privilege
• Expose sensitive data unnecessarily
• Require custom development when the scenario requires minimal development
• Use a service or pattern that does not fit the stated environment
• Skip required approval, audit, or compliance controls
• Solve a different problem than the one asked
• Add complexity without satisfying an unmet requirement

Second pass: compare the remaining choices

For the remaining options, ask:

• Which answer satisfies the most important requirement directly?
• Which answer uses the existing environment most naturally?
• Which answer preserves user permissions and accountability?
• Which answer has the lowest operational risk?
• Which answer handles the full lifecycle, not just the initial build?
• Which answer addresses the specific symptom or goal stated in the question?

The correct answer is not always the longest or most detailed. It is the answer that best aligns with the scenario’s decision point.

Scenario pattern: designing a customer service agent

Imagine a scenario where a company wants an agent to help support representatives answer customer questions and update cases. The company uses Microsoft 365 for internal knowledge and a CRM system for customer records. Case updates must be reviewed by a support representative before submission.

Reason through it like this:

1. Business goal: Help representatives resolve cases faster.
2. Users: Internal support representatives, not customers directly.
3. Knowledge need: Ground answers in approved internal content.
4. Action need: Update CRM case records.
5. Risk point: Case updates require human review.
6. Security: Representatives should only access permitted cases and knowledge.
7. Best design direction: An agent grounded in approved content, integrated with the CRM through a governed connector or API, with human approval before write actions and logging for traceability.

A weaker answer might automate all case updates without review. Another weak answer might provide Q&A only and ignore the required CRM update process. The strongest answer addresses both knowledge retrieval and controlled action.

Scenario pattern: protecting sensitive HR data

Imagine a scenario where HR wants an employee-facing agent to answer policy questions. Some HR documents contain manager-only information. Employees must not see content they are not authorized to access.

Reason through it like this:

1. Business goal: Employee self-service for HR policy questions.
2. Data issue: Mixed-sensitivity HR content.
3. Security requirement: Prevent unauthorized access.
4. Architecture priority: Permission-aware grounding and data governance.
5. Best design direction: Use approved content sources with access controls, sensitivity or governance policies where applicable, and validation that responses do not expose restricted content.

A choice that indexes all HR files into one broadly accessible knowledge source would not be defensible, even if it improves answer coverage.

Scenario pattern: automating a multi-step internal workflow

Imagine a scenario where finance wants to automate vendor onboarding. The process includes collecting information, validating documents, checking approval rules, creating vendor records, and notifying stakeholders.

Reason through it like this:

1. Business goal: Automate a repeatable business process.
2. Process type: Multi-step workflow with approvals and system updates.
3. Integration need: Business applications, document storage, notifications, and possibly approval workflows.
4. Risk: Vendor records and financial processes require controls.
5. Best design direction: Combine agent interaction with governed workflow automation, connectors or APIs, role-based access, approval gates, and audit logs.

A pure conversational answer is incomplete. A fully autonomous answer without approval or audit is likely too risky.

Troubleshooting scenario approach

Some AB-100 questions may describe a solution that is already built and failing in some way. Treat troubleshooting scenarios differently from design scenarios.

Find the symptom

Identify what is actually wrong:

• Agent gives inaccurate answers
• Agent cannot access a data source
• Agent exposes information to the wrong users
• Agent fails to call an action
• Workflow runs under the wrong identity
• Users receive inconsistent results
• Updates are not written to the target system
• Monitoring shows errors after a recent change
• Latency or availability is affecting adoption

Identify scope and recent change

Ask:

• Is the problem affecting all users or only some?
• Is it limited to one data source, connector, environment, channel, or action?
• Did permissions, policies, connectors, prompts, data, workflows, or deployments recently change?
• Is the failure in retrieval, reasoning, authentication, authorization, integration, or downstream system behavior?

Choose the least disruptive fix

For troubleshooting, the best first step is often the one that confirms the cause or fixes the narrowest failing component.

Prefer answers that:

• Check logs, traces, run history, or monitoring data when cause is unclear
• Validate identity and permission configuration when access is failing
• Test the connector, API, or workflow separately when action execution fails
• Review grounding sources when answers are inaccurate or outdated
• Roll back or correct the recent change when symptoms align with it
• Preserve production stability while isolating the issue

Avoid jumping immediately to rebuilding the solution unless the scenario proves the architecture cannot meet the requirement.

Think in layers: business, agent, data, action, governance

For final review, use this compact layer model.

Business layer

• What outcome matters?
• Who owns the process?
• What success measure is implied?
• What requirement is mandatory?

Agent layer

• What should the agent answer, decide, or do?
• How autonomous should it be?
• What should it refuse, escalate, or ask a human to approve?
• What instructions, topics, skills, tools, or orchestration does it need?

Data layer

• Which sources are authoritative?
• Is data structured, unstructured, or both?
• Does the agent need fresh data?
• Are permissions, labels, retention, or compliance controls relevant?

Action layer

• Which systems must the agent call?
• Are connectors, workflows, APIs, or custom services needed?
• What identity is used for actions?
• Are actions read-only, reversible, or high impact?

Governance layer

• Who can build, publish, manage, and use the agent?
• How are environments separated?
• How are policies enforced?
• How are prompts, tools, data sources, and changes reviewed?
• How is performance monitored after deployment?

When you are stuck between two choices, the missing layer often reveals the better answer.

How to handle “best next step” questions

“Best next step” questions are about sequence. Do not choose a later implementation task if an earlier architecture decision is unresolved.

A good sequence is usually:

1. Clarify the business process and success criteria.
2. Identify data sources, users, and security requirements.
3. Select the agent pattern and integration approach.
4. Define guardrails, human review, and governance.
5. Build or configure the solution.
6. Test with representative users and data.
7. Deploy using approved lifecycle practices.
8. Monitor, evaluate, and improve.

If the scenario says requirements are unclear, the best next step may be discovery, stakeholder alignment, or process mapping. If the scenario says design is approved and the problem is permissions, the next step may be configuring identity or access. Always match the step to the current state.

How to handle “most appropriate service or approach” questions

When the question asks for a Microsoft service, platform, or approach, map facts to capability.

Ask:

• Does the scenario favor a low-code business solution, a custom AI application, or a hybrid?
• Is the agent primarily for Microsoft 365 productivity, business process automation, customer engagement, or custom application integration?
• Are standard connectors enough, or does the scenario require custom APIs?
• Is the solution owned by business makers, IT, developers, or a shared team?
• Are lifecycle, monitoring, testing, and governance requirements explicit?
• Is the requirement about building the agent, securing it, grounding it, integrating it, or operating it?

A product name in the answer is not enough. The surrounding approach must match the scenario.

How to use practice questions for final review

After each AB-100 practice scenario, do a short review instead of only checking right or wrong.

Write down:

• The decision point in one sentence
• The must-have requirements
• The environment clues
• The security or governance clue
• The reason the correct answer is defensible
• The reason each tempting answer is weaker
• The product area or concept you need to review

This turns scenario practice into architecture training. Over time, you will see patterns: grounding decisions, action control, identity, governance, lifecycle, and business-fit trade-offs.

Final scenario checklist

Use this checklist during timed review:

• What is the business outcome?
• Who are the users?
• What Microsoft environment is already present?
• What data sources are authoritative?
• What actions must the agent perform?
• Are actions read-only, write, reversible, or high-risk?
• What constraints are mandatory?
• What security, compliance, or governance requirement is stated?
• Is human approval needed?
• What is the least complex approach that satisfies all requirements?
• Does the answer fit the current state of the scenario?
• Can I defend this answer using specific facts from the prompt?

If you cannot point to scenario facts supporting your choice, slow down and reread the final sentence of the question.

Practical next step

For your next study session, complete a set of AB-100 scenario questions by forcing yourself to identify the decision point before reading the answers. Then follow with targeted drills on the areas that caused hesitation, such as grounding, connectors and workflows, identity, governance, human-in-the-loop design, or agent lifecycle management. Finish with a timed mock exam to practice applying the same reasoning under pressure.