claude-architect-exam-guide: a community study guide for the Claude architect exam

One Markdown file is the source of truth

The repository is small and its structure explains why. The top level holds a README, an AGENTS.md and a CLAUDE.md, a LICENSE file, the guide itself at exam-preparation-guide.md, a publishing/ directory and a scripts/ directory. The documentation says plainly that the Markdown file remains the source of truth, while the files in publishing/ provide booklet metadata, front matter, PDF styling, EPUB styling and the cover image. That is a good arrangement for a document project, because there is exactly one file to edit and the rest is presentation. It also means the two things you can read are not the same thing. If you open the PDF from a release, you are reading a snapshot. If you open exam-preparation-guide.md on the default branch, you are reading whatever the last commit left there. The repository is written in Shell, which sounds odd for a study guide and is not, because the shell is what builds the booklets. The guide itself is teaching material, and the tooling around it is a small publication pipeline.

Eleven knowledge areas and the two things each section carries

The scope is the interesting part. The guide covers interconnected knowledge areas rather than a flat topic list, and the eleven of them run from API mechanics to workflow design. API fundamentals and output control covers stateless requests, tool choice, structured outputs and response prefill. Designing tool interfaces for LLM agents covers parameter design, structured output, tool composition and confirmation flows, and error handling in agent tools separates transient from permanent errors, structured error responses, uncertain state and MCP error patterns. Structured data extraction and validation covers schemas, nullability, semantic validation, provenance and human review. Conversation context management covers progressive summarization, state objects, retrieval and stale data handling. System prompt engineering covers structure, principles against conditionals, dilution and few-shot examples. The Model Context Protocol section covers tools, resources, prompts, the trust model, tool descriptions and configuration scopes. Agentic patterns covers prompt chaining, routing, orchestrator-workers, subagents and provenance. Customer service workflow design covers escalation, compliance enforcement, graceful degradation and handoff design. Claude Code and Agent SDK workflows covers built-in tools, plan mode, sessions, memory, slash commands and hooks. Evaluation and feedback loops covers validation, false-positive reduction, Message Batches and cost and latency trade-offs. Every section carries a What to Know block teaching the concepts and a Common Pitfalls block on misconceptions and subtle distinctions, and the guide adds a study strategy, a quick reference cheat sheet and recommended reading with links to official documentation.

No exam questions, and no affiliation with Anthropic

The disclaimer is the part of the README to read first, because it sets the boundary of what this artifact is. The guide is described as independent and community-created, not affiliated with, endorsed by, or sponsored by Anthropic. It states that no exam questions are included, paraphrased, or hinted at, and that the guide teaches the underlying knowledge domains only. That is a meaningful constraint on what you can expect. A study guide that contained real questions would be far more useful for recall practice, and this one deliberately is not that. It is a knowledge map, which suits someone who has never worked with LLM tooling and needs the vocabulary and the mental models in one place. It suits a reviewer less well, since the Common Pitfalls blocks are the closest thing to exam specific material and they are framed as conceptual distinctions rather than traps. The README also notes the guide was authored with assistance from Claude, which is worth keeping in mind when you weigh a section: you are reading a document partly written by a model, about building with models, and there is no editorial board.

Building the PDF and EPUB booklets with Pandoc

The publication step is a single script, and the tool requirements are stated precisely enough to reproduce it.

./scripts/build-release-assets.sh

The script writes its output to a dist/ directory. EPUB generation requires Pandoc, PDF generation additionally requires xelatex, and if rsvg-convert is on the path the EPUB cover is converted to PNG for broader reader compatibility. There is a versioning detail that matters if you build locally. Generated title pages use Version: dev for local test builds, while tagged releases use the tag name automatically, and you can override the displayed version with an environment variable.

RELEASE_VERSION=v1.0.0 ./scripts/build-release-assets.sh

So the build is reproducible enough to fork, and the release assets published from tagged releases come from this same pipeline rather than from a separate design tool. The published download formats are PDF and EPUB, which the README points to through the GitHub Releases page. There is no website and no hosted documentation, no npm package and no continuous integration described in the repository, so the booklets are the only distributable form and the Markdown is the only editable one.

Versioning, licence and how much to trust the branch

The release history is short and recent. v1.0.0 was tagged on 2026-05-16, v1.0.1 on 2026-05-26 and v1.1.0 on 2026-06-10, and the last push was on 2026-06-10, the same day as the newest tag. That means the default branch is currently close to the newest release, which is unusual and convenient for a document project, and it also means a future commit could move the branch away from any booklet you have already downloaded. On licensing, there is a discrepancy worth flagging rather than smoothing over. The README states the work is licensed under CC BY 4.0, free to share and adapt with attribution, and the LICENSE file in the repository is the place to confirm that. The repository's own metadata declares a custom licence that GitHub could not classify. Nothing in the documentation suggests the terms are unclear, but the correct approach for anyone reusing the text is to read the LICENSE file itself. Attribution to a community study guide, with no claim of vendor backing, is the practical requirement.

Where this guide is the wrong tool

There are three clear cases. First, an experienced LLM engineer. The README says the guide also serves as a focused review of the nuances the exam emphasises, but the coverage is deliberately broad and shallow, spanning eleven domains from structured output validation to Message Batches, and someone who builds these systems daily will spend most of the time skimming what they already know. Second, anyone hoping for question practice. The disclaimer rules it out explicitly, and no amount of reading will substitute for timed practice against real items. Third, anyone who needs the authoritative reference. The guide is a map of the domains, and the recommended reading section points to the official documentation, which is where the current and correct details live. A guide written by a community, partly with model assistance, and carrying no vendor endorsement, should be used for orientation and vocabulary, with the official documentation used to settle anything that matters. There is also a practical limitation of the format. A PDF booklet is a fixed snapshot with no search across the whole corpus beyond what the reader tool provides, and it will drift from the Markdown over time, so a reader who studied a PDF six months ago may be studying content that has since been revised in the source file.

Editorial conclusion

The guide suits a developer or solution architect who is new to LLM application work and wants one structured document covering the eleven knowledge areas the exam emphasises, including the pitfalls section that is the most useful part for review. It does not suit someone who has already built LLM systems and wants only the certification specific material, and it is not a substitute for the official documentation it links to. Before you rely on it, read the eleven domain headings in exam-preparation-guide.md and check which of them you already know, and note that the version printed in a booklet is fixed at release while the Markdown file keeps changing, with the last push on 2026-06-10 and the newest tag at v1.1.0 from the same day.

Frequently asked questions

Official sources

1. daronyondem/claude-architect-exam-guide on GitHub
2. Issues
3. README
4. Releases