Developer – Foundations

The facts

Criterion-referenced: you compete against a fixed standard, not against other candidates. The report gives you the total scaled score and the % correct per domain, but passing depends on the total alone.

Skill map: how many items each topic is worth

The 25 skills in the blueprint, ordered by weight, converted into expected items out of 53. The priority column is mine, not the guide's: it crosses the weight with what you already know from your day job.

1 · Claude Application Design — 8.6%, the heaviest skill

The objective literally speaks of "how Claude interprets instructions across interfaces, content boundaries, schema design, session hygiene and plugin management". There is no official page with that title: it is the examiner's synthesis of five separate areas. Here are the five.

How interpretation changes with the interface

• Raw API: there is no system prompt beyond your own, with one exception — if you send tools, the API automatically builds a system prompt containing the tool use instruction block, the JSON schemas, your system prompt and the tool configuration, in that order. It costs hundreds of tokens you did not write.
• If you include the memory tool, the API adds its memory protocol to the system prompt on its own. There is no need to resend it.
• claude.ai, mobile and desktop have their own system prompt (date, formatting, product behaviour) that does not apply to the API. Anthropic publishes it in full in its release notes.
• Agent SDK: three starting points — no system prompt (minimal, tool calling only), the Claude Code preset (the CLI's full prompt), or your own.

Content boundaries

Separate instructions, context, examples and variable input into their own XML tags, with consistent names. In long contexts (20k+ tokens): documents at the top, the question at the end — up to a 30% improvement in Anthropic's tests. And the hard rule you already know: third-party content goes only in tool_result blocks, never in the system prompt or in user text.

Schema design: the limits that get asked

Supported: basic types, scalar enum, const, anyOf, internal $ref, default, required, string formats. Not supported (400 if you use it): recursive schemas, external $ref, numeric constraints such as minimum/maximum, minLength/maxLength, and lookahead in pattern.

To reduce complexity, the official order is: mark only the critical tools strict → turn optionals into required (each optional almost doubles part of the state space) → flatten nesting → split across several requests or subagents.

Session hygiene

What survives compaction and what does not: the system prompt stays intact and the root CLAUDE.md is re-injected from disk; what is lost are the rules with paths: and the nested CLAUDE.md files, until a file that activates them is read again. The bodies of invoked skills are re-injected with a per-skill and total cap, discarding the oldest first.

And a recommendation that sounds counter-intuitive: it is often better to start clean than to compact, because the model can rebuild state from the filesystem if you give it a prescriptive opening ("check progress.txt, tests.json and the git log").

Plugins

A plugin is a self-contained directory with skills, agents, hooks, MCP servers and default settings. Only the manifest goes inside .claude-plugin/; the remaining folders live at the root. Four installation scopes: user (the default), project (shared via git), local (gitignored) and managed (read-only). Versioning is the cache key for updates, and it resolves in cascade: manifest version → marketplace version → commit SHA → digest → unknown.

2 · Claude through third parties — inside API Mechanics, 6.8%

The objective says "invoking Claude through third-party vendors". Today there are five platforms, not three, and the distinction most likely to be asked is who processes the data.

What changes in the code is only the client class and the authentication: client.messages.create(...) is identical.

Differences that come up

• Vertex: model does not go in the body (it goes in the URL) and, conversely, anthropic_version does go in the body. It is the most quotable format difference.
• Maximum request size: Bedrock 20 MB, Vertex 30 MB.
• Batch processing and data residency exist only in the Claude API and in Claude Platform on AWS. There are no Batches on Bedrock, Vertex or Foundry.
• Bedrock requires inference profiles for the newer models: invoking with the base model ID returns 400. Prefixes global., us., eu.…
• Global vs regional: regional routing guarantees residency and costs 10% more.

3 · Agentic frameworks — 4.9%

The blueprint names three explicitly: Strands, LangGraph and PydanticAI. You do not need to know how to program them; you need to know what each one is chosen for.

From LangGraph, two named concepts that lend themselves to a question: reducers (without a reducer, a node's update overwrites the state key) and the difference between checkpointer (snapshots of one thread, short-term memory, time travel) and store (key-value across threads, long-term memory). Checkpoints are saved at step boundaries, not mid-node, so on resume the node re-runs in full: nodes have to be idempotent.

Official product matrix

• Client SDK (Messages API): direct access, you implement the loop. Maximum control.
• Agent SDK: an agent without implementing the tool loop, running in your process.
• Claude Code CLI: interactive or one-off use in the terminal.
• Managed Agents: long, asynchronous agents without managing sandboxes or sessions. It is a separate product from the Agent SDK, with a hosted REST API.

4 · Deployment: self-hosted vs Anthropic-hosted — inside Agent Construction, 5.3%

The objective mentions "managed agent deployment models (self-hosted vs. Anthropic-hosted)". The exact distinction:

• Self-hosting the Agent SDK: the SDK spawns one subprocess per session with a shell, a working directory and transcripts on local disk. N sessions are N subprocesses. Local state does not survive restarts, so in production you need an external session store that mirrors the transcripts.
• Managed Agents (Anthropic-hosted): a prebuilt harness on managed infrastructure. Four concepts: Agent (model, prompt, tools), Environment (where it runs), Session (a running instance) and Events (history persisted server-side). Each session gets its own isolated sandbox.

There is a third, intermediate model: a self-hosted sandbox inside Managed Agents, where orchestration stays with Anthropic and only tool execution moves to your infrastructure. Mind the nuance: tool inputs and outputs still flow to Anthropic's control plane.

5 · The two "free" skills — 13.5% together

Software Engineering Foundations (7.4%) and Technical Fundamentals (6.1%) are not about Claude: they are about software engineering. REST and JSON, asynchronous programming, version control, integration into the development cycle, code review, refactoring at small and large scale, and SDKs that wrap REST APIs and websockets. That is seven items you already know how to answer; do not spend time here beyond a read-through.

Understanding Requirements (3.4%) and Systems Life Cycle (2.8%) are not Claude-technical either: functional and infrastructure requirements derived from business needs, and systems life cycle management. Answer with classic engineering judgement: requirements and acceptance criteria first, architecture second; and nothing reaches production without observability or a rollback plan.

6 · How the official module teaches it (and what that means for the items)

The module Production-grade prompting, Agents & tool use does not teach definitions: it teaches diagnosis. Every takeaway has the shape "this symptom means this technique is missing". Items are written against that mould, so the typical question will not be "what is X?" but "this is failing, what is missing?".

The diagnostic table you have to know cold

New figures and rules the module adds

• Exclusion condition: every tool description has to include a line saying when NOT to call it, written while designing the schema and not after the first failure shows up in a log. It is the sentence that resolves most wrong-tool bugs: two tools that both say "use it to search for information" are indistinguishable to Claude however different their schemas are.
• Tool outputs in production take 3 to 5 times more room than development fixtures. A session that holds up for 50 turns in testing can hit the ceiling at turn 8 once deployed.
• A connected MCP server spends context even if you never use its tools. The docs put a figure on it: a typical five-server setup consumes ~55,000 tokens in definitions before Claude does anything. Tool search cuts that by more than 85%.
• Image cost: ⌈width / 28⌉ × ⌈height / 28⌉ visual tokens — Claude sees 28×28 px patches, not pixels.
• Refactoring from in-context memory to external storage under production pressure costs an hour; taking the same decision deliberately at design time costs twenty minutes.

The image token ceiling is per tier, not per model

Images that exceed either of the two limits are rescaled automatically to the largest size that preserves the aspect ratio, which caps the cost. Padding to the next multiple of 28 px is then applied. A high-resolution image can cost around three times more than the same image on a standard-tier model, so run the formula against the largest input you expect in production, not against the ones in your test set.

Streaming: where the module and the documentation disagree

On the basics they agree, and this is what to walk in knowing: a block is only closed at its content_block_stop and the message only ends at message_stop. The deltas of a tool use are partial JSON strings: do not parse them until the block closes.

The four memory scopes, chosen by the shape of the session

Workflow or agent, in the module's formulation

Workflow when you can write the exact steps in code. Agent when you can specify the goal and the tools but not the path between them. Getting it wrong only shows in production: agents where a workflow would have done add context cost and behaviour that lives in transcripts; workflows where an agent was needed break on the first input that leaves the path.

Reasoning

Turn it on only where a reasoning pass changes the answer, and calibrate the effort to the problem rather than raising it on every call. Thinking blocks go back to the API unmodified or the next request fails. Mind the module's distinction: choosing which model to run is a separate topic from whether to turn reasoning on, and it is taught in an earlier module.

10-day plan

Ordered by weight, not by syllabus. Each day closes with a batch of cards on the topic, and the last three days are nothing but mock exams and mistakes.

The three official sample questions

They come from the guide. They do not come from the live bank, but they set the cognitive level: all are scenario-based and all are solved with a principle, not with memory.

The last 48 hours

• Review the numbers table and the version traps section. Almost all the memorisation lives there.
• Do a full pass of cards on the API and batch, Caching, Models and cost topics. Those are the ones with the most exact figures.
• One timed mock, not two. Resting pays more than a last-minute review.
• Get your ID ready with the name identical to the one on the registration, and clear your desk: no notes, phone, watch or second monitor.