The 6 Scenario Contexts

3 min read index source

The 6 Scenario Contexts

The exam frames its questions around 6 recurring real-world scenarios. Every question lands in one of these contexts, so practice mapping each domain’s concepts onto each scenario. Know, for each one, the judgment calls it forces.

1. Customer Support Resolution Agent

First-contact resolution targeting 80%+ success. The core judgment: when to escalate vs. when to resolve autonomously.

  • Escalation triggers: user asks for a human, authority/exception needed, uncertain/unsafe state, no progress, policy breach.
  • Structured handoff payload: customer ID, issue type, root cause, relevant records, recommended action.
  • Hard rules (refund limits, authorization) enforced in tools/code, not prompts.
  • Handle frustrated users: acknowledge, resolve efficiently, preserve user choice.
  • Primarily exercises Domain 5; also Domains 2 and 4.

2. Claude Code Implementation

Configuring Claude Code for a team. The core judgment: what goes in CLAUDE.md vs. a slash command vs. a hook, and when plan mode adds value.

  • CLAUDE.md hierarchy and path scoping by file placement.
  • Slash commands for explicit shared workflows.
  • Plan mode for multi-file / architectural / migration work; direct for small edits.
  • Primarily exercises Domain 3.

3. Multi-Agent Research System

A coordinator delegating to specialized subagents. The core judgment: orchestration pattern choice and graceful partial-failure handling.

  • Coordinator does small work directly; delegates independent uniform work.
  • Subagents receive only explicitly passed context (task, findings, sources, constraints, output shape).
  • One failed subagent → return verified progress + pending items, don’t abort.
  • Provenance: claim + source ID + location + date + confidence.
  • Primarily exercises Domains 1 and 5.

4. Developer Productivity Tools

Built-in tools and MCP integration for code navigation. The core judgment: which built-in tool fits the task, and tool vs. resource in MCP.

  • Grep (contents) vs. Glob (filenames) vs. Read vs. Edit vs. Write vs. Bash vs. Task.
  • MCP servers for external code-navigation context; resources vs. tools.
  • Primarily exercises Domains 2 and 3.

5. Claude Code in CI/CD

Automated code review, test generation, PR feedback. The core judgment: output formatting and minimizing false positives.

  • A noisy automated reviewer gets ignored — tune for signal.
  • Headless/automated invocation patterns; structured output for PR comments.
  • Primarily exercises Domain 3; also Domain 4.

6. Structured Data Extraction

Parsing messy documents into schemas. The core judgment: schema design that prevents hallucination, and batch strategy.

  • Optional/nullable fields and absence semantics (null, empty array, unclear enum) to reduce fabrication.
  • Provenance fields; semantic validation beyond JSON Schema; correction loops with exact errors.
  • Staged extraction for long scattered docs; batch processing for volume.
  • Primarily exercises Domain 4.

How to drill these

For each scenario, ask yourself:

  1. Which domain’s concepts dominate here?
  2. What’s the single most common wrong answer the exam would offer? (Usually: a prompt instruction where code enforcement is needed, or over-automation where escalation/confirmation is needed.)
  3. Where does “responsibility assignment” land — model judgment vs. code enforcement?

Interview angle

  • “How do you approach a scenario question?” - name the constraint first (latency, cost, reversibility, compliance), then choose the architecture it implies, then say what you would measure to know it is working. Jumping to a tool or framework before the constraint is the weak answer.
  • “What separates a good answer from a complete one?” - the failure story. Anyone can describe the happy path; the signal is in what happens when a tool times out, the model returns malformed output, or a step half-succeeded and left external state changed.
  • “When do you say ‘this does not need an LLM’?” - whenever the rules are stable and expressible. Recognising that is a stronger answer than designing an elegant agent for a job a regex would do, and interviewers do plant those.