CCAR-P Study Guide

How to use this guide

This guide follows the domain and objective structure of the official Claude Certified Architect – Professional (CCAR-P) Exam Guide, version 1.0, July 2026, exactly. Each blueprint domain is a section, and each testable objective is a subtopic you can open from the side menu.

Every objective answers the same questions: what it is, why it matters, how it is applied, an example of the kind of scenario that appears on the exam, and links to the official documentation that backs the concept.

The recommended study order is to read a full domain, take a practice exam, and go back to the objectives where you missed questions. Studying without practicing gives you a false sense of mastery: the exam does not test whether you recognize a definition, it tests whether you choose the right architecture when the scenario offers three plausible options.

Exam quick reference

Weight of each domain

Integration is the heaviest domain and Developer Productivity the lightest. If you are short on time, prioritize domains 3, 1, and 4: together they make up more than half of the exam.

Domain 1: Solution Design & Architecture (17%)

This domain tests whether the candidate can go from “we have a business problem” to “this is the architecture that solves it,” including when to use agents, when not to, and how to justify the decision in terms of business value.

Translate business problems into Claude-based AI solutions

What it is: the exercise of taking a problem stated in business language (“we lose too much time triaging tickets,” “analysts take a day to summarize contracts”) and turning it into a technical specification: what the system must do, with what data, under what constraints, and how success will be measured.

Why it matters: it is the first point of failure in any AI project. An architect who starts from the model (“let’s use the newest one”) instead of the problem builds an elegant solution that solves nothing. The exam rewards the right order: problem → constraints → architecture → model, never the reverse.

How it is applied: structured discovery (see Domain 6) to extract the real problem, the available data, the constraints (latency, cost, compliance) and the definition of success, before drawing any diagram.

Exam example: a kickoff meeting where an executive announces “we’re going to build a multi-agent system with the newest model” before any discovery exists. The correct answer is almost always to redirect the conversation toward the problem and the metrics, leaving the architecture as a later, derived decision.

Reference: there is no single official page on “translating business problems”; it is a consulting discipline that the rest of this guide puts into practice with Anthropic’s tools. See Domain 6 for the concrete discovery techniques.

Design end-to-end architectures

What it is: the mental pattern used to draw any production AI system: an input comes in (user question, document, event), goes through processing (prompt, retrieval, tools, orchestration), produces an output, and that output together with its real-world performance must feed back into the system. That last step, the feedback loop, is the one most often forgotten.

Why it matters: a system without a feedback loop cannot improve, it can only be replaced. The exam includes items where an architecture diagram is almost complete except for the return arrow from monitoring to evaluation, and spotting that omission is an explicit exam objective.

Exam example: “an architect reviews a diagram with input, processing, output, and monitoring, but the monitoring doesn’t connect to anything.” The correct answer is to close the loop toward evaluation and iteration.

Reference: Building Effective Agents, Anthropic

Select appropriate architectural patterns

What it is: the most fundamental design decision. Anthropic defines three increasing levels of autonomy:

• Augmented LLM: a single model enhanced with retrieval, tools, and memory, with no multi-step orchestration. It is the basic building block.
• Workflow: the LLM and tools are orchestrated through predefined code, meaning the sequence of steps is fixed in advance (prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer; see Appendix A).
• Agent: the LLM dynamically directs its own process and tool use, deciding in real time how many steps to take and in what order, using feedback from the environment to correct itself.

Why it matters: Anthropic’s guidance is explicit: start with the simplest solution that meets the requirements and increase complexity only when evaluations show it improves the result. Agents trade latency and cost for flexibility, and that purchase must be justified with evidence, not fashion.

Exam example: a case where a single model call already passes the evaluations, but the team proposes 6 agents because it “sounds more advanced.” The correct answer is to keep the design simple.

Reference: Building Effective Agents, Anthropic

Design multi-agent systems and orchestration strategies

What it is: when a single agent is not enough, because the task allows parallel exploration or requires separation of responsibilities, you design an orchestrator-workers system: a lead agent breaks the task down, delegates to subagents with their own context and tools, and synthesizes the results.

Why it matters: Anthropic’s multi-agent research system showed substantial performance gains over a single agent on broad (breadth-first) exploration tasks, but at a much higher token cost, by orders of magnitude. The pattern is only justified when the task breaks down into truly independent directions and the value of the task covers that cost. Risks specific to this pattern: context isolation between workers, so data from one task does not contaminate another, and preventing the orchestrator from spawning too many subagents for simple questions.

Exam example: due diligence over 300 heterogeneous documents where subtopics emerge as you read. Orchestrator-workers is the answer, because the decomposition cannot be fixed in advance.

Reference: How we built our multi-agent research system, Anthropic

Apply decomposition techniques for complex problem solving

What it is: when a task is too large or too heterogeneous for a single call, it is broken into smaller, verifiable steps. The base technique is prompt chaining: splitting the task into a fixed sequence of steps, where each step uses the output of the previous one, optionally with a programmatic gate (code-based validation) between steps.

Why it matters: splitting the work into subtasks with intermediate verification raises accuracy and lowers the cognitive load per call, at the price of extra latency. It is the lowest-complexity technique among the agentic patterns and almost always the right starting point before considering multi-agent orchestration.

Exam example: “extract parties, dates, and obligations, check for conflicts, and summarize” in a single prompt fails. The solution is to decompose into chained subtasks with a verification gate.

Reference: Building Effective Agents, Anthropic

Align solutions to business value pillars

What it is: a framework for classifying and communicating the value of an AI solution, useful for justifying investment to executives.

Why it matters: mixing up the pillars leads to measuring success the wrong way. Automating an existing queue (efficiency and productivity, with a measurable baseline) is one kind of bet; launching a new capability the company could not offer before (transformation, under uncertainty, measured by strategic value) is a completely different kind of bet. Each demands different metrics, risk appetite, and executive framing.

Exam example: two initiatives compete for budget, automating a document queue versus launching a new sales capability. Classifying each one in the right pillar determines which success metrics are valid for each.

Reference: there is no single Anthropic page with this exact framework; it is a standard business-value convention in the industry. For real-world data on AI adoption and value in enterprises, see the Anthropic Economic Index.

Domain 2: Claude Models, Prompting & Context Engineering (13%)

This domain tests “how to talk to the model” decisions: which model to use, how to structure the prompt, and how to manage context so it stays effective and cheap as the conversation grows.

Select appropriate Claude models based on trade-offs

What it is: choosing between fast, inexpensive models (the Haiku family) and more capable models (the Sonnet and Opus families) based on the real difficulty of the task, not on preference.

How it is applied: the official guidance recommends two iteration paths:

1. Start cheap: implement with the fastest, cheapest model, evaluate against your use case, and move up only if there is a measured capability gap.
2. Start capable: for complex tasks, implement with the most capable model, optimize the prompt, and then consider dropping down a tier or lowering “effort” once evaluations confirm that a smaller model maintains quality.

In both cases, your own use-case evaluation set is the most important step. A public benchmark does not certify that a model fits your specific task.

Exam example: a router that sends 70% of traffic to a fast model and 30% to a capable model meets latency, cost, and quality goals at the same time, while using the most capable model for all traffic misses latency and cost targets even though it has the highest quality.

Reference: Choosing the right model, Claude Docs

Design system prompts, templates, and guardrails

What it is: the system prompt is the designated place to set an assistant’s role, tone, scope, and hard rules; everything else (the specific task, the data) goes in the user turn. A guardrail is any instruction or control that bounds behavior: what it must not do, when it must refuse, when it must escalate to a human.

Why it matters: the role in the system prompt is one of the highest-impact prompt engineering techniques, because it turns Claude from a generic assistant into a domain expert and improves accuracy, tone, and focus all at once. The system prompt is also the natural place to declare the instruction hierarchy, that is, what prevails if the user contradicts a system rule.

Exam example: a system prompt that has accumulated months of patches contains contradictory instructions (one says “never reveal X,” another says “adapt the format to whatever the user asks for”). The correct diagnosis is to audit the prompt as a versioned artifact and resolve the conflict explicitly, not to add a third instruction on top.

Reference: Giving Claude a role with a system prompt, Claude Docs

Apply prompt engineering techniques

What it is:

• Zero-shot: ask for the task directly, with clear and explicit instructions, without examples.
• Few-shot (multishot): show 3 to 5 representative, diverse input and output examples, including edge cases, wrapped in <example> tags so the model can tell them apart from the real task. It is one of the most reliable ways to lock in format, tone, and consistency.
• Chain-of-thought (CoT): ask for step-by-step reasoning before the final answer, useful in logic, math, or multi-step analysis tasks. It is structured with tags like <thinking> and <answer> when native extended thinking is not active.

Why it matters: each technique solves a different problem: zero-shot for simple, well-specified tasks, few-shot to lock in an exact format or style, CoT for tasks that benefit from explicit reasoning. Applying CoT to a trivial task only adds cost and latency with no accuracy gain.

Exam example: few-shot example pairs put together in a hurry where 11 of 12 have the same distinctive phrase in the positives and none in the negatives. The model learns a spurious shortcut (that phrase), not the real concept. The fix is a balanced, diverse set, audited for accidental regularities.

Reference: Use examples (multishot prompting), Claude Docs · Let Claude think (chain of thought), Claude Docs · Use XML tags, Claude Docs

Optimize context windows and manage token usage

What it is: context is a finite, paid resource. Everything that enters the window (system prompt, history, tool results, documents) counts toward the model’s limit and toward the bill. Context engineering is the discipline of curating what information lives in the context at each moment, beyond just writing a good prompt.

How it is applied:

• Just-in-time retrieval: instead of preloading everything, keep lightweight references (file paths, IDs) and load the content on demand with tools.
• Compaction: summarize results from earlier turns, keeping conclusions and discarding verbosity.
• External memory: persist durable facts (decisions, preferences) outside the window, retrieving only what is relevant per session.

Why it matters: larger context windows do not guarantee better performance. The context rot phenomenon describes how more irrelevant tokens make it harder for the model to stay focused. And even if the technical limit is high, cost and latency scale with what you actually send.

Exam example: loading a full 5 GB corpus into every prompt “because windows are big now” is wrong even if it technically fit, because cost and latency per query scale with context size. Retrieving only what is relevant is still the correct design.

Reference: Context windows, Claude Docs · Effective context engineering for AI agents, Anthropic

Implement prompt reuse strategies

What it is: three mechanisms to avoid reinventing context on every call:

• Prompt caching: the stable prefix of a prompt (system prompt, tools) is cached. Reads cost about 10% of the normal input price, and writes cost about 125% with a 5-minute TTL or 200% with a 1-hour TTL. The correct order is stable content first (tools, then system, then messages) and variable content last, because any change inside the prefix invalidates the entire cache.
• Modular prompts: a system prompt parameterized by audience or context, instead of one giant monolithic prompt, so parts can be maintained and versioned separately.
• Skills: folders of reusable instructions, scripts, and resources that Claude loads automatically when relevant, with progressive disclosure (they are only loaded into context when the task needs them), ideal for standardizing procedures across the organization.

Exam example: an engineer hotfixes one sentence in the shared system prompt during peak hours, and cost and latency immediately rise across the whole fleet. The cause is that the change invalidated the cached prefix, and the correct practice is to version and schedule such changes deliberately.

Reference: Prompt caching, Claude Docs · Agent Skills, Claude Docs

Domain 3: Integration (19%)

This is the heaviest domain on the exam. It tests how to connect Claude to real systems: which protocol to use, how to secure access, how to design retrieval, and how to maintain observability at scale.

Evaluate tool/agent configuration for capability bloat

What it is: capability bloat happens when an agent has too many tools, poorly named or overlapping tools, or overly verbose tool results. All of that degrades its ability to pick the right tool and consumes unnecessary context.

How it is applied: few, well-scoped, orthogonal tools, with clear names and descriptions (think about how you would explain the tool to a new colleague); paginated, truncated, or filtered results instead of full dumps; and for large catalogs, with hundreds of tools, use progressive disclosure, that is, a lightweight index that loads the full definition only for the tools relevant to the current task.

Exam example: an agent with 45 tools that often picks the wrong one. The solution is to reduce to the minimum needed per task and load the rest on demand, not to add a paragraph to the prompt asking for “more care.”

Reference: Writing effective tools for AI agents, Anthropic · Tool use overview, Claude Docs

Analyze authentication and authorization requirements

What it is: deciding which credentials an agent or connector uses to act on external systems, and with what scope. The guiding principle is least privilege: short-lived, rotated credentials, with exactly the scope the task requires and nothing more.

How it is applied:

• Delegated OAuth when the agent acts on behalf of an aware end user, with explicit, revocable consent. This is the model for remote MCP connectors.
• Service credentials (machine-to-machine) for unattended work on behalf of the system, not of a person.
• Audience binding: a token issued for server A must not be valid on server B, which prevents replay across services.

Exam example: an agent with a tool that only needs to read one system and write to a queue is given organization-wide administrator credentials “for simplicity.” The security gap is the absence of least privilege, and the fix is a narrow, short-lived scope dedicated to those two operations.

Reference: MCP connector, Claude Docs · Model Context Protocol, authorization specification

Evaluate accuracy-latency trade-offs

What it is: almost every quality lever has a latency cost, or the other way around: extended thinking, reranking, more retrieved context, a larger model. The architect’s job is to quantify that trade-off and justify the chosen configuration against a measurable requirement, not against a preference.

How it is applied: measure the lever’s curve (for example, extended thinking budget versus accuracy) and pick the point where the marginal quality gain no longer justifies the marginal latency and token cost. That curve almost always shows diminishing returns.

Exam example: an extended thinking curve where accuracy rises sharply up to 16k tokens, gains little up to 32k, and flattens after that. The defensible setting is around 16k to 32k, not the maximum available “just in case.”

Reference: Extended thinking, Claude Docs · Reducing latency, Claude Docs

Analyze observability challenges and select monitoring strategies

What it is: unlike deterministic software, an LLM system needs observability that captures not only whether the request failed, but what the model saw, what it retrieved, which tools it called, and why it answered the way it did. At scale, logging everything in full detail is expensive, and the standard strategy is sampling for routine traffic and full traces for errors and anomalies, with correlation IDs that tie model calls, retrieval, and tool calls into a single trace per request.

How it is applied: logging with redaction or tokenization of sensitive data at capture time, role-based access control over the trace store, defined retention, and aggregate metrics (cache-hit rate, p95 and p99 latency per stage, refusal rate) with alerts on deviations.

Exam example: one specific bad answer from a Tuesday can only be diagnosed with the full trace of that request: what was retrieved, with what score, under which prompt version. A weekly satisfaction average is useless for that kind of targeted diagnosis.

Reference: Usage and Cost API, Claude Docs · Rate limits, Claude Platform Docs

Design a RAG pipeline with chunking and indexing strategies

What it is: Retrieval-Augmented Generation (RAG) combines an indexed knowledge base with generation: the system retrieves the chunks most relevant to the query and gives them to the model as context before it answers.

How it is applied: the chunking technique must reflect the shape of the data: by function or class in code, by section in contracts, with overlap between chunks so ideas are not cut at the boundary. Contextual Retrieval, Anthropic’s technique, prepends to each chunk a short model-generated context describing its place in the full document, which reduces retrieval failures by up to 49%, and up to 67% when combined with reranking, using prompt caching so the cost of generating that context stays manageable.

Exam example: a codebase indexed with fixed 500-token chunks cuts functions in half. The fix is structure-aware chunking, by function or class, not smaller chunks of the same arbitrary kind.

Reference: Introducing Contextual Retrieval, Anthropic

Apply retrieval strategies matched to data shape

What it is: not every query is solved the same way. Semantic search (embeddings) captures paraphrasing but can fail on exact matches such as SKUs or error codes; lexical search (BM25) captures exact matches but not paraphrasing. The hybrid strategy combines both, and reranking is reserved for ambiguous queries where the extra cost is worth it.

How it is applied: for catalogs with exact identifiers, favor hybrid with a high lexical weight; for conversational questions, semantic with query expansion if the query is very short; for multi-hop questions, agentic iterative retrieval instead of a single pass.

Exam example: users searching by exact SKU get poor results with pure semantic search. The solution is hybrid retrieval, lexical plus semantic, not indiscriminately increasing k.

Reference: Introducing Contextual Retrieval, Anthropic

Evaluate connection protocols and select the integration mechanism

What it is: three integration mechanisms with different purposes.

MCP defines three primitives: tools (actions, model-controlled), resources (read-only data, application-controlled), and prompts (reusable templates, user-controlled, typically exposed as commands).

Exam example: an organization needs the same CRM connector available in Claude Code, the desktop app, and a custom agent. Building three custom integrations is wrong: a single MCP server reused by all three clients is the answer.

Reference: Model Context Protocol, specification · MCP connector, Claude Platform Docs

Evaluate progressive discovery vs. monolithic context

What it is: when an agent has access to a large catalog of tools or documents, there are two strategies: monolithic, loading everything into context from the start, or progressive disclosure, keeping a lightweight index and loading the full detail only for what is relevant to the current task, on demand.

Why it matters: the monolithic strategy is simple but does not scale. With hundreds of tools or documents it saturates the context, raises cost, and degrades selection accuracy. Progressive disclosure is the documented pattern for scaling, used for example by Skills and by Claude’s tool search.

Exam example: a platform with more than 100 tools fully defined in every prompt. The fix is a lightweight index with search, loading full definitions only for the tools relevant to the task at hand.

Reference: Writing effective tools for AI agents, Anthropic · Agent Skills, Claude Docs

Domain 4: Evaluation, Testing & Optimization (16%)

This domain tests the discipline of measuring: how success is defined, how evaluation datasets are built, how failures are diagnosed, and how cost and latency are optimized without sacrificing quality.

Define evaluation metrics

What it is: before building anything, you agree on success criteria that are specific, measurable, achievable, and relevant to the use case. “Good performance” is not a metric; “sentiment classification with 95% accuracy on the test set” is. Most applications need multidimensional evaluation: task accuracy, latency (p50, p95, p99), cost per resolution, safety (correct refusal rate, jailbreak resistance) and, where applicable, information security.

Why it matters: without criteria agreed in advance with business stakeholders, success is left to the discretion of whoever looks at the result, and launch decisions lose their objective basis.

Exam example: defining the evaluation metrics during discovery, together with the business stakeholder, rather than at the end of development or unilaterally by engineering.

Reference: Define success criteria and build evaluations, Claude Platform Docs

Design evaluation datasets and test frameworks

What it is: an evaluation dataset combines anonymized real questions, to reflect the real traffic distribution, with synthetic edge cases, labeled against a rubric. Grading combines three methods depending on how objective the property being measured is.

Why it matters: an LLM judge must be calibrated against human labels, measuring its agreement instead of trusting it blindly. And a small dataset iterated on repeatedly ends up overfitted, so you need to keep a held-out portion that is never used to tune prompts, reserved for final measurement.

Exam example: two human annotators who disagree on 40% of cases. Before using those labels as ground truth, you must refine the labeling guide and measure inter-annotator agreement.

Reference: Define success criteria and build evaluations, Claude Platform Docs

Conduct A/B testing and iterative improvements

What it is: comparing a candidate variant against the production version on real traffic, in a controlled way (random assignment, same time period, same traffic mix) to isolate the effect of the change from other factors such as seasonality.

Why it matters: comparing variants in different periods, for example a holiday week against a normal week, confounds the effect of the change with the effect of the calendar. Also, small differences on small samples are often statistical noise rather than real signal, so before launching you must verify that the sample is large enough for the effect size you want to detect.

Exam example: an A/B test where variant A ran during a holiday week and B during a normal week, with B winning. The result is confounded by seasonality and is not valid for making a decision.

Reference: there is no single official Anthropic page solely about A/B testing methodology; it is general statistical practice. See the combined guide on defining criteria and evaluations, which mentions it as one of the measurement techniques.

Diagnose system issues

What it is: a set of diagnostic patterns for when something goes wrong in production.

• Hallucinations: the model asserts something not supported by the context. Mitigation: explicitly allow it to say “I don’t know,” ask for citations grounded in the source text, and verify claims against those citations.
• Prompt failure: a recent prompt change introduced contradictory or poorly calibrated instructions, for example a spike in refusals right after editing it.
• Model mismatch: the chosen model is not right for the real difficulty of the task, or the provider changed the model behind an alias without the team pinning it to a specific version.

Exam example: a RAG system starts giving confident but incorrect answers right after a document update, with no change in latency or in the model version. The first place to investigate is the retrieval and indexing step, with stale or poorly indexed chunks, not the model.

Reference: Reduce hallucinations, Claude Platform Docs

Optimize token usage, latency, and cost-performance

What it is: a set of concrete levers to lower cost and latency without sacrificing already-validated quality.

• Prompt caching for reused stable prefixes (see Domain 2).
• Batch API for deferrable, non-urgent work: 50% discount on input and output, processed asynchronously.
• Routing by difficulty: fast models for simple tasks, capable ones for hard tasks.
• Streaming to improve perceived latency even if total latency does not change.
• max_tokens and stop sequences to avoid unnecessary generation.

Why it matters: every lever must be verified against the evaluation set. Lowering cost without confirming that quality holds is optimizing blindly.

Exam example: a workload of 40,000 summaries every night, with no real-time requirement. The Batch API with the smallest model that passes the evaluations is the right combination.

Reference: Batch processing, Claude Docs · Reducing latency, Claude Platform Docs

Monitor system performance using logging and observability

What it is: once in production, the system needs continuous telemetry: usage and cost per team or feature (Usage & Cost API), cache hit rate, latency percentiles per stage, and production quality signals such as the human escalation rate, the thumbs-down rate, or the rate at which users immediately rephrase the same question, which work as early proxies while a slower human review is pending.

Exam example: finance asks for a breakdown of model spend by feature and team. This requires per-request token accounting tagged with feature and team metadata, backed by separate API keys or workspaces per team, not an even split of the total bill.

Reference: Usage and Cost API, Claude Docs · Workspaces, Claude Platform Docs

Domain 5: Governance, Safety & Risk Management (14%)

This domain tests controls: how the risk of an LLM system is limited, how humans are involved, and how regulations such as GDPR, HIPAA, and FedRAMP are met.

Implement guardrails and safety controls

What it is: layered controls across the whole chain: input screening to detect malicious content before it reaches the model, often with a small, fast model as a classifier; a hardened system prompt that treats third-party content as data and never as instructions; and output validation before showing it or acting on it. No single layer is enough: effective defense is defense in depth.

Why it matters: indirect prompt injection, meaning malicious instructions hidden in a document or email that the model processes, is one of the best-documented risks in LLM applications and tops the OWASP Top 10 for LLMs. It is not solved with a single filter: it requires retrieved content to always be treated as data, with human confirmation before sensitive actions.

Exam example: an assistant that summarizes emails receives one with hidden text instructing it to forward payroll information. The correct design treats read content as data and never as authority, requires explicit confirmation for sensitive actions, and does not rely on the model noticing the trick.

Reference: Mitigate jailbreaks and prompt injections, Claude Platform Docs · OWASP Top 10 for LLM Applications

Identify risks, limitations, and failure modes

What it is: a deliberate inventory of how an LLM system can fail: hallucination, bias inherited from training data, leakage of sensitive information via prompt or logs, tool misuse with unauthorized actions, and user over-reliance on incorrect answers.

How it is applied: classify actions by reversibility and impact to decide autonomy levels, automating what is reversible and low-impact and requiring human approval for what is irreversible or high-impact, and maintain an AI-specific incident response plan with severity classification, a kill switch, communication, and a postmortem.

Exam example: deciding which of an agent’s actions can run autonomously and which require human approval. The deciding axis is reversibility and blast radius, not how old the tool is or alphabetical order.

Reference: NIST AI Risk Management Framework · OWASP Top 10 for LLM Applications

Apply human-in-the-loop validation strategies

What it is: defining where and how a human steps into the process: pre-action approval for what is irreversible or high-value, sampled post-hoc review for medium risk, or continuous automated monitoring for low risk. A common pattern for consequential actions is propose, approve, execute: the agent prepares the exact change and its rationale, a human approves, and only then is it applied.

Why it matters: miscalibrating the level of oversight, reviewing everything (which does not scale) or reviewing nothing (which exposes you to costly mistakes), is one of the most common design errors in agentic systems with real-world actions.

Exam example: a refund agent that today can issue refunds of any amount autonomously. The first control to add is a human approval gate above a defined value threshold, with the refund tool limited to reversible operations.

Reference: Building Effective Agents, Anthropic, section on checkpoints and human oversight

Ensure compliance with regulations

What it is: three regulatory frameworks the exam expects you to recognize at the architecture level, not as legal advice.

Exam example: a government client requires FedRAMP compliance. The decisive consideration is operating inside an environment with a current FedRAMP authorization, verifying that the level and scope of the authorization cover the services used, not the model version or the prompt.

Reference: HIPAA Security Rule, HHS.gov · GDPR Art. 17 · GDPR Art. 35 · FedRAMP.gov

Address ethical AI considerations

What it is: continuous monitoring, not just pre-launch, of error and outcome rates per relevant segment, with alerts on significant divergences; disclosure of when content is AI-generated; and enough explainability that a relevant decision can be reconstructed, knowing which prompt version, which sources, and which tool calls produced it.

Why it matters: fairness is not a property you certify once. It degrades over time as input data and system behavior change, so it requires continuous monitoring with the same rigor as any other production metric.

Exam example: a lending assistant that was evaluated for fairness only before launch. The correct governance is continuous monitoring of error rates per segment, with alerts and remediation, not a single initial test.

Reference: NIST AI Risk Management Framework · Anthropic Transparency Hub

Domain 6: Stakeholder Communication & Lifecycle Management (14%)

This domain tests consulting-architect skills: how the real problem is discovered, how technical decisions are communicated to non-technical audiences, and how the system is managed throughout its lifecycle.

Conduct structured discovery and requirement gathering

What it is: the phase that produces, before any technical decision, the business problem in one sentence, measurable success metrics, constraints (latency, cost, compliance, data residency), and an inventory of the available data and systems.

Why it matters: incomplete discovery is found late and expensive, typically when legal or security block the project at launch review because they were not consulted from the start.

Exam example: legal sees the assistant for the first time at launch review and blocks it over data handling. The practice that prevents this is involving compliance and legal stakeholders from discovery, not at the end.

Reference: there is no single Anthropic page on discovery methodology; it is consulting practice. The technical constraints that discovery must capture are described throughout Domains 3 and 5 of this guide.

Communicate architectural decisions and trade-offs

What it is: presenting an architecture decision to an executive committee by leading with business outcomes, cost, risk, and timeline, leaving the technical detail in an appendix, and documenting the reasoning behind significant decisions with an Architecture Decision Record (ADR) so that the future team understands why it was decided that way when conditions change.

Exam example: presenting three candidate architectures to a steering committee. The comparison should be made in a trade-off matrix (quality, cost, latency, risk, delivery time) with a reasoned recommendation, not by showing the code or prompts of each option.

Reference: there is no single official Anthropic page on this topic; it is general technical communication and Architecture Decision Record practice.

Manage stakeholder feedback loops and expectation alignment

What it is: a recurring rhythm, for example a periodic review with the product owner examining real transcripts and metrics, that turns production evidence into a prioritized improvement backlog. And for contractual commitments, a defensible SLA: latency percentile and availability targets that the architecture demonstrably meets, with defined degradation modes and reasonable exclusions such as third-party outages or maintenance windows.

Exam example: an enterprise customer demands an SLA with no exclusions. The defensible position is to commit to measurable targets that the architecture does control, with standard exclusions for what is genuinely outside its control, because guarantees with no exclusions promise a control the provider does not have.

Reference: there is no single official Anthropic page on this topic; it is product management and customer relationship practice.

Document architectures and provide implementation guidance

What it is: documentation layered by audience: a value and risk summary for executives, component and data-flow diagrams for engineering, runbooks and dashboards for operations, keeping all three consistent with each other, plus a handoff package that includes the prompt version registry and the authorized change process.

Exam example: the same architecture must be explained to the board, to the engineering guild, and to operations. The correct strategy is three audience-specific views kept consistent with each other, not a single artifact for everyone or documentation only for engineering.

Reference: there is no single Anthropic page on this topic; it is general software architecture documentation practice applied to AI systems.

Support lifecycle phases

What it is: the full lifecycle of an AI solution in production, as shown in the diagram in this section. Discovery defines the problem and constraints; design produces the architecture and its evaluations; handoff delivers the system to the team that will operate it, with documentation and KPIs already defined; monitoring observes the system in production; and iteration turns that evidence into changes, reopening the cycle toward design.

Why it matters: the phases are not a linear single pass. It is a cycle, and skipping monitoring or iteration, evaluating only once before launch, leaves the system’s quality frozen at the moment of launch while the real world keeps changing.

Exam example: defining at the discovery stage when the system should eventually be retired, with sunset criteria such as sustained KPI stagnation or unsustainable cost, is a mature part of managing the full lifecycle and not a taboo topic to avoid.

Reference: Building Effective Agents, Anthropic, the feedback loop as a structural part of the architecture

Domain 7: Developer Productivity & Operational Enablement (7%)

The lightest domain, focused on how an architect enables development teams to work effectively and safely with AI-assisted tools, mainly Claude Code.

Configure Claude tools and environments for teams

What it is: Claude Code is an agentic coding tool that reads the repository, edits files, runs commands, and integrates with development tools, available in the terminal, IDE, desktop app, and browser. A typical team setup includes a CLAUDE.md versioned in the repository with persistent project instructions, MCP servers for internal systems, and a permissions posture that defines which actions require explicit approval, appropriate to the repository’s risk level.

Exam example: new developers take days to set up a productive environment for each repository. The correct practice is to version CLAUDE.md, commands, and tool configuration inside the repository, so the environment is identical and reproducible from the first clone.

Reference: Claude Code, Overview · How Claude remembers your project (CLAUDE.md)

Improve developer workflows using AI-assisted tooling

What it is: patterns that raise real productivity and not just perceived productivity: custom commands for recurring workflows, hooks that run lint and tests automatically after every edit (deterministic control that does not depend on the model remembering), and MCP servers that connect Claude Code to internal systems such as tickets or documentation, as governed context sources.

Exam example: a team repeats the same release-notes workflow in Claude Code every week, re-explaining it each time. A custom command versioned in the repository, which encodes the workflow as a reusable invocation, eliminates the repetition.

Reference: Claude Code: Best practices for agentic coding, Anthropic · Hooks, Claude Code Docs · Slash commands, Claude Code Docs

Support debugging and operational issue resolution

What it is: the appropriate use of Claude during incidents and operational automation. In headless mode, non-interactive, inside CI, with scoped permissions and structured output, for tasks such as automated pull request review. And as a diagnostic assistant during an incident, analyzing logs and context to propose ranked hypotheses with verification steps, always keeping the human in charge of changes.

Exam example: an engineer wants AI help during a production incident without giving up control. The correct flow is to provide logs and context, ask for ranked hypotheses with verification for each, and have the engineer validate before applying any change. Never let the agent apply the change directly to production.

Reference: Headless mode, Claude Code Docs · GitHub Actions, Claude Code Docs

Appendix A: The 5 patterns from Building Effective Agents

Anthropic documents 5 workflow patterns, with predefined code and no agent autonomy, that usually solve most cases before a fully autonomous agent is needed. Prompt chaining and orchestrator-workers were already diagrammed in Domain 1; here all 5 are consolidated in a table and the remaining three are diagrammed.

General decision rule: start with the simplest solution, a single call or an augmented LLM, and move up this list only when evaluation shows that the added complexity improves the result enough to justify the extra cost and latency it adds.

Reference: Building Effective Agents, Anthropic

Appendix B: How to reason through the sample questions

The official Exam Guide includes 3 sample questions in its Section 8 that illustrate the style and cognitive level of the real exam. They are not reproduced here: instead, we analyze why each one has its answer, as exam-reasoning training.

Sample 1 (Domain 3, least privilege): the key to the item is distinguishing between privilege elimination controls, that is, removing the tool that is not needed, and detective or compensating controls such as logging and confirmation. The exam rewards the option that eliminates the attack surface, not the one that watches it or the one that changes an unrelated factor, such as model size.

Sample 2 (Domain 2, prompt caching): the key is recognizing that the real problem, latency and cost from a prefix repeated on every call, has a specific architectural solution: put stable content first and enable prompt caching. And discarding options that sound related but do not attack the cause, such as truncating needed content, blindly downgrading the model, or relocating the content without producing a cacheable prefix.

Sample 3 (Domain 4, RAG diagnosis): the key is diagnosis by elimination. If latency and model version did not change, but quality dropped right after a document refresh, the most likely cause is in the stage that did change, retrieval or indexing, not in the model or in a sampling parameter unrelated to the event.

General pattern for the whole exam: almost every item follows this structure. A scenario with a specific cause hinted at by the details (what changed, what stayed constant), 4 to 5 options where 2 or 3 are plausible in the abstract but do not attack the real cause, and a single option that solves exactly what the scenario describes. Reading what did not change in the scenario is as informative as reading what did.

Appendix C: Exam strategy and glossary

Exam day strategy

• 120 minutes for 63 items, which is 1 minute 54 seconds per item on average. “Choose two” items tend to take longer, so don’t get stuck: flag it mentally and move on.
• No penalty for guessing: answer everything, even the items where you are unsure.
• On “choose two” items, both answers must be correct to earn the point. First rule out the options that solve a different problem from the one in the scenario.
• Look in the scenario for what changed and what stayed constant right before the described symptom. The real cause is almost always there.
• When two options seem equally reasonable, prefer the one that attacks the root cause over the one that treats a symptom. For example, “review the prompt that was edited” before “change the model.”
• Be wary of extreme options (“never,” “always,” “eliminate entirely,” “no controls”) unless the scenario is exactly that edge case.
• For governance and compliance items, the correct option almost always combines prevention, oversight, and logging, not just one of the three.

Minimal glossary

Guide prepared from the official CCAR-P Exam Guide v1.0 (July 2026) and from official Anthropic documentation verified in July 2026. Links point to the specific page for each topic. Where no single authoritative source exists, for example in consulting practice or executive communication, this is stated explicitly instead of forcing an imprecise reference.