Study guide

1. Agentic architecture & orchestration 27%

The biggest domain, and the one beginners most often get backwards. An agent, in this exam’s sense, is a loop: Claude reads context, decides on an action (call a tool, ask a question, or stop), the result is fed back in, and it repeats until the task is done. A deterministic workflow is the opposite instinct — you hard-code the steps and only let Claude fill in the reasoning inside each step.

The exam wants you to know when to choose which. Reach for a fixed workflow when the steps are known in advance and repeat the same way — it’s cheaper, faster, and easy to test. Reach for an agent loop only when the path genuinely can’t be known ahead of time — and know that buys nondeterminism, latency, and real dollar cost per retry.

• Multi-agent patterns: a lead agent that plans and delegates to narrower sub-agents does better on broad, parallelizable research tasks; a single agent with a big tool set does better when steps are tightly coupled and order-dependent.
• State preservation: anything that must survive a crash, restart, or context compaction needs to live outside the conversation — on disk, in a database, in a ticket.
• Human review integration: the exam rewards designs that put a person in the loop before irreversible or high-cost actions, not ones that maximize autonomy for its own sake.

2. Claude Code configuration & workflows 20%

This domain is about the concrete knobs Claude Code has, and picking the right one for a given audience. Instructions and permissions can live at several scopes, from “just me, just this repo” up to “everyone on this team, every repo.” The recurring theme is choosing the narrowest scope that reliably reaches the people who need it — not the broadest one available.

• CLAUDE.md files: project-level instructions checked into the repo versus user-level settings that are personal and don’t belong in version control.
• Commands and skills: reusable named procedures you invoke on demand, versus hooks, which fire automatically on an event whether or not anyone asked — hooks are the answer whenever a rule must never be skippable by a bad prompt.
• Permissions: the exam tests whether you’d grant broad standing access versus scoping a permission to exactly the tool and path a task needs, then re-evaluating it.
• Headless operation & CI/CD: running non-interactively raises the bar on what must be automatic — logging, exit codes, and failure alerts have to work with nobody watching.

3. Prompt engineering & structured output 20%

The core beginner mistake this domain probes for: treating a prompt as the only line of defense for getting a reliable, parseable answer out of a model. A system prompt with good examples raises the odds of correct-shaped output; it does not guarantee it. The exam wants the combination: clear instructions and examples plus a schema plus deterministic code that validates the actual response before anything downstream trusts it.

• System prompts and examples: a few well-chosen few-shot examples that show the exact output shape usually beat a longer paragraph of abstract rules.
• XML-style organization: wrapping distinct pieces of context in clearly-tagged sections helps Claude tell them apart — especially content from outside sources, which should never be confused with instructions.
• Output constraints and validation: ask for a schema, then check the response against it in code; on a mismatch, prefer a bounded retry with the validation error fed back over silently guessing.
• Decision boundaries: know where “just prompt it better” stops working and the fix becomes a tool, a schema, or a code-level check instead.

4. Tool design & MCP integration 18%

A tool is just a function Claude can choose to call — but the exam treats tool design, not just tool use, as its own skill. MCP (Model Context Protocol) is the standard way to package and expose capabilities to any compatible client, and it distinguishes three things beginners lump together: tools (actions with side effects), resources (read-only data the model can pull in), and prompts (reusable parameterized instruction templates).

• Naming and descriptions: a tool’s name and description are the only information Claude has to decide when to call it — vague names or overlapping tools cause wrong calls even with a perfect implementation.
• Input schemas: tight, specific schemas (enums over free strings where possible) cut malformed calls before they run.
• Output contracts: return something a model can reason from — structured, consistently-shaped results, not a raw dump that changes format with internal state.
• Failure behavior: a tool that fails should say so clearly rather than returning something that looks like success — “fails loudly and legibly” beats “fails silently.”
• Permissions per tool: scope what each tool can touch as narrowly as the task allows.

5. Context management & reliability 15%

The smallest domain by weight but the one that quietly underlies the others: a context window is finite, and everything you put in it competes for the same space and the model’s limited attention. The core distinction: durable state versus transient conversation — anything that must be true next week shouldn’t live only in this session’s chat history.

• Compaction: when a conversation gets long, older turns get summarized or dropped — this is lossy by design, so anything load-bearing must be re-derivable from what’s left.
• Retrieval: pull in only the specific slice of a large corpus relevant to the current step, not the whole set “just in case.”
• Prompt caching: reusing a stable prefix across calls cuts cost and latency — but only if that prefix genuinely doesn’t change, so put the stable part first and the variable part last.
• Escalation and confidence handling: a well-designed agent recognizes when it’s stuck and hands off to a human rather than guessing forward.