Table of Contents

Click any entry to jump straight to it. You can also use the sidebar on the left at any time, filter chapters with the search box, and move with the ← / → arrow keys.

How to Use This Guide

One document, everything you need. This guide is written to be read start to finish like a book. No external course is required to use it, though pairing it with hands-on Claude API work is strongly recommended.

What this credential actually tests

The Claude Certified Architect Professional exam (CCAR-P) is not a trivia quiz about API parameters. It is written for the minimally qualified candidate (MQC): an experienced architect who can take a business problem, design a production-grade Claude solution for it, defend the trade-offs to stakeholders, and keep it safe, compliant, and observable once it ships. Every one of the 63 scored items on the real exam is written against a specific task statement in the official blueprint, so this guide is organized around that blueprint, domain by domain, task by task.

How the guide is organized

• Start Here (this section): how to use the guide, a 6-week study plan, and the full official exam blueprint and policies.
• Domains 1-7: one chapter per content domain, in blueprint order. Each chapter opens with the official task statements, then explains every one of them in depth with diagrams, tables, and worked examples, then closes with a "Key Takeaways" card you can use for rapid review.
• Practice Questions pages follow every domain chapter: 8 scenario-style items per domain (56 total) with click-to-reveal answers and rationale, written in the exact style and cognitive level of the real exam.
• Full-Length Practice Exam: 63 items, weighted to match the official blueprint percentages exactly (11/8/12/10/9/9/4), simulating the real exam end to end.
• Glossary and External Resources: a reference you can scan the night before the exam, plus links to official Anthropic documentation for deeper hands-on practice.

How to navigate

Use the left sidebar to jump to any chapter, or the Next / Previous buttons at the bottom of each page to move sequentially like a book. Your reading progress is tracked in the sidebar as you go. On mobile, tap the ☰ icon to open the chapter menu. Practice question answers are hidden by default: click ▸ Reveal answer to check yourself only after you've committed to a choice.

What you will NOT find here

No actual exam questions are reproduced anywhere in this guide. Doing so would violate the confidentiality agreement every candidate accepts before sitting the exam. Every sample and practice item here is original, written to match the blueprint's stated cognitive level and the style shown in the official guide's sample questions, not drawn from or reconstructed from the live item bank.

Six-Week Study Plan

Built for a working architect who can dedicate roughly 4-6 hours a week. Compress to three weeks by doubling up if you're already running Claude in production; stretch to ten weeks if you're newer to LLM systems.

Exam Blueprint & Policies

Summarized directly from the official Claude Certified Architect Professional Exam Guide (Version 1.0, effective July 2026, exam code CCAR-P). This is the authoritative scope of the exam. Everything else in this book is built to teach it.

Exam at a glance

Content domains and weights

Integration (19%) and Solution Design (17%) together make up more than a third of the exam: spend disproportionate study time on RAG design, connection protocols (MCP vs. API/CLI vs. agent-to-agent), and end-to-end architecture patterns.

Intended audience & minimally qualified candidate

This certification targets mid- to senior-level solution architects, AI/ML engineers, technical leads, and senior software engineers who own the full lifecycle of a Claude-based system: model selection, prompt/context engineering, tool and agent orchestration, and safety/compliance/governance, and who advise clients or internal stakeholders on architecture. It explicitly excludes entry-level developers, casual users, and roles limited to prompt writing without system design responsibility.

Recommended (not required) background: a foundation in software engineering best practices; 3+ years in systems architecture or platform engineering; 6+ months of hands-on production experience with Claude or comparable LLM systems; and experience delivering systems from discovery through operationalization. There are no mandatory prerequisites: the credential is awarded on exam performance alone.

Scoring & results

CCAR-P is criterion-referenced: you are measured against a fixed standard set by subject-matter experts, not ranked against other candidates. Your score report shows a pass/fail result, a scaled score (100-1,000, cut score 720), and the percentage of items you got right in each of the seven domains, useful for targeting a retake, but not itself the pass/fail determinant.

Conduct, retakes, and renewal

• Exams are closed-book: no notes, translation tools, or AI assistants are permitted.
• A government-issued photo ID matching your registration name is required.
• Failing candidates can retake after 14 days (1st fail), 30 days (2nd), or 90 days (3rd); max 4 attempts per exam per rolling 12 months, full fee each time.
• The credential is valid 12 months; renewing on time requires only a free, non-proctored assessment reviewing what changed since you certified. A lapsed credential requires the full exam again.

Claude Platform & API Essentials

The concrete product and API knowledge the domain chapters assume you already have. If you've built on Claude for six months this is review; if not, read it carefully. The exam expects you to reason about these specifics, not just concepts. Exact model names, prices, and limits evolve, so verify current figures in the official docs (links on the Resources page); the reasoning patterns are what the exam tests.

P.1 The Claude model family

Claude is a family of models spanning a capability / speed / cost spectrum. As of this guide's edition the current line-up is below. You are not expected to memorize prices to the cent, but you must be able to reason about the relative trade-offs and pick a tier for a scenario.

Rough per-million-token pricing at this edition (input / output): Haiku 4.5 ≈ $1 / $5; Sonnet 5 ≈ $3 / $15; Opus 4.8 ≈ $5 / $25; Fable 5 ≈ $10 / $50. The pattern that matters: each step up the capability ladder is roughly 2-5× the cost of the one below, which is exactly why routing high-volume/simple traffic to a smaller tier and reserving the top tier for hard cases is the dominant cost architecture. All current models are multimodal (text + image/PDF input, text output), multilingual, and available on the Claude API plus Amazon Bedrock, Google Cloud (Vertex AI), and Microsoft Foundry.

P.2 The Messages API

Every Claude interaction is a request to the Messages API. The core shape:

• system: the system prompt: role, reference material, guardrails, output-format rules (Domain 2). Sent once, separate from the turn-by-turn messages.
• messages: an ordered array of turns, each with a role of user or assistant, alternating. Content can be text, images, documents, tool-use, and tool-result blocks.
• max_tokens: the ceiling on output tokens for this response (counts toward the context window along with everything else).
• Statelessness: the API has no server-side memory of prior turns: you resend the full relevant conversation history on every request. This is why context management and prompt caching (below) matter so much.
• Stop reasons: each response reports why it ended: end_turn (natural completion), max_tokens (hit the output cap), tool_use (the model wants to call a tool), stop_sequence, or a refusal. Well-built systems branch on the stop reason rather than assuming completion.
• usage: every response reports input, output, and cache token counts: the raw material for cost and observability instrumentation (Domains 3-4).

P.3 Tool use (function calling) and the agent loop

Tools are how Claude acts on the world: the mechanism beneath every workflow and agent in Domain 1. The loop:

1. You send a request that includes a tools array. Each tool has a name, a description (prompt-engineer this like a docstring: it's how the model decides when to use it), and a JSON-Schema input_schema for its parameters.
2. If Claude decides to use a tool, it returns a tool_use content block (with the tool name and structured input) and a stop reason of tool_use.
3. Your code executes the tool and sends the result back as a tool_result block in a new user turn (referencing the tool_use ID). The model itself never runs your tools. It only requests them.
4. Claude incorporates the result and either answers or requests another tool. This repeat-until-done cycle is the agent loop.

Key details the exam may probe: Claude can request multiple tools in parallel in one turn when they're independent (reducing round-trips); tool_choice can force, allow, or forbid tool use; and tool definitions count toward the context window and toward capability bloat (Domain 3): every tool you expose costs tokens and adds a decision the model can get wrong. Well-designed tools follow the agent-computer-interface (ACI) principles from "Building Effective Agents": clear names, thorough descriptions with examples, and inputs designed so mistakes are hard to make (e.g., absolute over relative file paths).

P.4 Thinking, adaptive reasoning, and effort

Modern Claude models can allocate internal reasoning ("thinking") before answering, improving accuracy on multi-step problems at the cost of extra output tokens and latency:

• Extended thinking: an explicit, budgeted reasoning phase you enable, with a token budget that is a subset of max_tokens and billed as output tokens.
• Adaptive thinking: newer models allocate thinking dynamically per request, so usage varies with problem difficulty: no fixed budget to set.
• Effort: a parameter (e.g., on Opus 4.8 and Sonnet 5) controlling how much reasoning/work the model puts in; higher effort trades cost and latency for thoroughness. It defaults to high on several surfaces: set it explicitly to economize on simple tasks.
• Interleaved thinking: the model can think between tool calls, reasoning about each result before the next action: important for reliable agents.

Thinking tokens count toward the context window. When passing tool results back mid-cycle you must return the unmodified thinking block that accompanied the tool request (it carries a cryptographic signature); how long previous thinking blocks persist across turns is model-dependent.

P.5 Prompt caching mechanics

Caching (introduced conceptually in Domain 2) is the highest-ROI cost/latency lever. The mechanics you should know:

• What it does: marks a stable prompt prefix so repeated requests reuse the already-processed tokens instead of reprocessing them.
• Cost model: a cache write costs ~1.25× normal input (5-minute TTL) or ~2× (1-hour TTL); a cache read/hit costs ~0.1× normal input. So caching pays off whenever a prefix is reused more than a couple of times within its lifetime.
• TTL: 5 minutes by default (refreshed for free on each hit); a 1-hour option exists at higher write cost for prompts reused less often than every 5 minutes.
• Ordering & hierarchy: the cache covers the prefix in the order tools → system → messages. A change at any level invalidates that level and everything after it (e.g., editing a tool definition busts the entire cache).
• Breakpoint placement: put the cache boundary on the last block that stays identical across requests. Placing it on content that changes every request (a timestamp, the live user message) guarantees a permanent miss: the single most common caching mistake.
• Minimums: there is a minimum cacheable prefix length (varies by model, on the order of 1K-4K tokens); shorter prefixes are silently not cached. Verify via the usage cache fields.

P.6 Context management features

The context window is a finite, decaying working memory (Domain 2's "context rot"). Beyond curating what you put in it, the platform offers:

• 1M-token windows on Sonnet 5, Opus 4.8, and Fable 5 (200K on Haiku 4.5). More room is not automatically better. Accuracy still degrades as you fill it.
• Compaction: server-side summarization of earlier conversation so a long-running session can continue past the window limit without you hand-rolling summarization.
• Context editing: automatic clearing of stale tool results or thinking blocks to reclaim space in agentic loops.
• Context awareness: some models track their own remaining token budget during a task, so they can manage long work against the space that's left.
• Token counting: an API to estimate a request's token cost before sending it: use it to make deliberate trade-offs and avoid overflow (which returns a 400 "prompt is too long" if the input alone exceeds the window).

P.7 Retrieval building blocks (for RAG)

Domain 3 designs RAG pipelines; here are the components those designs are made of:

• Embeddings: vector representations of text capturing semantic meaning, so "reset my password" and "I can't log in" land near each other. Produced by an embedding model (Anthropic recommends third-party embedding providers; embeddings are not generated by the core Claude chat models themselves).
• Vector database / index: stores embeddings for fast nearest-neighbor (similarity) search, usually with metadata for filtering (date, document type, and, critically, access-control tags so retrieval respects the user's permissions).
• Dense (semantic) vs. sparse (lexical/keyword, e.g., BM25) search: semantic search for fuzzy natural-language matching; lexical for exact terms (SKUs, error codes, citations). Hybrid search combines both.
• Reranking: a second, more precise pass that reorders an initial broad candidate set to surface the truly most relevant chunks: the "recall then precision" two-stage pattern.
• Citations: a Claude API feature that ties generated claims back to specific source passages, directly supporting groundedness and the anti-hallucination controls in Domains 4-5.

P.8 MCP: the Model Context Protocol

MCP is the open standard for connecting AI applications to external tools and data ("USB-C for AI"). Its architecture (tested in Domain 3):

• Host: the AI application the user interacts with (e.g., Claude Desktop, an IDE, a custom app).
• Client: the connector inside the host that maintains a 1:1 connection to a server.
• Server: a program exposing capabilities over MCP: this is what you build or install to connect a data source or tool.
• Server primitives: tools (actions the model can invoke), resources (data/context the server can supply), and prompts (reusable prompt templates the server offers).
• Transports: local servers over stdio; remote servers over HTTP-based transport.

MCP's value is reusability: build one server and any MCP-compatible client can use it, versus writing bespoke glue per integration (direct API/CLI) or coordinating across trust boundaries (agent-to-agent). Because MCP servers can carry untrusted data into context and expose real actions, apply least-privilege scoping and prompt-injection defenses (Domain 5).

P.9 Skills, the Agent SDK, and Claude Code

• Agent Skills: packaged, reusable procedural knowledge (instructions, scripts, reference files) that Claude discovers and loads only when relevant: progressive disclosure that keeps context lean (Domains 2-3).
• Claude Agent SDK: Anthropic's framework for building custom agent harnesses (the loop, tool wiring, context/session management) without reinventing the plumbing, while still letting you see the underlying prompts, which "Building Effective Agents" stresses.
• Claude Code: the agentic coding tool that applies Claude inside a development workflow: reading a codebase, editing across files, running tests and commands under human oversight, and the reference point for Domain 7's developer-enablement objectives (shared config, permission boundaries, reusable Skills).

P.10 Supporting API features worth knowing

• Structured outputs: constrain responses to a JSON schema so downstream systems get reliably parseable output (fewer format-failure errors than free-text-plus-parsing).
• Batch API: asynchronous processing of large request volumes at a significant discount, for non-latency-sensitive workloads (bulk classification, offline evals), a key cost lever in Domain 4.
• Files API & PDF/vision support: upload and reference documents and images; a single request can include many pages/images up to request-size limits.
• Streaming: tokens returned incrementally for responsive UX; the first token's latency (TTFT) is what caching and pre-warming optimize.
• Deployment surfaces: Claude API, Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry, relevant to data-residency and compliance choices (Domain 5), since where the model runs affects which regulatory guarantees apply.

Solution Design & Architecture

The skill of turning a fuzzy business problem into a concrete, defensible system design, and choosing the simplest architecture that actually meets the requirement.

Official task statements

• Translate business problems into Claude-based AI solutions
• Design end-to-end architectures (input → processing → output → feedback loops)
• Select appropriate architectural patterns (workflow, agentic, augmented LLM)
• Design multi-agent systems and orchestration strategies
• Apply decomposition techniques for complex problem solving
• Align solutions to business value pillars (efficiency, transformation, productivity, cost, performance SLAs)

1.1 Translating business problems into solutions

Every architecture starts with a problem statement, not a technology choice. A recurring failure mode among junior architects is reaching for an agent when a single well-crafted prompt would do, or reaching for fine-tuning when better context engineering would do. The discipline is to work backward from the outcome:

1. What decision or output does a human currently produce, and what does "good" look like for it?
2. What information is required to produce that output, and where does it live today (documents, databases, APIs, tribal knowledge)?
3. What is the acceptable error rate and the cost of an error? A drafting assistant that occasionally needs a human edit tolerates far more risk than a system that auto-approves loan decisions.
4. What is the volume and latency requirement? Ten decisions a day tolerates a slow, expensive, heavily-reviewed pipeline; ten thousand a day does not.

Only after answering these should you pick a pattern. The Anthropic engineering guidance on agent design is blunt about this: "find the simplest solution possible, and only increase complexity when needed." Agentic systems trade latency and cost for flexibility. That trade only pays off when the task truly can't be predicted in advance.

1.2 End-to-end architecture: input → processing → output → feedback

Every production Claude system, no matter how simple or complex, can be described in four stages. Being able to draw and narrate this loop is one of the most commonly tested architecture skills:

A design that stops at "output" without a feedback mechanism is incomplete for this exam's purposes: Domain 4 (Evaluation) and Domain 6 (Lifecycle Management) both assume the feedback loop exists and is instrumented from day one, not bolted on later.

1.3 Architectural patterns: augmented LLM, workflow, and agent

Anthropic's own engineering guidance ("Building Effective Agents") draws a precise vocabulary that the exam expects you to use correctly. Get comfortable with the distinction between a workflow (LLM calls orchestrated through code you wrote) and an agent (the LLM decides its own next steps and tool calls in a loop).

The augmented LLM (the base building block)

A single Claude call enhanced with retrieval, tools, and memory. Most production use cases, a support macro generator, a document summarizer, a classification step, never need to go beyond this. Always ask whether an augmented LLM call, possibly with good in-context examples, already solves the problem before adding orchestration.

Workflow patterns (predefined code paths)

Agents (model-directed control flow)

An agent is an LLM that plans, calls tools based on environmental feedback (tool results, code execution output), and decides its own next step in a loop, typically until a stopping condition (task complete, max iterations, or a human checkpoint) is reached. Agents suit open-ended problems where the number of steps can't be predicted in advance and where you're willing to trust the model's judgment in a bounded, monitored environment. The cost is real: higher latency, higher token spend, and the possibility of compounding errors across many turns, which is exactly why Domains 4 and 5 (evaluation and guardrails) exist.

1.4 Multi-agent systems and orchestration strategies

When a single agent's context would grow too large, or when genuinely independent sub-domains of expertise are needed, multi-agent designs come into play. Two dominant shapes:

• Orchestrator (lead) + subagents: A lead agent decomposes the goal, dispatches focused subagents (each with its own tightly-scoped tools and context window), and synthesizes their results. This keeps each subagent's context clean and lets subagents run in parallel, at the cost of coordination overhead and the need to pass compact, well-structured handoffs rather than raw context.
• Peer-to-peer / agent-to-agent: Independent agents (potentially owned by different teams or organizations) communicate through a defined protocol rather than a shared orchestrator, useful when agents cross trust or organizational boundaries.

Multi-agent orchestration adds real cost. Every subagent call is billed independently, and coordination introduces new failure modes (a subagent stalling, conflicting subagent outputs, runaway recursive delegation). Justify multi-agent designs only when a single agent's context or tool surface would genuinely become unmanageable; otherwise a single well-tooled agent or a workflow is more reliable and cheaper.

1.5 Decomposition techniques for complex problems

Decomposition is the architect's core lever for controlling cost, latency, and reliability simultaneously. Useful techniques:

• Functional decomposition: split by capability (retrieve → reason → format) so each step can use the cheapest model and simplest prompt that satisfies it.
• Data decomposition: split a large input (a long document, a big dataset) into independently processable chunks, then merge: trades latency for parallelism and avoids context-window and context-rot problems.
• Confidence-gated escalation: attempt the cheap/fast path first (small model, short prompt); escalate to a larger model or human review only when confidence is low or stakes are high.
• Checkpointing: insert deterministic, code-based validation gates between LLM steps (schema validation, business-rule checks) so errors are caught before propagating downstream.

1.6 Aligning solutions to business value pillars

The exam expects architects to justify a design in business terms, not just technical ones. Learn to map every design decision to one or more of these pillars:

A strong architecture narrative states, explicitly, which pillar(s) the design optimizes for and which it consciously trades away. For example: "we chose Claude Haiku with a routing layer over a single large-model call because the SLA requires sub-second responses for 90% of traffic, accepting a small accuracy trade-off on the hardest 10% of cases, which we route to a slower, larger model."

Solution Design & Architecture

8 scenario-style items. Commit to an answer before revealing the rationale.

Claude Models, Prompting & Context Engineering

Choosing the right model, shaping its behavior, and managing the finite, decaying resource that is context.

Official task statements

• Select appropriate Claude models based on trade-offs
• Design system prompts, templates, and guardrails
• Apply prompt engineering techniques (zero-shot, few-shot, chain-of-thought)
• Optimize context windows and manage token usage
• Implement prompt reuse strategies (caching, modular prompts, Skills)

2.1 Model selection trade-offs

The current Claude model family (as of mid-2026) spans a clear capability/latency/cost spectrum. You do not need to memorize exact prices, but you must be able to reason about the trade-off axes:

The exam will not ask you to recite a price sheet, but it will ask you to reason like this: high volume + tight latency SLA + simple task → smallest capable model; low volume + high stakes + complex reasoning → largest capable model; mixed traffic → route between tiers. A common architecture is a router (Domain 1) that sends the bulk of easy traffic to Haiku and escalates ambiguous or high-stakes cases to Sonnet or Opus. The "efficient frontier" of cost vs. quality rarely lives at one single model choice.

Also weigh reasoning mode: modern Claude models support adaptive or extended thinking, which lets the model allocate more internal reasoning tokens to hard problems. This improves accuracy on multi-step reasoning at the cost of extra output tokens and latency: appropriate for complex planning or math-like tasks, wasteful for simple lookups.

2.2 System prompts, templates, and guardrails

The system prompt is the architectural control surface for a Claude application. A well-designed system prompt typically layers, in order:

1. Role and objective: what the assistant is for, in plain terms.
2. Static reference material: policies, product catalogs, tone guides (placed early and cached, see 2.5).
3. Behavioral guardrails: explicit instructions on refusals, escalation triggers, tone boundaries, and what the model must never do (e.g., "never promise a refund amount; always direct to a human for anything above $500").
4. Output format constraints: the exact structure downstream systems expect (JSON schema, a specific template), reducing parsing failures.

Templates (parameterized prompts with variable slots) let you standardize a family of related tasks, e.g., one template for "summarize document type X" reused across every document of that type, which both improves consistency and enables prompt caching (2.5).

2.3 Prompt engineering techniques

On current Claude models, structured reasoning is also available as a first-class capability (adaptive/extended thinking) rather than purely a prompting trick, but classic CoT prompting ("think through this step by step") remains useful for models or modes without that feature enabled, and for making the reasoning process auditable to reviewers.

2.4 Context window optimization and token management

The context window is a working-memory budget, not a place to dump everything you might conceivably need. Two facts anchor this domain:

• Context rot: accuracy and recall degrade as token count grows, even well within the nominal window limit. More context is not automatically better. Curating what's in context matters as much as how much room is available.
• Everything counts: the system prompt, every message (including tool results, images, documents), tool definitions, and the model's own output (including any thinking tokens) all count against the window.

Practical optimization levers:

• Summarization / compaction: periodically collapse older conversation turns into a compact summary rather than carrying full history forever, increasingly offered as a server-side feature so you don't have to hand-roll it.
• Context/tool-result editing: clear stale tool results or superseded intermediate outputs from context once they've served their purpose.
• Retrieval instead of stuffing: for large knowledge bases, retrieve only the relevant slice per request (see Domain 3's RAG content) instead of pasting entire corpora into every call.
• Token counting before sending: estimate token usage ahead of a request to stay within budget and to make deliberate trade-off decisions instead of discovering overflow at runtime.

2.5 Prompt reuse: caching, modular prompts, and Skills

Prompt caching is the single highest-leverage cost/latency lever an architect controls. By marking a stable prefix (system instructions, static reference documents, tool definitions) as cacheable, repeated requests reuse that already-processed prefix instead of reprocessing it from scratch: cutting both cost (cached reads are billed at a small fraction of fresh input tokens) and time-to-first-token. The design rule that matters most for the exam: place static content first and put the cache boundary on the last block that stays identical across the requests you want to share a cache: a boundary placed on content that changes every request (a timestamp, the live user message) never gets a cache hit and silently costs more, not less.

Modular prompts decompose a large instruction set into composable pieces (a core persona block, a task-specific block, an output-format block) that can be assembled per request: easier to maintain, test, and independently cache than one monolithic prompt string.

Skills package reusable procedural knowledge (instructions, scripts, and reference files) that Claude can discover and load only when relevant, rather than keeping every possible capability's instructions resident in context at all times. This is the same "progressive disclosure" principle covered in Domain 3's discussion of tool and context strategy: load capability on demand, not everything up front.

Models, Prompting & Context Engineering

8 scenario-style items. Commit to an answer before revealing the rationale.

Integration

Connecting Claude to real systems safely, efficiently, and observably: tools, retrieval, authentication, and protocol choice.

Official task statements

• Evaluate tool/agent configuration for capability bloat
• Analyze authentication and authorization requirements to identify security gaps
• Evaluate accuracy-latency trade-offs and justify configuration decisions
• Analyze observability challenges and select monitoring strategies at scale
• Design a RAG pipeline with appropriate chunking and indexing strategies
• Apply retrieval strategies matched to data shape and query pattern
• Evaluate connection protocols and select the appropriate integration mechanism (MCP, API/CLI, agent-to-agent)
• Evaluate progressive discovery vs. monolithic context strategy

3.1 Capability bloat in tool and agent configuration

Capability bloat is giving an agent more tools, permissions, or scope than the task requires. It causes three concrete problems: it enlarges the attack surface (Domain 5), it degrades tool-selection accuracy (the model must discriminate among more, often overlapping, tool definitions, and every extra tool definition also burns context tokens), and it increases the blast radius of any single failure or prompt injection. The corrective principle is least privilege: an agent should hold exactly the tools its task requires, no more. This is the same logic behind the official guide's own sample item: removing a refund/delete tool from a read-and-draft support agent eliminates the risk rather than merely monitoring it.

Practical checks for capability bloat: does every tool the agent can call actually get invoked in realistic task traces? Do multiple tools have overlapping, easily-confused purposes? Could two narrowly-scoped agents replace one broadly-scoped one?

3.2 Authentication and authorization gaps

Two distinct questions must both be answered for every integration: authentication (is this caller who it claims to be?) and authorization (is this caller allowed to do this specific thing?). Common architectural gaps to check for:

• Over-privileged service credentials: an agent or MCP server using a single admin-level API key/service account instead of a scoped credential matching only the actions it needs.
• Missing user-context propagation: a backend tool call that runs with the application's own broad permissions rather than the requesting end-user's actual permissions, silently letting a user access data or actions their own account shouldn't allow.
• Unauthenticated or weakly-authenticated tool/MCP endpoints: internal tools exposed without verifying the caller at all, trusting network location as a substitute for identity.
• No re-authorization at the action boundary: a multi-step agentic flow that authenticates once at the start of a session but never re-checks authorization before a sensitive downstream action (e.g., a refund) much later in a long-running agent loop.

The architecture answer is almost always to narrow scope and check identity/permission as close to the sensitive action as possible, not to add more logging around an over-broad permission (logging is a detective control, not a preventive one).

3.3 Accuracy-latency trade-offs

Every integration decision sits somewhere on an accuracy/latency/cost frontier, and the exam expects you to justify where you land, not just describe the options:

A defensible answer names the SLA or business constraint driving the choice: "we cap retrieval at the top-5 chunks and use Sonnet rather than Opus because the product requires sub-2-second responses, and our eval set shows accuracy plateaus past 5 chunks for this corpus."

3.4 Observability at scale

A handful of manually-reviewed transcripts is not observability once a system handles meaningful production volume. Architect for:

• Structured logging of every request/response pair, including token usage, latency, tool calls made, and any guardrail triggers: sufficient to reconstruct any single production incident after the fact.
• Sampling-based human review at a statistically meaningful rate, stratified by risk (review 100% of high-stakes actions like refunds; sample 1-5% of routine chat).
• Automated quality signals running continuously in production, not just pre-launch: reference-free evals, guardrail trigger rates, escalation rates, and user feedback (thumbs up/down, edit rates).
• Drift detection: alerting when quality signals, latency, or cost move outside historical bounds, since a silent regression (e.g., after a document refresh breaks a RAG index) is far more common than a loud outage.
• Cache/tool diagnostics: tracking cache hit rates and tool-call success/error rates as first-class operational metrics, not just an afterthought.

3.5 Designing a RAG pipeline: chunking and indexing

Retrieval-augmented generation grounds Claude's answers in a specific corpus rather than relying purely on parametric knowledge. A RAG pipeline has five stages, and the exam probes judgment at each:

1. Ingestion: parsing source documents (PDFs, wikis, tickets, code) into clean text, preserving structure (headings, tables) where it carries meaning.
2. Chunking: splitting documents into retrievable units. Chunk size is a trade-off: too small loses surrounding context needed to answer correctly; too large dilutes relevance and wastes tokens once retrieved. Match the strategy to the content: fixed-size chunking is simple but naively cuts across sentence and section boundaries; semantic/structural chunking (split at headings, paragraphs, or logical document sections) usually retrieves more coherent, self-contained units for policy documents, contracts, and technical docs.
3. Embedding: converting chunks into vectors capturing semantic meaning.
4. Indexing: storing vectors (and often metadata for filtering: date, document type, access-control tags) in a retrievable index. Access-control metadata at index time is what lets retrieval respect the same permissions the end user has in the source system, a frequent, easily-missed security gap (see 3.2).
5. Retrieval + generation: at query time, embed the query, retrieve the top-k most relevant chunks (often re-ranked), and pass them to Claude alongside the user's question.

3.6 Retrieval strategies matched to data shape and query pattern

A recurring exam trap: defaulting to vector search for everything. When the underlying data is genuinely structured (a transactional database) or requires exact-match precision (a part number), a direct query or lexical search beats semantic embedding search on both accuracy and cost.

3.7 Connection protocols: MCP vs. direct API/CLI vs. agent-to-agent

Choosing among these is a real architecture decision, not a stylistic one: MCP buys you reusability and a growing ecosystem at the cost of a standardization layer; direct integration buys you simplicity and control for a narrow, stable use case; agent-to-agent buys you decentralization where no single party can or should own the whole orchestration.

3.8 Progressive discovery vs. monolithic context strategy

When an agent has access to many tools, data sources, or Skills, there are two opposing strategies for exposing them:

• Monolithic context: load every tool definition, every reference document, every possible instruction into context up front, for every request. Simple to reason about, but wastes tokens (and money, and latency) on capability the current task never touches, and increases the chance the model gets confused among many similar options (see capability bloat, 3.1).
• Progressive discovery: expose a small, high-level directory of available capabilities (e.g., a tool-search mechanism or Skill index), and let the model request more detail only for the specific tool/Skill/document it decides it needs, when it needs it. This scales far better as the number of available tools/Skills grows into the dozens or hundreds, keeping the resident context small and focused.

The exam heuristic: small, stable tool count → monolithic is fine and simpler; large or growing tool/Skill catalog → progressive discovery is required to avoid both context bloat and tool-selection errors.

Integration

8 scenario-style items. Commit to an answer before revealing the rationale.

Evaluation, Testing & Optimization

Proving a system works, catching regressions before users do, and diagnosing failures correctly instead of guessing.

Official task statements

• Define evaluation metrics (accuracy, latency, cost, safety, security)
• Design evaluation datasets and test frameworks using mixed methodologies
• Conduct A/B testing and iterative improvements
• Diagnose system issues (prompt failure, hallucinations, model mismatch)
• Optimize token usage, latency, and cost-performance trade-offs
• Monitor system performance using logging and observability tools

4.1 Defining evaluation metrics

"Is it good?" is not a metric. A production-ready eval plan states, per use case, concrete measurable targets across at least five dimensions:

Define the target and the floor for each metric before building. Otherwise "better" has no fixed meaning and every stakeholder will argue from a different implicit bar.

Quantitative metrics you should be able to name

For classification and extraction tasks, know the standard information-retrieval quartet, because "accuracy" alone is misleading on imbalanced data:

• Precision: of the items the system flagged/returned, what fraction were correct. High precision = few false positives.
• Recall: of the items it should have flagged/returned, what fraction it actually caught. High recall = few false negatives.
• F1: the harmonic mean of precision and recall, used when you need a single number balancing both.
• Accuracy: fraction of all predictions that were correct; unreliable when classes are imbalanced (a "always say no fraud" model is 99% accurate on data that's 1% fraud, yet useless).

For RAG retrieval quality specifically, evaluate the retrieval step separately from generation: precision@k / recall@k (are the right chunks in the top-k?) and groundedness / faithfulness (does the generated answer actually follow from the retrieved chunks, with no fabricated additions?) plus answer relevance (does it address the question?). Diagnosing RAG failures means asking which of these three broke: retrieval (wrong chunks), grounding (right chunks, invented answer), or relevance (correct but off-topic).

A worked cost calculation

4.2 Evaluation datasets and mixed-methodology test frameworks

A single evaluation technique is rarely sufficient. Combine at least these three methodologies:

• Golden-set exact/graded evaluation: a curated set of representative inputs with known-correct (or expert-graded) outputs, run automatically on every change. Should include both common cases and known hard edge cases.
• Model-graded evaluation ("LLM-as-judge"): using a separate Claude call to grade open-ended outputs against a rubric, at a scale human grading can't match: useful for catching subtler quality regressions, though it must itself be validated periodically against human judgment to confirm it isn't drifting or biased.
• Human evaluation: expert or end-user review, essential for subjective quality, tone, and edge cases automated grading misses, usually applied via sampling rather than to every output.

Datasets should be built from real production traffic wherever possible (not only synthetic examples), refreshed as the product and corpus evolve, and explicitly include adversarial/edge cases (ambiguous questions, out-of-scope requests, known prior failure modes), not only "happy path" examples.

4.3 A/B testing and iterative improvement

Before shipping a prompt, model, or retrieval change to 100% of traffic, run a controlled comparison:

1. Define the primary metric the change is meant to move (e.g., resolution rate) and guardrail metrics that must not regress (e.g., safety trigger rate, latency).
2. Split traffic (or run the golden set through both variants) with a large enough sample to detect a meaningful difference. Small qualitative "it feels better" comparisons are not sufficient evidence for production changes at scale.
3. Ship the winner only if the primary metric improves without regressing guardrail metrics; if it's ambiguous, gather more data rather than deciding on vibes.
4. Treat every production system as a loop, not a one-time launch: keep measuring after shipping, since real-world traffic drifts from any pre-launch test set over time.

4.4 Diagnosing system issues

The exam repeatedly tests whether you can correctly localize a failure to the right layer instead of guessing. A useful diagnostic order:

Notice the pattern: three of the most common wrong first guesses on the real exam are blaming the model itself (temperature, "the weights changed") when the actual fault is in retrieval, prompt structure, or configuration. Always ask what specifically changed at the time the symptom appeared.

4.5 Optimizing token usage, latency, and cost-performance

Optimization is not "make it cheaper" in isolation. It's finding the best point on the cost/latency/accuracy frontier for the specific SLA. Levers, cheapest first:

• Enable prompt caching correctly (Domain 2): usually the single highest-ROI lever with zero accuracy cost.
• Right-size the model per request via routing rather than using one model for all traffic.
• Trim retrieved context to the eval-validated minimum rather than "more is safer."
• Batch non-latency-sensitive work (e.g., offline analysis, and Anthropic's Message Batches API for asynchronous workloads) instead of paying for synchronous, real-time pricing where a delay is acceptable.
• Only reach for extended/adaptive thinking, multi-call voting, or larger models where evals show they actually move the accuracy metric that matters, otherwise they're pure cost with no benefit.

4.6 Monitoring with logging and observability tooling

Continuous production monitoring (distinct from one-time pre-launch evaluation) should track the same five metric dimensions from 4.1 on a live dashboard, with alerting thresholds and clear ownership for who responds when a threshold is breached. Treat evaluation as a lifecycle activity: pre-launch (does it meet the bar to ship?), continuous (is it still meeting the bar in production?), and triggered (did a change, such as a document refresh, a model upgrade, or a new prompt version, introduce a regression?).

Evaluation, Testing & Optimization

8 scenario-style items. Commit to an answer before revealing the rationale.

Governance, Safety & Risk Management

Keeping a Claude system safe, compliant, and defensible: before, during, and after it ships.

Official task statements

• Implement guardrails and safety controls
• Identify risks, limitations, and failure modes of LLM systems
• Apply human-in-the-loop validation strategies
• Ensure compliance with regulations (e.g., GDPR, HIPAA, FedRAMP)
• Address ethical AI considerations (bias, fairness, transparency)

5.1 Guardrails and safety controls

Guardrails belong at multiple layers, and a mature design uses several simultaneously rather than relying on any single one:

The recurring exam principle: removal beats detection, and detection beats nothing. Preventing a capability from existing is stronger than logging or flagging its misuse after the fact.

5.2 Risks, limitations, and failure modes of LLM systems

• Hallucination: confident generation of false or unverifiable claims, especially outside the model's grounded context or reliable knowledge.
• Prompt injection: malicious instructions hidden in retrieved documents, tool outputs, or user input that attempt to override the system's intended behavior: a particular risk whenever an agent processes untrusted external content (web pages, emails, documents) as part of its context.
• Excessive agency: an agent taking actions beyond what a task actually required, especially in multi-step autonomous loops without sufficient checkpoints.
• Data leakage: sensitive information from one user's context, retrieved documents, or training surfacing inappropriately in another user's session or output.
• Model/knowledge drift: a system's behavior or accuracy shifting after a silent upstream change: a model version update, a data refresh, or a prompt edit made elsewhere.
• Bias amplification: the system systematically producing worse or unfair outcomes for particular groups, whether from training data patterns, biased retrieval corpora, or unrepresentative eval sets that failed to catch it.

5.3 Human-in-the-loop (HITL) validation strategies

Not every action needs a human in the loop, and requiring one for everything defeats the purpose of automation. Calibrate HITL to risk:

Design HITL checkpoints at the point of irreversible or high-consequence action, not merely at the start of a session: a long-running agent that was approved to begin a task is not thereby pre-approved for every downstream action it might decide to take.

5.4 Regulatory compliance

You are not expected to be a lawyer, but you must recognize which regulatory regime is triggered by a given scenario and what architectural implication follows:

The consistent exam pattern: identify which regulated data type or sector a scenario involves (health data → HIPAA, EU citizens' personal data → GDPR, US federal agency → FedRAMP), then pick the option that reduces unnecessary data exposure, adds required access controls/audit trails, or uses an appropriately accredited environment, not the option that merely adds disclaimers or ignores the regime because "the model is just giving information."

5.5 Ethical AI: bias, fairness, and transparency

• Bias: actively test outputs across demographic and use-case slices, not just aggregate accuracy: a system can look accurate on average while performing far worse for a specific subgroup.
• Fairness: define, with stakeholders, what fair treatment means for the specific use case (equal outcomes vs. equal treatment vs. equal opportunity can conflict), and pick an explicit standard rather than leaving it implicit.
• Transparency: disclose to end users when they are interacting with an AI system, what data it uses, and its known limitations, especially in consequential domains (hiring, lending, healthcare, legal). Maintain internal documentation of model choice, guardrails, and known failure modes so decisions are auditable after the fact.

Governance, Safety & Risk Management

8 scenario-style items. Commit to an answer before revealing the rationale.

Stakeholder Communication & Lifecycle Management

The architect as translator: between business needs and technical trade-offs, and across the full life of a system, not just its launch.

Official task statements

• Conduct structured discovery and requirement gathering
• Communicate architectural decisions and trade-offs
• Manage stakeholder feedback loops and expectation alignment (including SLAs)
• Document architectures and provide implementation guidance
• Support lifecycle phases (discovery, design, handoff, monitoring, iteration)

6.1 Structured discovery and requirement gathering

Discovery is where most project risk is created or avoided. A structured discovery covers, at minimum:

• Business objective and success metric: tied to a specific value pillar (Domain 1): what number moves, and by how much, if this succeeds?
• Current-state process: who does this today, how long does it take, what's the error rate now (the baseline any new system must beat)?
• Data inventory: where does needed information live, who owns it, what's its quality and access-control status?
• Constraints: regulatory (Domain 5), budget, existing technology commitments, timeline.
• Risk tolerance: what does an acceptable error look like, and what does an unacceptable one look like, for this specific use case?

Skipping structured discovery is the single most common root cause of a project that technically "works" but fails to deliver the value the stakeholder actually wanted.

6.2 Communicating architectural decisions and trade-offs

Non-technical stakeholders don't need implementation detail; they need to understand what a decision costs them and why it was made. A reliable structure for any architecture decision record (ADR):

1. Context: what problem or constraint prompted this decision.
2. Options considered: at least two real alternatives, not a strawman.
3. Decision: what was chosen.
4. Trade-offs accepted: stated explicitly, in business terms ("we accept slightly higher cost per request in exchange for a 99.9% latency SLA the business requires").
5. Reversibility: how hard would it be to change this decision later if requirements shift?

The exam frequently probes whether you default to jargon or to plain, decision-relevant language when a scenario describes presenting to an executive or non-technical client.

6.3 Managing stakeholder feedback loops and SLA alignment

Expectation misalignment, not technical failure, is the most common reason engagements sour. Concrete practices:

• Put SLAs (latency, accuracy floor, uptime) in writing and tie them to the same metrics used in Domain 4's evaluation framework: don't let "fast" or "accurate" remain undefined between the team and the client.
• Establish a recurring, structured feedback cadence (not just ad hoc escalations) so stakeholders see progress and can flag concerns early, before they compound.
• When a stakeholder request conflicts with sound architecture (an unnecessary multi-agent system, an unrealistic accuracy guarantee), address it directly with trade-off language rather than silently complying or silently ignoring it.
• Manage scope creep explicitly: every new requirement discovered mid-project should be evaluated against the original success metric and constraints, not simply absorbed.

6.4 Documenting architectures and implementation guidance

Documentation that only the original architect can use has failed its purpose. A complete architecture package typically includes:

• A system diagram showing the four-stage loop (Domain 1: input, processing, output, feedback) and every external integration.
• The rationale for model, prompt, and retrieval choices (so a future engineer doesn't "optimize" away a deliberate trade-off without understanding why it was made).
• Guardrail and compliance controls in place, and why (Domain 5), for audit and handoff purposes.
• Evaluation results and the metric definitions used to approve the system for launch (Domain 4).
• Runbooks: what to check first when something breaks, who owns what, and how to roll back a change.

6.5 Lifecycle phases: discovery → design → handoff → monitoring → iteration

A system architecture is never "done" at launch. The exam expects you to treat monitoring and iteration as designed-for phases, not an afterthought that happens only if something breaks loudly.

Stakeholder Communication & Lifecycle Management

8 scenario-style items. Commit to an answer before revealing the rationale.

Developer Productivity & Operational Enablement

Making the humans building and running the system faster and less error-prone: the smallest domain by weight, but a real differentiator for an architect advising a delivery team.

Official task statements

• Configure Claude tools and environments for teams (e.g., Claude Code)
• Improve developer workflows using AI-assisted tooling
• Support debugging and operational issue resolution

7.1 Configuring Claude tools and environments for teams

Agentic coding tools such as Claude Code let a team apply Claude directly inside their development workflow: reading a codebase, making multi-file edits, running tests, and executing shell commands under human oversight. Architecting this for a team (not just an individual) involves:

• Shared configuration: standardized project-level instructions (a checked-in configuration file describing conventions, architecture, and constraints) so every developer's AI-assisted sessions follow the same house rules rather than reinventing them per person.
• Permission boundaries: scoping what actions an agentic coding tool may take autonomously (read files, run tests) versus what requires explicit developer approval (destructive commands, pushing to production branches), the same least-privilege principle from Domain 3, applied to developer tooling.
• Reusable team knowledge: packaging common, repeated procedures (a deployment checklist, a code-review rubric, a scaffolding pattern) as reusable Skills or templates so the whole team benefits from one well-tested procedure instead of each engineer improvising their own prompt.
• Plugin/extension governance: when a team adopts bundles of tools, connectors, and skills as installable packages, apply the same review discipline you'd apply to any new production dependency: provenance, scope, and update process.

7.2 Improving developer workflows with AI-assisted tooling

Beyond individual productivity, the architect's job is to identify where AI-assisted tooling changes the shape of a workflow, not just its speed:

• Faster iteration on boilerplate and scaffolding, freeing engineer time for the judgment-heavy parts of a task.
• Code review augmentation: a first automated pass catching obvious issues (style, common bugs, missing tests) before a human reviewer's time is spent, without replacing human review for architectural and business-logic correctness.
• Documentation-as-you-go: generating and keeping documentation in sync with code changes, addressing the chronic problem of documentation drifting out of date.
• Onboarding acceleration: new engineers using AI-assisted tools to understand an unfamiliar codebase faster than reading it cold.

The consistent theme, echoed from Domain 1: apply the same "start simple, add complexity only when justified" discipline to developer tooling adoption: measure whether a given AI-assisted workflow change actually reduces cycle time or defect rate before standardizing it team-wide.

7.3 Supporting debugging and operational issue resolution

The same architect who designs the system should make it fast to debug when it breaks. Practical patterns:

• Reproducible traces: every production incident should be reconstructable from logs (Domain 3's observability practices): the exact prompt, retrieved context, tool calls, and model version involved.
• AI-assisted root-causing: using Claude itself (with appropriate access to logs and code) to accelerate the same diagnostic process from Domain 4: narrowing down whether a regression traces to retrieval, prompt, or model/config change, while a human still makes the final call on production fixes.
• Runbooks over tribal knowledge: operational procedures documented and kept current (Domain 6) rather than living only in one engineer's memory.
• Fast rollback paths: any prompt, model, or configuration change should be revertible quickly once a regression is detected, not require a full redeploy cycle.

Developer Productivity & Operational Enablement

6 scenario-style items. Commit to an answer before revealing the rationale.

Full-Length Practice Exam

63 items, weighted exactly to the official blueprint (11 / 8 / 12 / 10 / 9 / 9 / 4 across Domains 1-7). Set a 120-minute timer, answer on paper or in your head, then turn to the Answer Key & Rationale page to score yourself. Do not peek early. The value of a mock exam depends on honest timing pressure.

Domain 1: Solution Design & Architecture (Items 1-11)

1. A mid-size airline wants Claude to answer "where is my luggage" questions using live baggage-tracking data. Volume is high, latency must be near-instant, and the task is narrow and repetitive. Which pattern fits best?

1. Multi-agent orchestrator with five subagents
2. An augmented LLM call with a tool that queries the live baggage system
3. An autonomous agent free to take any action on the airline's systems
4. A prompt-chaining pipeline with five sequential drafting steps

2. Which best distinguishes a workflow from an agent?

1. Workflows never call tools
2. Workflows follow developer-defined code paths; agents let the model direct its own steps and tool use
3. Agents are always cheaper to run
4. Workflows only work with the smallest models

3. A customer-support pipeline needs a draft written, then automatically checked against a compliance rubric, then rewritten if it fails. Which pattern is the closest fit?

1. Routing
2. Evaluator-optimizer
3. Simple augmented LLM with no additional steps
4. Voting across five identical prompts

4. A leadership team wants "efficiency gains" from a new Claude system but cannot articulate a number. What should the architect do first?

1. Proceed with the build and infer the metric later
2. Work with stakeholders to define a concrete, measurable efficiency metric tied to the current-state baseline
3. Assume cost reduction is always the intended metric
4. Skip metric definition since "efficiency" is self-evident

5. Which scenario most clearly justifies an agent over a workflow?

1. A fixed three-step approval process with known steps in advance
2. An open-ended research task where the number and nature of needed steps can't be predicted ahead of time
3. A single classification call
4. A static document translation task

6. A design decomposes a large invoice-processing task into: (1) extract fields, (2) validate against business rules in code, (3) generate a summary. What technique is this?

1. Voting
2. Functional decomposition with a deterministic validation checkpoint
3. Agent-to-agent negotiation
4. Monolithic context loading

7. Select two. Which two are legitimate engineering justifications for a multi-agent design rather than a single agent?

1. The task decomposes into independent sub-domains that would overload one agent's context/tools
2. A stakeholder wants to see "agents" mentioned in the proposal
3. Independent subtasks can run in parallel, meaningfully reducing latency
4. It matches a trend seen in an unrelated case study

8. A design has clear input handling and a well-tooled processing stage, but no mechanism for learning whether outputs were actually correct after delivery. What is missing?

1. A bigger model
2. A feedback loop connecting outcomes back into evaluation and iteration
3. More few-shot examples
4. A second output format

9. "Same team of analysts, able to cover triple the client portfolios" describes which business value pillar?

1. Cost reduction
2. Productivity amplification
3. Transformation
4. SLA compliance

10. A stakeholder insists on the most complex architecture available "to be safe," for a task that is simple and predictable. What is the architect's best move?

1. Comply without comment
2. Recommend the simplest architecture that meets requirements, explaining the cost/reliability trade-offs of unnecessary complexity
3. Build the complex version and a simple version in parallel indefinitely
4. Disengage from the project

11. Which best describes the "augmented LLM" building block?

1. A single Claude call enhanced with retrieval, tools, and/or memory
2. A network of five or more coordinated agents
3. A model that has been fine-tuned exclusively
4. A workflow that never uses tools

Domain 2: Models, Prompting & Context Engineering (Items 12-19)

12. A high-volume, sub-second-latency ticket classifier with a clearly-bounded label set should default to which model tier?

1. The largest, slowest available model for every request
2. The fastest, smallest capable model, with escalation for low-confidence cases
3. A model with the largest possible context window regardless of task size
4. Whichever model is newest, regardless of fit

13. A prompt must reliably produce a very specific JSON structure the model doesn't produce by default. Which technique addresses this most directly?

1. Zero-shot instruction only
2. Few-shot examples demonstrating the exact target structure
3. Lowering max_tokens
4. Disabling tool use

14. As a multi-turn agent conversation grows, output quality degrades well before the nominal context limit is reached. What is this called, and what best mitigates it?

1. Rate limiting; mitigate by increasing quota
2. Context rot; mitigate with summarization/compaction and removal of stale content
3. Cache invalidation; mitigate by disabling caching
4. Model deprecation; mitigate by pinning a model ID

15. A team places its prompt-caching breakpoint immediately after the unique, per-request user question rather than after the static system prompt. What results?

1. Optimal caching performance
2. Near-zero cache hit rate, since the breakpoint sits on content that changes every request
3. Automatically higher accuracy
4. No effect either way

16. Which best describes "Skills" from a context-management perspective?

1. They force all procedural instructions to load on every request
2. They allow procedural knowledge to be discovered and loaded only when relevant to the current task
3. They are a replacement for system prompts in all cases
4. They only function with the largest models

17. A tutoring assistant skips reasoning steps and jumps to a wrong arithmetic answer. Which technique most directly helps?

1. Chain-of-thought prompting requiring step-by-step reasoning before a final answer
2. Removing all examples from the prompt
3. Reducing the model's context window
4. Disabling retrieval

18. Select two. Which two design choices most directly improve prompt-cache hit rates for a system with a large, static system prompt and a varying user message?

1. Placing static content before the variable content
2. Setting the cache breakpoint on the last block that is identical across requests
3. Randomizing the order of static content each request
4. Appending a timestamp before the cache breakpoint

19. A system prompt lists the assistant's role, then reference material, then explicit behavioral guardrails, then output-format requirements. What principle does this ordering reflect?

1. Random ordering has no effect, so this is arbitrary
2. A deliberate, layered system-prompt structure that establishes context before constraining behavior and output
3. Guardrails should always be listed first, so this ordering is wrong
4. Output format should never be specified in a system prompt

Domain 3: Integration (Items 20-31)

20. An agent configured with far more tools than its task requires shows degraded tool-selection accuracy and a larger attack surface. What is this called?

1. Context rot
2. Capability bloat
3. Model drift
4. Cache invalidation

21. A backend tool call executes using a shared application-level credential instead of the requesting user's actual permission scope. What gap does this represent?

1. An authentication gap only
2. An authorization gap: the call may exceed what this specific user should be allowed to do
3. A latency issue only
4. No gap, since the application itself is authenticated

22. A RAG system retrieves the top-40 chunks per query "to be thorough," though evals show accuracy plateaus at 6 chunks for this corpus. What is the likely consequence?

1. Guaranteed proportional accuracy gains
2. Wasted cost/latency and possible context-rot-driven accuracy loss with no benefit past the plateau
3. No cost impact, since retrieval is free
4. Automatic deduplication with no downside

23. Confident but wrong answers appear immediately after a scheduled document refresh, with model version and latency unchanged. Where should the architect look first?

1. Temperature setting
2. The retrieval/indexing layer for stale or broken chunks
3. The user's device
4. The context window size

24. A knowledge base is a structured table of transactional order records, and users ask for exact order statuses by ID. Which retrieval approach fits best?

1. Chunk everything into prose and use dense vector search
2. Direct database query / text-to-SQL against the structured records
3. A giant few-shot prompt of all orders
4. Fine-tuning on the order table

25. Two independent companies need their agents to negotiate a shared task without either hosting a central orchestrator the other must trust. Which integration mechanism fits best?

1. A shared internal MCP server hosted by one company only
2. An agent-to-agent protocol enabling peer communication across the trust boundary
3. A hardcoded shared CLI script
4. Monolithic context loading both companies' tool catalogs into one agent

26. A tool catalog is expected to grow from 20 to 400 tools over the next year. Which context strategy scales appropriately?

1. Continue loading every tool definition on every request
2. Progressive discovery: a searchable directory, with full definitions loaded only for relevant tools
3. Randomly sample 20 tools per request
4. Disable tool use once the catalog exceeds 50

27. Select two. Which two practices most directly support observability at scale for a system handling hundreds of thousands of daily requests?

1. Structured logging of token usage, latency, tool calls, and guardrail triggers per request
2. Occasional informal spot-checking with no fixed cadence
3. Risk-stratified sampling with 100% review of high-stakes actions
4. Disabling logs to reduce storage spend

28. An integration needs to connect to a growing ecosystem of third-party tools and data sources with minimal bespoke glue code, usable across multiple AI client applications. Which mechanism fits best?

1. A one-off direct API integration per tool
2. MCP (Model Context Protocol)
3. A private, undocumented CLI wrapper
4. Hardcoded credentials shared across tools

29. A support agent that only ever needs to read tickets and draft replies is also configured with tools to issue refunds and delete accounts. Applying least privilege, what is the best fix?

1. Add audit logging to the refund/delete tools
2. Remove the refund and delete tools from the agent's configuration entirely
3. Add a confirmation dialog before refunds/deletions
4. Use a larger, more reliable model

30. A multi-hop question requires combining facts from several related documents and understanding relationships between entities. Which retrieval approach is best suited?

1. A single top-k vector search pass
2. Graph-based or iterative/agentic retrieval that can traverse relationships and retrieve again as needed
3. Keyword search only
4. No retrieval at all

31. Which best describes chunking strategy trade-offs in a RAG pipeline?

1. Chunk size has no effect on retrieval quality
2. Chunks too small lose needed surrounding context; chunks too large dilute relevance and waste tokens once retrieved
3. Larger chunks always improve accuracy with no downside
4. Chunking should always be exactly 100 tokens regardless of content

Domain 4: Evaluation, Testing & Optimization (Items 32-41)

32. A team plans to launch with only the statement "it seems to work well" as their evaluation basis. What is the most important corrective step?

1. Launch as planned
2. Define measurable targets across accuracy, latency, cost, safety, and security before launch
3. Measure only cost
4. Rely entirely on post-launch user complaints

33. Which combination of evaluation methods best balances scale and nuance?

1. Golden-set automation only
2. A mix of golden-set automated evaluation, model-graded (LLM-as-judge) evaluation, and sampled human evaluation
3. Human review of 100% of outputs only
4. No structured evaluation, only model self-reported confidence

34. A new prompt "feels better" after reading ten transcripts. What should precede a full production rollout?

1. Immediate 100% rollout
2. A proper A/B comparison on a sufficiently large sample, checking the primary metric and guardrail metrics
3. No further testing, since the team is confident
4. Rollout based on cost impact alone

35. A system shows a broad quality drop across unrelated task types immediately after a model version upgrade, with retrieval and infrastructure unchanged. What is the likely cause?

1. A retrieval indexing bug
2. Model mismatch: the new version behaves differently than what prompts/evals were tuned against
3. User error
4. A network issue

36. An assistant occasionally fabricates a plausible but nonexistent citation. What failure mode is this, and what mitigates it?

1. Rate limiting; mitigate with throttling
2. Hallucination; mitigate with grounded citation requirements verified against retrieved sources
3. Latency spike; mitigate with more hardware
4. Cache invalidation; mitigate by disabling caching

37. A team wants to reduce cost on a high-traffic pipeline. Which optimization should generally be tried first?

1. Correctly structured prompt caching for static prompt content
2. Immediately switching to the cheapest model regardless of fit
3. Removing safety guardrails to save tokens
4. Disabling logging

38. Which best describes the correct relationship between pre-launch evaluation and post-launch monitoring?

1. Pre-launch evaluation alone is sufficient forever
2. Evaluation is continuous: pre-launch, ongoing monitoring, and triggered re-evaluation after meaningful changes
3. Monitoring is needed only if pre-launch evaluation failed
4. They are unrelated, separately-owned activities

39. Select two. Which two are hallmarks of a well-designed evaluation dataset?

1. Built entirely from idealized synthetic happy-path examples
2. Includes real production traffic and deliberately chosen edge/failure cases
3. Refreshed periodically as the product and corpus evolve
4. Frozen permanently at launch

40. Rising latency appears with no change in output accuracy. Which is the most efficient first diagnostic step?

1. Rewrite the entire prompt from scratch
2. Check cache-hit-rate telemetry and tool-call timing breakdowns for a specific bottleneck
3. Assume the model itself has become slower with no further investigation
4. Increase the retrieved chunk count

41. Which metric dimension is most directly measured by a red-teaming exercise attempting prompt injection and jailbreaks?

1. Cost
2. Security
3. Latency
4. Productivity

Domain 5: Governance, Safety & Risk Management (Items 42-50)

42. An agent summarizing web pages follows hidden instructions embedded in page content, taking unintended actions. What is this, and what best mitigates it?

1. Hallucination; mitigate with a bigger model
2. Prompt injection; mitigate by treating retrieved content as untrusted data and constraining resulting actions
3. Model drift; mitigate by pinning a version
4. Bias amplification; mitigate with fairness testing

43. A healthcare startup uses a third-party vendor to process protected health information (PHI) via Claude. What is the essential compliance prerequisite?

1. A GDPR agreement only
2. A HIPAA Business Associate Agreement plus strict access controls and audit logging
3. No special agreement needed
4. Automatic FedRAMP authorization

44. An agent can issue refunds up to $10,000. Which reflects mature human-in-the-loop design?

1. One approval at session start covering all future refunds
2. Mandatory human approval at the point each refund would execute, especially above a threshold
3. Never allowing refunds under any circumstance
4. Logging refunds after the fact with no approval gate

45. A hiring-screening tool shows good aggregate accuracy but a notably higher false-rejection rate for one demographic subgroup. What should happen?

1. Ignore it since aggregate accuracy is fine
2. Investigate and address the subgroup disparity before further deployment in this consequential domain
3. Stop reporting subgroup metrics
4. Increase sample size without addressing the disparity

46. An EU-facing chatbot retains full transcripts indefinitely with no deletion mechanism. What compliance gap does this create?

1. A HIPAA violation
2. A GDPR gap around data minimization and the right to erasure
3. No gap, since chat isn't personal data
4. A FedRAMP violation

47. Which best exemplifies "removal beats detection" as a guardrail principle?

1. Logging every high-risk tool call
2. Removing an unneeded delete-account tool from an agent entirely
3. Adding confirmation dialogs to all actions, including harmless ones
4. Expanding the context window

48. A US federal agency wants to process case files in the cloud using Claude. What requirement most likely gates the entire deployment?

1. A well-written system prompt
2. Deployment in a FedRAMP-authorized environment meeting required residency, encryption, and audit controls
3. A larger context window
4. Enabling prompt caching

49. Select two. Which two support transparency as an ethical AI principle in a consequential-decision system?

1. Disclosing AI involvement and data use to affected users
2. Keeping the model's role undisclosed to avoid confusion
3. Maintaining internal documentation of model choice, guardrails, and known failure modes
4. Avoiding subgroup-level performance reporting

50. Which is a legitimate example of "excessive agency" as an LLM system risk?

1. A model correctly declining an out-of-scope request
2. An autonomous multi-step agent taking actions well beyond what the original task required, without a checkpoint
3. A model citing its retrieved sources accurately
4. A model responding within its context window limit

Domain 6: Stakeholder Communication & Lifecycle Management (Items 51-59)

51. A project begins from "add AI to our support process" with no further detail gathered. What is the most significant risk?

1. No risk at all
2. A technically functional system that fails to move the actual business metric, since success was never defined
3. Automatic budget overrun
4. Guaranteed regulatory violation

52. An architect must explain to a non-technical executive why a routing layer with a smaller model was chosen over one large model for every request. Which explanation fits best?

1. A detailed explanation of attention mechanisms
2. A trade-off explanation tying the choice to latency SLA, cost, and negligible quality impact on the majority of traffic
3. Avoiding the topic entirely
4. "It's just more efficient," with no further detail

53. A stakeholder requests an unplanned new capability mid-project with no discussion of timeline or cost. What is the best next step?

1. Silently add it
2. Evaluate it against the original success metric and constraints, and communicate the trade-off before proceeding
3. Refuse outright with no discussion
4. Add it and hide the resulting delay

54. A system is handed off with only a verbal walkthrough and no written documentation; the original architect later leaves. What was missing?

1. A bigger model
2. Complete documentation enabling someone other than the original architect to operate the system
3. A different programming language
4. More pre-launch meetings only

55. Which lifecycle phase is most often incorrectly treated as optional?

1. Discovery
2. Monitoring and iteration after launch
3. Initial design
4. The kickoff meeting

56. A client verbally agreed the system should be "fast and accurate" with no further specification, and now disputes whether it meets that bar. What should have happened earlier?

1. Nothing; verbal agreement suffices
2. Defining concrete, written SLA metrics tied to the evaluation framework, agreed before build
3. Building first, defining metrics afterward based on results
4. Avoiding metric discussion to stay informal

57. What is the primary purpose of an Architecture Decision Record (ADR)?

1. Marketing collateral for the client
2. A structured record of context, options considered, the decision, trade-offs accepted, and reversibility
3. A line-by-line code changelog
4. A document used only once for legal sign-off

58. Select two. Which two should structured discovery establish before design begins?

1. The exact final prompt text
2. The business success metric and acceptable risk tolerance
3. The current-state process and baseline to improve upon
4. The specific vector database vendor

59. A team documents guardrails, evaluation results, and runbooks as part of handoff. What lifecycle purpose does this serve?

1. Satisfying an arbitrary paperwork requirement only
2. Enabling the operating team to independently diagnose and respond to incidents after handoff
3. Replacing the need for any monitoring going forward
4. Preventing any future iteration on the system

Domain 7: Developer Productivity & Operational Enablement (Items 60-63)

60. A team adopts an agentic coding tool with no shared team-level configuration; every developer configures it differently. What is the most direct consequence?

1. Guaranteed faster delivery
2. Inconsistent style, duplicated effort, and uneven safety/permission boundaries across developers
3. No consequence
4. Automatic compliance with architecture standards

61. Which permission boundary best reflects least-privilege practice for an agentic coding tool in a shared repository?

1. Direct push access to production with no review
2. Autonomous read/test access, with explicit approval required before destructive commands or deploys
3. Full administrative access for simplicity
4. No command execution allowed at all

62. After a production incident, the team cannot reconstruct the prompt version, retrieved context, or model version involved. What was missing beforehand?

1. A larger context window
2. Reproducible, structured logging capturing the exact request details per call
3. A faster model
4. More stakeholder meetings

63. A prompt change causes a regression, and reverting it requires 45 minutes and a full redeploy. What operational capability was missing?

1. A larger evaluation dataset
2. A fast, low-friction rollback path for prompt/configuration changes independent of full redeployment
3. A bigger model
4. More input-layer guardrails

Answer Key & Rationale

Score yourself, then read every rationale, including for items you got right. The reasoning pattern matters more than the individual fact.

Domain 1 (Items 1-11)

Domain 2 (Items 12-19)

Domain 3 (Items 20-31)

Domain 4 (Items 32-41)

Domain 5 (Items 42-50)

Domain 6 (Items 51-59)

Domain 7 (Items 60-63)

Glossary

Every bolded or domain-critical term used in this guide, in one place for last-minute review.

External Resources & Further Reading

This guide is designed to be sufficient on its own: these links are optional deeper dives and official primary sources, useful for hands-on practice and for verifying anything that may change after this guide's July 2026 edition.

Official certification sources

• Official Exam Guide (PDF): the authoritative blueprint this study guide is built from: search "Claude Certified Architect Professional Exam Guide" on Anthropic Partner Academy, or visit anthropic-partners.skilljar.com.
• Anthropic Partner Academy certifications hub: anthropic-partners.skilljar.com/page/partner-certifications, for the FAQ, policies, and any prep courses added over time.
• Pearson VUE (exam delivery): pearsonvue.com/us/en/anthropic.html, scheduling, system requirements, and accommodations.

Anthropic technical documentation

• Claude Platform Docs: platform.claude.com/docs, the primary reference for models, the Messages API, tools, context management, prompt caching, extended/adaptive thinking, and Skills. Start with "Models overview," "Choosing a model," and "Features overview."
• Prompt engineering guides: under Build with Claude → Prompt engineering: covers prompting best practices, chain-of-thought, and model-specific guidance.
• Context management: Context windows, Compaction, Context editing, and Prompt caching pages: essential hands-on reading for Domain 2 and Domain 3.
• Tools & agents: Tool use overview, MCP connector, Remote MCP servers, and Agent Skills overview: essential for Domain 3.
• Claude Agent SDK: platform.claude.com/docs/en/agent-sdk/overview, for building custom agent harnesses referenced in Domain 1 and Domain 7.

Model Context Protocol

• modelcontextprotocol.io: the open MCP specification, architecture concepts, and guides for building both MCP servers and clients: core reading for Domain 3's connection-protocol objectives.

Anthropic engineering & research writing

• "Building Effective Agents" (anthropic.com/engineering): the primary source for the workflow/agent vocabulary (prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer) used throughout Domain 1.
• "Effective context engineering for AI agents" (anthropic.com/engineering): deeper treatment of context rot and context management strategy for Domain 2.
• "Effective harnesses for long-running agents" (anthropic.com/engineering): relevant to Domain 1's multi-agent orchestration and Domain 7's operational patterns.
• Anthropic Transparency Hub (anthropic.com/transparency): model cards, responsible scaling policy, and safety documentation relevant to Domain 5.

Regulatory primary sources (for Domain 5)

• GDPR: official text and guidance at gdpr.eu or your EU data protection authority.
• HIPAA: U.S. Department of Health and Human Services, hhs.gov/hipaa.
• FedRAMP: fedramp.gov for the authorization process and marketplace of authorized cloud offerings.

Good luck on the exam, Amit.