AB-100 — Microsoft Certified: Agentic AI Business Solutions Architect Cheat Sheet
Last revised: September 16, 2026
Compact AB-100 Cheat sheet for designing secure, governed, business-aligned agentic AI solutions with Microsoft technologies.
Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.
Scope and study context
Item
Reference
Vendor/provider
Microsoft
Certification title
Microsoft Certified: Agentic AI Business Solutions Architect (AB-100)
Exam code
AB-100
Candidate mindset
Translate business outcomes into secure, governed, measurable agentic AI solutions across Microsoft services.
Common exam angle
Choose the right architecture, Microsoft service, control boundary, data grounding pattern, evaluation approach, and operational model.
AB-100 scenarios are likely to reward architecture decisions more than feature memorization. Think in this order:
Business objective: What outcome, user group, process, and success metric?
Agent fit: Should the solution be an agent, copilot extension, workflow automation, or standard app?
Grounding: What data is authoritative, fresh, permission-trimmed, and auditable?
Actions: What tools, APIs, connectors, and approvals are needed?
Safety and governance: What can the agent do, for whom, under what policy?
Evaluation: How will quality, risk, and business value be measured before and after release?
Operations: How will the solution be monitored, improved, and controlled over time?
The exam mindset is architectural: you are not just choosing an AI feature. You are translating a business outcome into a secure, governed, measurable agentic solution that can interact with people, data, tools, and enterprise processes.
After this Cheat Sheet, move into IT Mastery practice with original practice questions. For each question:
Identify the business goal before reading the answers.
Mark the key constraint: security, cost, governance, autonomy, data freshness, or user workflow.
Eliminate answers that rely only on prompting for security or compliance.
Prefer the least complex architecture that satisfies all requirements.
Review the detailed explanations for both correct and incorrect choices.
Use topic drills for weak areas such as grounding, tool execution, governance, or evaluation.
Core Agentic AI Concepts
Concept
Exam-ready meaning
High-yield distinction
Agent
AI system that can reason over goals, use tools, retrieve context, and take steps toward a task.
More autonomous than a single prompt-response chatbot.
Copilot
User-facing AI assistant, often embedded in a Microsoft experience.
Usually assists a human; may be extended with plugins, connectors, or agents.
Tool use
Agent calls APIs, functions, connectors, workflows, or external systems.
Requires strict authorization, input validation, and audit logging.
Grounding
Supplying the model with trusted enterprise data.
Reduces hallucination but does not eliminate need for evaluation.
RAG
Retrieval-augmented generation: retrieve relevant content, then generate an answer grounded in that content.
Good for knowledge-heavy scenarios; not enough for transactional actions.
Orchestration
Logic that plans steps, calls tools, manages state, and handles fallback.
Can be low-code, pro-code, or hybrid.
Human in the loop
Human review, approval, or escalation before or after agent action.
Essential for high-impact, irreversible, regulated, or ambiguous decisions.
Guardrails
Policies, constraints, filters, prompt instructions, validation, and monitoring.
Must be layered; prompt instructions alone are weak controls.
Evaluation
Testing agent quality, safety, grounding, tool accuracy, and business outcomes.
Should happen before release and continuously after deployment.
Responsible AI
Design discipline for fairness, reliability and safety, privacy and security, inclusiveness, transparency, and accountability.
Architecture concern, not just a policy document.
Microsoft Service Selection Matrix
Requirement
Prefer
Why
Watch for
Build low-code business agents for Teams, Microsoft 365, customer service, or internal workflows
Microsoft Copilot Studio
Fast agent creation, topics, actions, connectors, governance through Power Platform ecosystem.
Do not choose pro-code services when low-code connectors and governance meet the requirement.
Extend Microsoft 365 Copilot with enterprise data or actions
Copilot Studio, Microsoft Graph connectors, plugins/actions
Keeps experience close to Microsoft 365 users and permission-aware content.
Respect existing Microsoft 365 and Graph permissions.
Build custom, pro-code agentic apps with fine-grained orchestration
Azure AI Foundry, Azure AI Agent Service, Azure OpenAI Service, Semantic Kernel
More control over model selection, tools, retrieval, orchestration, app integration, and DevOps.
Requires deeper engineering, security, and operations design.
Add enterprise search grounding over documents and structured indexes
Refresh more often or retrieve live from source system.
Identity, Access, and Security
Topic
Exam-ready rule
Least privilege
Give the agent, tools, and users only the permissions required for the task.
User-delegated access
Use when results/actions must reflect the signed-in user’s permissions.
App-only access
Use only when the app has its own controlled service permissions and business justification.
Managed identity
Prefer for Azure-hosted workloads accessing Azure resources.
Secrets
Store in Azure Key Vault or managed secret stores; do not place secrets in prompts or code.
API security
Put controlled contracts in front of systems; validate input and output.
Network controls
Use private access patterns where required by the organization’s security model.
Data protection
Classify data, apply DLP, encryption, retention, and access reviews according to policy.
Prompt injection
Treat retrieved content and user input as untrusted; isolate instructions from data.
Auditability
Log user, tool, action, approval, result, and correlation IDs where appropriate.
Notes and examples
Delegated vs App-Only Access
Use delegated access when…
Use app-only access when…
The answer must be trimmed to the user’s rights.
A background process performs a controlled organizational task.
The user is responsible for the action.
The application identity is responsible for the action.
Different users should see different results.
All authorized users receive the same approved service behavior.
Microsoft 365 or Graph data must follow user permissions.
A curated service index or backend API has its own authorization layer.
Common trap: Using one highly privileged app identity to retrieve all enterprise data can violate least privilege and produce data leakage.
Data security and identity controls
For AB-100, security is not an afterthought. Agentic systems can amplify access because they combine natural language, data retrieval, and action execution.
Control area
What to design for
Identity
Use enterprise identity such as Microsoft Entra ID where appropriate
Authorization
Apply least privilege to users, agents, connectors, and service identities
Permission trimming
Ensure retrieved content respects the user’s access rights
Secrets
Store credentials securely; do not place secrets in prompts or code
Data loss prevention
Apply policies to prevent sensitive data movement to unauthorized systems
Audit logging
Record important prompts, tool calls, approvals, and outputs where appropriate
Environment separation
Separate development, test, and production environments
Conditional access
Consider user, device, network, and risk context where relevant
Data lifecycle
Address retention, deletion, classification, and sensitivity labels when required
Security traps
Using a high-privilege service account that lets the agent retrieve or modify more data than the user can access.
Treating prompts as a security boundary.
Allowing unrestricted tool calls from untrusted user input.
Returning retrieved content without checking sensitivity or access.
Logging sensitive prompts or responses without retention and access controls.
Forgetting that connectors and plugins may expand the agent’s effective attack surface.
Tool and Action Design
Design element
Recommendation
Tool contract
Use explicit schemas, required fields, allowed values, and clear descriptions.
Authorization
Enforce outside the model in the API/workflow layer.
Validation
Validate model-provided parameters as untrusted input.
Idempotency
Design repeated calls not to duplicate harmful actions.
Confirmation
Preview high-impact actions before execution.
Error handling
Return structured errors the orchestrator can handle safely.
Logging
Record action intent, parameters where safe, actor, approval, result, and correlation ID.
Rollback
Provide compensation or reversal for actions where possible.
Rate control
Protect backend systems from loops or excessive calls.
Notes and examples
Example tool contract style:
{"name":"create_support_ticket","description":"Create a support ticket after user confirmation.","parameters":{"type":"object","properties":{"customerId":{"type":"string"},"severity":{"type":"string","enum":["low","medium","high"]},"summary":{"type":"string"}},"required":["customerId","severity","summary"]}}
Architectural point: the schema helps the model call the tool correctly, but the backend still must enforce permissions, validation, and business rules.
Prompt, Instruction, and Memory Controls
Area
Good practice
Avoid
System/developer instructions
State role, allowed tasks, forbidden tasks, escalation rules, citation rules.
Hiding security-critical logic only in natural-language instructions.
User input
Treat as untrusted.
Letting user override policy, identity, or tool restrictions.
Retrieved content
Treat as data, not instructions.
Allowing documents to redefine the agent’s behavior.
Conversation history
Keep only relevant context.
Sending unnecessary sensitive history into every request.
Memory
Store explicit, consented, useful facts where appropriate.
Persisting sensitive inferred data without governance.
Output format
Use structured output for tool calls and downstream systems.
Free-form output when a deterministic schema is required.
Notes and examples
Prompt Injection Defense Layers
Layer
Control
Instruction hierarchy
Keep trusted system instructions separate from user and retrieved content.
Retrieval filtering
Retrieve only authorized, relevant content.
Tool allowlist
Only expose tools needed for the current task.
Parameter validation
Reject unsafe or unauthorized tool arguments.
Action approval
Require human approval for sensitive actions.
Output filtering
Detect unsafe, unsupported, or policy-violating output.
Monitoring
Review suspicious prompts, failed guardrails, and abnormal tool usage.
Responsible AI and Risk Controls
Microsoft Responsible AI principle
Architecture implications
Fairness
Test for uneven quality or harmful outcomes across user groups and scenarios.
Reliability and safety
Evaluate failure modes, fallback behavior, and robustness before production use.
Privacy and security
Minimize data exposure, secure identities, protect prompts and outputs.
Inclusiveness
Design accessible experiences and support diverse user needs.
Transparency
Tell users they are interacting with AI, show sources, explain limitations.
Business outcome — What measurable process, decision, or user experience needs improvement?
User and workflow context — Who uses the agent, where, and at what point in the process?
Agent capability — Should the solution answer, recommend, summarize, plan, or act?
Grounding and data — What trusted enterprise data is required, and how are permissions enforced?
Tools and actions — Which systems can the agent call, and what approvals are required?
Risk controls — How will the design reduce hallucination, prompt injection, data leakage, unsafe actions, and compliance risk?
Evaluation — How will quality, safety, cost, latency, and business impact be measured?
Operations — How will the agent be monitored, updated, versioned, and governed after deployment?
flowchart LR
A[Business outcome] --> B[User workflow]
B --> C[Agent role and autonomy]
C --> D[Grounding data]
D --> E[Tools and actions]
E --> F[Security and governance]
F --> G[Evaluation and testing]
G --> H[Deployment and operations]
H --> I[Continuous improvement]
High-yield Microsoft solution positioning
AB-100 questions often test whether you can select an appropriate Microsoft-aligned architecture pattern, not just name a product.
Need in the scenario
Likely architectural direction
Watch for
Employees need AI assistance inside Microsoft 365 work patterns
Extend or configure Microsoft 365 Copilot experiences where appropriate
Do not build a separate custom app if the requirement is mainly productivity-context assistance
Business users need a low-code conversational agent for internal or customer workflows
Consider Microsoft Copilot Studio with connectors, topics, actions, and governance
Confirm data sources, authentication, escalation, and environment strategy
Solution needs advanced custom orchestration, model selection, evaluation, or AI application lifecycle control
Consider Azure AI Foundry and related Azure services
Higher flexibility usually means more design responsibility
Agent must retrieve enterprise knowledge from documents or indexed data
Use a grounded retrieval pattern, often with search/indexing and permission controls
Do not rely on the model’s general knowledge for enterprise facts
Agent must update records, submit requests, or trigger workflows
Use tools, APIs, connectors, Power Automate, Logic Apps, or custom services
Require approvals, auditability, idempotency, and error handling
User only needs deterministic workflow automation
Use workflow automation instead of an agent when natural-language reasoning is unnecessary
Do not overuse agentic AI for fixed rule-based processes
Sensitive or regulated process with material business impact
Add human-in-the-loop, policy checks, logging, and constrained tool execution
Prompt instructions alone are not sufficient control
Key terms to know cold
Term
Practical meaning
Exam trap
Agent
AI system that can reason over context, use tools, and pursue a task through multiple steps
Treating every chatbot as a true agent
Copilot
AI assistant experience embedded in a user workflow
Assuming a copilot always has permission to all enterprise data
Grounding
Supplying trusted context to improve relevance and reduce unsupported answers
Confusing grounding with model training
RAG
Retrieval-augmented generation: retrieve relevant content, then generate an answer grounded in it
Assuming RAG automatically solves permissions, freshness, or quality
Tool / action
Callable capability such as an API, connector, workflow, or function
Forgetting authorization, validation, and rollback behavior
Orchestration
Control logic that coordinates prompts, tools, memory, routing, and multi-step tasks
Letting an agent freely call tools without constraints
Human-in-the-loop
Human review, approval, or escalation before or during an action
Adding approval too late for high-risk actions
Prompt injection
Malicious or accidental instructions that try to override system behavior or exfiltrate data
Believing “ignore malicious instructions” is a complete defense
Evaluation
Measuring correctness, groundedness, task success, safety, cost, and latency
Testing only with happy-path demos
Observability
Logs, traces, metrics, and feedback used to operate the solution
Ignoring production monitoring after launch
Agent autonomy decision rules
The safest architecture usually gives the agent the minimum autonomy needed to create value.
If the action is irreversible, external-facing, financial, legal, safety-related, privacy-sensitive, or reputationally risky, design for human approval or strong deterministic controls.
Requirements analysis: what the architect must clarify
Scenario questions often include extra detail. Focus on the requirement that changes the architecture.
Requirement area
Questions to ask
Design implication
Business value
What KPI improves: cycle time, accuracy, cost, satisfaction, throughput?
Determines identity, channel, UX, and access model
Data
Which systems are authoritative? How fresh must data be?
Determines grounding, indexing, connectors, and sync strategy
Actions
Does the agent only answer, or can it modify systems?
Determines tool design, approvals, and audit needs
Risk
What can go wrong if the agent is wrong?
Determines autonomy, testing depth, and controls
Compliance
Are there privacy, retention, residency, or industry constraints?
Determines governance and data handling
Operations
Who owns, monitors, and updates the solution?
Determines ALM, telemetry, support, and change management
Choosing between knowledge, workflow, and agent patterns
Scenario clue
Prefer
Why
“Users need answers from internal documents”
Grounded knowledge copilot / RAG pattern
Retrieval and source grounding are central
“Users need a request submitted after a conversation”
Conversational agent plus workflow/action
Needs both natural language and system execution
“Every request follows fixed rules”
Deterministic workflow automation
Agent reasoning adds unnecessary risk
“Agent must plan across multiple systems”
Tool-using agent with orchestration
Requires state, tool selection, and error handling
“Business users must maintain conversation flows”
Low-code agent design
Maintainability by non-developers matters
“Developers need full control over models, evaluation, and deployment”
Custom Azure AI architecture
Flexibility, testing, and lifecycle control matter
Grounding and retrieval review
Grounding is central to enterprise agentic AI. The agent should use trusted sources instead of unsupported model knowledge when answering business-specific questions.
Retrieval design checklist
Design point
Good practice
Common mistake
Source selection
Use authoritative repositories and systems of record
Indexing outdated, duplicate, or unofficial files
Chunking
Split content into useful, semantically coherent units
Chunks too large to retrieve precisely or too small to preserve context
Metadata
Store labels such as owner, date, department, sensitivity, product, region
Failing to filter by region, role, or effective date
Permissions
Enforce user access at retrieval and response time
Returning content the user cannot access
Freshness
Define sync/index update requirements
Assuming indexed content is always current
Citations
Provide references where useful
Producing confident answers with no traceability
Fallback
Say when information is unavailable or uncertain
Forcing an answer when grounding fails
Notes and examples
RAG versus fine-tuning
Need
Better fit
Reason
Answer from changing enterprise documents
RAG / grounding
Easier to update content without retraining
Adapt style, format, or task behavior
Prompting or fine-tuning, depending on need
Behavior may not require retrieval
Add private facts to responses
RAG
Facts should remain in controlled data sources
Improve specialized output consistency
Prompt templates, examples, evaluation, or fine-tuning
Depends on volume, stability, and governance
Reduce hallucination about company policy
Grounded retrieval plus refusal/fallback behavior
Training alone does not guarantee current policy accuracy
Designing tool-using agents
Agents become business-critical when they can act. That increases value and risk.
Tool design principles
Principle
Why it matters
Narrow tool scope
Reduces damage from bad planning or malicious input
Explicit schemas
Improves reliability and validation
Idempotency
Prevents duplicate actions during retries
Confirmation steps
Protects high-impact operations
Error handling
Lets the agent recover or escalate gracefully
Auditability
Supports compliance, troubleshooting, and user trust
Rate limits and quotas
Protects downstream systems
Timeouts
Prevents long-running or stalled agent tasks
Rollback or compensation
Handles partial failure in multi-step workflows
Notes and examples
Tool-call decision path
flowchart TD
A[Agent wants to call a tool] --> B{Is the tool needed?}
B -- No --> C[Answer without action]
B -- Yes --> D{Is user authorized?}
D -- No --> E[Refuse or escalate]
D -- Yes --> F{Is action high risk?}
F -- Yes --> G[Request approval]
F -- No --> H[Validate inputs]
G --> H
H --> I{Validation passes?}
I -- No --> J[Ask clarification or stop]
I -- Yes --> K[Execute tool]
K --> L[Log result and report status]
Orchestration and multi-agent thinking
Not every problem needs multiple agents. The exam may describe complex workflows to test whether you can decompose responsibilities safely.
Pattern
Use when
Caution
Single agent
One primary user task, limited tools, clear context
Avoid overloading with unrelated responsibilities
Router pattern
Different tasks require different specialized flows or agents
Routing logic must be tested
Planner-executor
Agent plans steps and uses tools to complete them
Needs constraints, monitoring, and recovery
Human escalation
The agent cannot safely or confidently complete the task
Escalation path must be part of the design
Deterministic workflow plus AI step
AI is needed for summarization, classification, or drafting inside a stable process
Do not make the entire workflow probabilistic
Multi-agent collaboration
Distinct specialized roles improve quality or maintainability
More complexity, latency, cost, and testing burden
Prompt and instruction hierarchy review
Prompts are important but should not carry the entire architecture.
Prompt layer
Purpose
System/developer instructions
Define role, boundaries, policies, and response style
Grounding context
Supplies retrieved facts or task-specific data
User request
Describes the current user’s goal
Tool outputs
Provide results from external systems
Conversation history or memory
Preserves relevant context across turns
Prompt engineering traps
Hiding business rules only in a long prompt when they should be enforced by code, workflow, or policy.
Asking the model to “always be accurate” without grounding or evaluation.
Including sensitive credentials or secrets in prompt text.
Allowing retrieved documents to override higher-priority instructions.
Using one giant prompt instead of modular instructions, tools, and evaluation.
Evaluation: what to measure
A strong architect defines how the agent will be evaluated before full deployment.
Metric area
What it measures
Example evaluation method
Task success
Whether the agent completes the intended workflow
Test cases with expected outcomes
Groundedness
Whether answers are supported by retrieved sources
Compare response claims to source documents
Retrieval quality
Whether the right content is retrieved
Precision/recall review against known queries
Safety
Whether harmful, disallowed, or sensitive responses are blocked
Red-team prompts and policy tests
Tool accuracy
Whether tool calls use correct parameters and sequence
Simulated API tests and logs
Latency
How quickly the solution responds
Performance tests under realistic load
Cost
Token, compute, search, and workflow execution cost
Usage telemetry and budget thresholds
User satisfaction
Whether users trust and adopt the solution
Feedback, surveys, support tickets
Business impact
Whether the KPI improved
Before/after process metrics
Notes and examples
Evaluation traps
Testing only a few demo prompts.
Ignoring negative tests and adversarial prompts.
Measuring answer fluency instead of correctness.
Not testing permissions with different user roles.
Not retesting after prompt, model, data, or tool changes.
Failing to include real business edge cases.
Monitoring and operations
Production agentic AI requires continuous operation, not one-time deployment.
Operational concern
What to plan
Telemetry
Prompts, responses, retrievals, tool calls, latency, errors, user feedback
Versioning
Track changes to prompts, models, tools, indexes, and workflows
Rollback
Ability to revert a bad prompt, connector, index, or model change
Incident response
Process for unsafe output, data leakage, or failed actions
Cost management
Budgets, quotas, alerts, usage reporting
Model updates
Regression testing when model behavior changes
Content updates
Index refresh strategy and source ownership
Support model
Who handles failed sessions, escalations, and user issues
Governance
Review process for new agents, tools, connectors, and data sources
Scenario-based decision table
Use this table when a question asks for the “best” design.
If the question emphasizes…
Choose the answer that prioritizes…
Least custom development
Existing Microsoft copilot or low-code capabilities
Maximum control and custom AI lifecycle
Azure-based custom architecture and evaluation
Business-user ownership
Copilot Studio / low-code maintainability with governance
Enterprise data Q&A
Grounded retrieval with permissions and citations
Process execution
Tool/action integration with validation and approvals
User workflow fit, training, feedback, measurable value
Final readiness check
You are closer to exam-ready when you can explain why an architecture is appropriate, not just name the Microsoft service involved. Focus your final review on scenario tradeoffs: when to use an agent, how to ground it, how to constrain its actions, how to secure it, and how to prove it works.
Next step: use the AB-100 question bank for targeted topic drills, then complete mixed mock exams with detailed explanations to test whether you can apply these decision rules under exam-style pressure.