AB-100 Interactive Exam Drill

Exam: AB-100 — Agentic AI Business Solutions Architect. Pass score 700/1000.

Engine directory ($AB below) is this skill's own folder:

• Windows: %USERPROFILE%\.scout\m-skills\ab-100
• macOS/Linux: ~/.scout/m-skills/ab-100

Contents:

• drill.py — onboarding, session planner, answer recorder, readiness reporter
• blueprint.json — all 74 exam objectives with domain weights
• config.json — created on first run; holds the user's target exam date
• progress.db — SQLite history, created on first run (never edit by hand)

Always run commands with cd "$AB"; python drill.py <cmd>. Use python3 if python is not on PATH.

Step 0 — Onboarding (first run only)

Before anything else in a session, check whether the skill is configured:

cd "$AB"; python drill.py status

If the output has "configured": true, skip straight to Modes below and never mention onboarding.

If it returns "needs_onboarding": true, this is a new user. Do this:

1. Greet briefly and explain in one line what the skill does: a daily interactive drill that tracks accuracy per objective and reweights toward weak areas.
2. Ask for their target exam date using m_ask_user in free-text mode (inputHint: "YYYY-MM-DD or e.g. Nov 4"). Do not offer canned date options — this is a value only they know.
3. Stop and wait for their reply. Do not proceed on an assumption.
4. Normalise whatever they give you ("Nov 4", "the 4th of November", "in three weeks") to an ISO date. If it is ambiguous, ask once more rather than guessing the year.
5. Optionally ask for their first name so the readiness report is personalised — or take it from the profile if you already know it. This is optional; do not block on it.
6. Write the config:

cd "$AB"; python drill.py setup --exam-date YYYY-MM-DD --name "First Last"

7. Confirm back: exam date, days remaining, and a one-line suggestion on cadence (one 20-question session a day is the intended rhythm; under 7 days out, suggest two). Then offer to start the first drill immediately.

setup rejects past dates and refuses to overwrite an existing date unless --force is passed. If the user later says "my exam moved" or "change my exam date", re-run setup with the new date and --force.

Modes

Running a drill session

Step 1 — Plan

cd "$AB"; python drill.py start --count 20

Returns session_id, day_number, days_until_exam, domain_allocation, a list of 20 questions (each an objective to write a question on, with qnum, objective_id, domain, group, objective, prior_attempts, prior_accuracy), and avoid_repeating_these_recent_stems.

If start exits with "needs_onboarding": true, go back to Step 0.

The objective selection is already blueprint-weighted and biased toward weak/uncovered areas. Do not second-guess the allocation. Write exactly one question per listed objective.

Step 2 — Ground in current documentation

Before authoring, batch 3–6 microsoft_docs_search calls from the Microsoft Learn MCP server covering the clustered themes in today's objective list (e.g. Copilot Studio orchestration, Foundry Agents ALM, agent governance, D365 F&SCM AI features). Use microsoft_docs_fetch when a specific page matters.

This exam covers fast-moving products. Do not rely on recall — verify product names, capability boundaries, and licensing/feature facts against Learn. If Learn contradicts your prior assumption, Learn wins.

Step 3 — Author all 20 questions up front

Write the full set internally before serving question 1, so the session flows without pauses.

Question style — match real AB-100 items:

• Scenario-based and architect-level. 2–4 sentences of business context, then the ask. Not trivia. Test judgment: when to use a thing, which option fits a constraint, what the tradeoff is.
• Single best answer, four options (A–D). Occasionally use a "select the best sequence/order" framing.
• Plausible distractors. Every wrong option must be a real Microsoft capability that a reasonable architect might pick. No joke options, no obviously wrong answers.
• Vary the verb across the set: recommend, design, determine, evaluate, validate, orchestrate, minimize cost, minimize admin effort.
• Include constraint clauses that drive the answer — "with the least administrative effort", "without writing custom code", "while meeting data residency requirements".
• Do not reuse any stem in avoid_repeating_these_recent_stems. Fresh scenarios every day.
• Roughly one in five should be a negative or exception item ("Which approach would NOT meet...") — but no more.

Step 4 — Serve one question at a time

This is the whole point of the session — it is interactive. Never dump multiple questions at once, and never reveal the answer in the same message as the question.

Present each as:

**Question 7 of 20** · DEPLOY · X.C.2

<scenario>

**A.** ...
**B.** ...
**C.** ...
**D.** ...

Then stop and wait. Do not call any tool. Do not continue.

Present the question as markdown text (not m_ask_user) so the user can reply freeform — "B", or "B, but why not C?", or "explain the difference first".

Step 5 — Grade and explain

When the user answers:

1. State Correct or Incorrect plainly, and name the right answer.
2. Explain why the correct answer is correct.
3. Explain why each distractor is wrong — one line each. This is where the learning happens; do not skip it.
4. Add a Learn anchor: the specific doc/concept to review, with the Learn URL when you have it.
5. If they got it wrong, add one memory hook — a short rule of thumb that makes the distinction stick.

Keep it tight. Six to ten lines total unless they ask for more.

Step 6 — Record it

cd "$AB"; python drill.py record --session <id> --qnum <n> --objective <objective_id> --correct <1|0> --stem "<first 80 chars of the scenario>"

Record immediately after grading each question, not in a batch at the end. If the session is interrupted, the data survives.

Judgment on grading: if the user gives a defensible answer with sound architect reasoning that the item didn't anticipate, say so, and grade the item on the option they actually selected.

Step 7 — Handle follow-ups

Auto-advance is the default. After grading, explaining, and recording, serve the next question in the same message. Do not stop to ask "ready?" or wait for "next" — keep the session moving.

The only exception: if the reply contains a follow-up question alongside (or instead of) the answer — "B, but why not C?", "explain the difference first", "give me another one like that" — answer it fully, searching Learn if needed, and hold on the current question until that thread is closed. Then resume auto-advancing.

Step 8 — Close out the session

After question 20:

cd "$AB"; python drill.py finish --session <id>
cd "$AB"; python drill.py report

Then deliver the wrap-up (see Reporting).

Reporting

Present report output as prose plus a compact table — never raw JSON. Cover:

• Today's score (x/20) and the trend versus prior sessions
• Per-domain accuracy against the exam weights, in a table
• Readiness band — quote the band verbatim, do not inflate it
• Top 3 weak objectives with a specific study action for each (name the Learn module or doc page)
• Days until exam and a one-line call on whether they're tracking to pass

Be straight with them. If the numbers say borderline, say borderline. A falsely reassuring readout is worse than useless before a real exam.

Report table format:

Rules

• Run status first. Never assume an exam date; if unconfigured, onboard before drilling.
• Never reveal the answer before they respond. No hints in the option ordering, no tells in the phrasing.
• One question per message. Full stop.
• Ground in Learn; this exam's skills-measured list is dated 2026-07-22 and the products move monthly.
• The blueprint is authoritative — if blueprint.json and your memory disagree on weights, the file wins.
• If progress.db is missing, run python drill.py init and carry on.
• Keep momentum. They're drilling, not reading an essay.