Claude Certified Architect Foundations (CCAR-F) Complete Study Guide 2026

What is the Claude Certified Architect Foundations?

The Claude Certified Architect Foundations (CCAR-F) is Anthropic's first official technical certification, validating that practitioners can make informed decisions about tradeoffs when implementing real-world solutions with Claude. The exam tests foundational knowledge across Claude Code, the Claude Agent SDK, the Claude API, and Model Context Protocol (MCP) — the core technologies used to build production-grade applications with Claude.

Questions are grounded in realistic scenarios drawn from actual customer use cases: building agentic systems for customer support, designing multi-agent research pipelines, integrating Claude Code into CI/CD workflows, building developer productivity tools, and extracting structured data from unstructured documents. Candidates must demonstrate not only conceptual knowledge but practical judgment about architecture, configuration, and tradeoffs in production deployments.

Exam Overview

• Exam Name: Claude Certified Architect Foundations
• Issued By: Anthropic
• Format: Multiple choice, scenario-based (1 correct + 3 distractors)
• Questions: 60
• Duration: 120 minutes
• Passing Score: 720 / 1000 (72%)
• Cost: $99 USD
• Scenarios: 4 of 6 randomly selected per candidate
• Target Audience: Solution architects building production Claude applications
• Registration: Anthropic Skilljar portal — available to everyone

Target Candidate Profile

The ideal candidate is a solution architect with 6+ months of hands-on experience building with Claude APIs, Agent SDK, Claude Code, and MCP. You should have experience with:

• Building agentic applications using the Claude Agent SDK including multi-agent orchestration, subagent delegation, tool integration, and lifecycle hooks
• Configuring and customizing Claude Code for team workflows using CLAUDE.md files, Agent Skills, MCP server integrations, and plan mode
• Designing Model Context Protocol (MCP) tool and resource interfaces for backend system integration
• Engineering prompts that produce reliable structured output using JSON schemas, few-shot examples, and extraction patterns
• Managing context windows effectively across long documents, multi-turn conversations, and multi-agent handoffs
• Integrating Claude into CI/CD pipelines for automated code review, test generation, and pull request feedback
• Making sound escalation and reliability decisions including error handling, human-in-the-loop workflows, and self-evaluation patterns

Exam Domain Weighting

Study strategy: Treat the exam as a scenario-recognition test. Identify the architectural clue first, then choose the simplest design that satisfies correctness, reliability, safety, and operational constraints.

Complete Five-Domain Study Guide

The sections below expand the certification overview into an exam-oriented reference. They are designed around decision rules, pattern recognition, common traps, scenario drills, and rapid review rather than rote memorization.

Domain 1 — Agentic Architecture & Orchestration

CCAR-F Domain 1

Agentic Architecture & Orchestration - Complete Exam Cheat Sheet

Designed to translate theory into practical architecture decisions: pattern -> when to use it -> exam clues -> common trap.

Use this beside your CCAR-F course. The goal is scenario recognition, not memorizing every lecture definition.

The #1 Rule

Known path -> WORKFLOW | Unknown / dynamic path -> AGENT

If the steps can be determined when you write the application, use a workflow.

If Claude needs to examine results and decide what to do next, you probably need an agent.

Anthropic distinguishes workflows as predefined orchestration and agents as model-directed execution.

The 20-Second Exam Decision Tree

1. Single LLM Call

Think: "Don't architect what you don't need."

Use when:

• Task is straightforward

• One prompt can reliably produce the answer

• Retrieval/examples can provide enough context

• No dynamic sequence of actions is required

Exam clue:

"The company wants the simplest, lowest latency and lowest cost solution..."

Start with one well-designed LLM call, potentially augmented with retrieval/tools.

Trap: Multi-agent system because "AI agents are more powerful."

2. Workflow vs Agent

Workflow

The application controls the path.

Input \| Step 1 \| Step 2 \| Step 3 \| Output

Good for:

• Predictable business processes

• Repeatability

• Easier testing/debugging

• Lower variability

• Compliance-sensitive processes

Agent

The model controls what happens next.

Goal \| Claude thinks/decides \| Action / Tool \| Observe result \| Decide next action \| repeat if needed \| Finished

Good for:

• Open-ended problems

• Unknown number of steps

• Dynamic tool selection

• Tasks where the next action depends on what is discovered

Memory hook: Workflow = YOU know the road. Agent = CLAUDE chooses the road.

3. Prompt Chaining

Prompt A \| Output A \| Prompt B \| Output B \| Prompt C

Each step depends on the previous step.

Use when the problem naturally breaks into a fixed sequence.

Examples:

Generate outline -> Validate outline -> Write article

Extract data -> Validate data -> Generate report

Exam clue words: sequential; ordered; step-by-step; output feeds next stage; validation between stages; predictable process.

Trade-off: Better focus/accuracy, but more latency than one call.

Memory hook: A -> B -> C = CHAIN

4. Routing

                 /-> Billing process
Input -> ROUTER -+-> Technical process
                 \-> General support

Classify the input, then send it to the appropriate specialized path.

Use when different types of input need:

• Different prompts

• Different models

• Different tools

• Different workflows

• Different expertise

Examples:

Customer question -> Billing? -> Technical? -> Sales?

Easy task -> cheaper/faster model Hard task -> stronger model

Exam clue words: classify; category; specialized handling; different types; choose appropriate model; choose appropriate workflow.

Memory hook: ROUTER = traffic cop. It does not do all the work; it decides where the work goes.

5. Parallelization

              /-> Task A -\
Input -------+-> Task B --+-> Combine
              \-> Task C -/

Use when tasks do not depend on each other.

Two important variations:

A. Sectioning

Different independent pieces of work.

Review contract:

Call 1 -> Legal risk Call 2 -> Financial risk Call 3 -> Privacy risk

-> Combine findings

B. Voting

Run the same task multiple times and compare results.

Useful when:

• Multiple perspectives improve confidence

• You want consensus

• Errors are costly

Exam clue words: independent; simultaneously; reduce latency; multiple perspectives; consensus; aggregate results.

Memory hook: Independent = PARALLEL. If Task B needs Task A's answer, it is not parallel.

6. Orchestrator -> Workers

This is one of the big ones.

                  /-> Worker A
                 /
Goal -> ORCHESTRATOR -> Worker B
                 \
                  \-> Worker C
                        |
                    Synthesis

The orchestrator dynamically decides:

• What subtasks are needed

• How to divide the work

• Which worker handles each

• How results get combined

Difference from normal parallelization

Parallel workflow - developer already knows:

Run A + B + C

Orchestrator-workers - Claude determines:

"This problem needs A, C, F and G. I'll delegate those."

Exam clue words: task cannot be decomposed beforehand; dynamically determine subtasks; delegate; specialist workers; synthesize; unpredictable complexity.

Memory hook: Boss does not do everything. Boss decides who does what.

7. Evaluator -> Optimizer

Generator \| Draft \| Evaluator \| Feedback \| Generator improves \| repeat

Repeat until quality criteria are satisfied.

Use when there are clear evaluation criteria, but high-quality output often requires iteration.

Examples:

• Code generation

• Writing

• Translation

• Complex analysis

• Policy compliance

• Quality improvement

Important: The evaluator needs to be able to explain what is wrong and how to improve it.

Exam clue words: critique; refine; improve; feedback; iterate until acceptable; measurable quality criteria.

Memory hook: Writer -> Teacher -> Rewrite

8. The Agent Loop

This is the heart of an agent.

USER GOAL \| CLAUDE \| Decides action \| Calls tool \| Gets result \| CLAUDE evaluates result \| More work? -- YES -> Loop \| NO \| Answer

The important concept: Claude must receive the result of an action before deciding what to do next.

The loop continues until:

• Goal achieved

• Claude determines it is finished

• Maximum iterations reached

• Error/stop condition occurs

• Human intervention is required

Memory hook: THINK -> ACT -> OBSERVE -> REPEAT

9. Planning & Decomposition

Goal \| Plan \| Break into subtasks \| Execute \| Evaluate

Use planning when:

• Problem is complex

• Many dependencies exist

• Tool usage may be extensive

• Mistakes early in execution are expensive

Do not over-plan. Simple task? Just execute it.

Exam principle: Complexity should be justified by the problem.

10. Single Agent vs Multi-Agent

Prefer Single Agent when

• One agent can handle the task

• Tools provide the needed capabilities

• Context fits comfortably

• Coordination overhead is not justified

Consider Multiple Agents when

• Independent subtasks benefit from specialization

• Different contexts should remain isolated

• Work can happen concurrently

• One orchestrator needs specialized workers

• The overall problem is too broad for one agent to handle effectively

Major trade-off: Multi-agent systems can improve capability but usually increase:

• Cost

• Latency

• Coordination complexity

• Debugging difficulty

• Failure possibilities

Exam instinct: If one agent works, do not automatically choose five.

11. Human-in-the-Loop

Human approval belongs at important control boundaries.

Examples:

Claude analyzes loan -> Human approves decision

Claude drafts database change -> Human approves -> System executes

Good reasons for human intervention:

• Irreversible action

• Financial consequence

• Security-sensitive action

• Regulatory/compliance impact

• High uncertainty

• Significant real-world consequence

Exam clue words: irreversible; high impact; sensitive; approval; regulated; high risk.

Memory hook: READ can often automate. WRITE may need a gate. Not an absolute rule - useful exam intuition.

12. Guardrails

Agents need boundaries.

WHAT can Claude do? WITH WHICH tools? UNDER WHAT conditions? HOW MANY times? WHEN must it stop? WHEN does a human intervene?

Typical architectural guardrails include:

• Restricted tool access

• Input validation

• Output validation

• Maximum iterations

• Timeouts

• Permission boundaries

• Human approval

• Logging/auditing

• Error handling

Exam principle: Do not give an agent more authority than the task requires.

13. Retries vs Fallbacks

Retry

Same operation again.

API fails temporarily -> Retry

Good for temporary/transient errors.

Fallback

Try another method.

Primary service unavailable -> Secondary service

Agent cannot confidently solve -> Human

Memory hook: Retry = again. Fallback = another way.

14. State

Agents may operate over many steps.

Context = information currently available to Claude.

Durable state = information stored outside the immediate model call so the application can recover or continue later.

Examples:

• Database

• Session store

• Checkpoint

• Job status

• Persistent memory

Exam scenario: "The agent must resume after an application restart."

Do not rely solely on conversation context. Use external durable state/checkpointing.

15. Cost / Latency / Reliability Triangle

Every extra model call costs something.

More agents

• More loops
• More evaluation
• More tool calls

= More cost + more latency + more failure opportunities

So do not choose the fanciest architecture. Prefer the simplest architecture that meets the reliability requirement.

Common CCAR-F Traps

The Six Patterns to Remember

Memory Shortcuts

CHAIN - Depends on previous output

ROUTE - Choose a lane

PARALLEL - Do independent things together

ORCHESTRATOR - Boss assigns workers

EVALUATOR - Teacher marks homework

AGENT - Figures out what to do next

Exam Scenario Examples

Scenario 1

A company receives support requests for Billing, Technical issues, and Account problems. Each has a specialized prompt and tools.

Answer: ROUTING

Why: Known categories -> select predefined path.

Scenario 2

Claude needs to investigate an unfamiliar software repository. It decides which files to inspect, runs tests, searches code and changes its plan based on what it discovers.

Answer: AGENT

Why: Next steps cannot be fully predetermined.

Scenario 3

Analyze 50 independent documents and combine the findings.

Answer: PARALLELIZATION

Why: Each document can be analyzed independently.

Scenario 4

Generate a report, score it against explicit requirements and repeatedly revise it until it passes.

Answer: EVALUATOR-OPTIMIZER

Why: Generate -> critique -> improve.

Scenario 5

Claude receives an unfamiliar engineering problem and decides that database, security and API specialists are required.

Answer: ORCHESTRATOR-WORKERS

Why: The subtasks are determined dynamically.

Scenario 6

Extract fields from an invoice, validate them, calculate totals, then produce a structured record.

Answer: WORKFLOW / PROMPT CHAINING

Why: The sequence is known beforehand.

Night-Before-Exam Version

One Sentence That Solves Half the Domain

Use deterministic workflows when you know what needs to happen; give Claude agentic control only when the problem requires Claude to decide what should happen next.

60-Second Self-Test

• [ ] Can I explain workflow vs agent without notes?

• [ ] Can I distinguish routing from orchestration?

• [ ] Can I tell sequential work from parallel work?

• [ ] Do I recognize evaluator-optimizer from scenario wording?

• [ ] Do I know retry vs fallback?

• [ ] Do I add human approval for high-impact actions?

• [ ] Do I prefer the simplest reliable architecture instead of maximum autonomy?

Source Notes

This cheat sheet is based on the Domain 1 explanation provided in our study discussion and aligns with Anthropic's public guidance on building effective agents and agent patterns. For exam prep, use it alongside the official CCAR-F exam objectives and current Anthropic Academy/course material.

Anthropic - Building Effective Agents: https://www.anthropic.com/research/building-effective-agents

Anthropic Documentation / Cookbook: https://docs.anthropic.com/

---

Domain 2 — Tool Design & MCP Integration

CCAR-F DOMAIN 2

Tool Design & MCP Integration

Complete Printable Cheat Sheet

Designed for study alongside the 2026 CCAR-F exam-prep course and for rapid review before the exam.

How to use this document

- During the course: keep this beside you and map each lecture concept to the decision rules here. - For practice questions: identify the clue words first, then choose the simplest tool/MCP design that preserves correctness and safety. - Before the exam: use the Rapid Review and Common Traps sections instead of rereading every page. - Version note: MCP changed materially on July 28, 2026. This sheet emphasizes stable architectural concepts and flags version-specific details separately.

EXAM RULE: Domain 2 is not primarily a coding test. It is an architecture and behavior test: which capability should exist, how Claude should discover/select it, what schema and description reduce ambiguity, and what the system should do when a call succeeds, fails, or has side effects.

1. Domain 2 in One Page

The core mental model

USER REQUEST

|

v

CLAUDE / HOST

| chooses capability

v

TOOL or MCP PRIMITIVE

|

+--> ACTION / API / DATABASE / FILE / SERVICE

|

v

STRUCTURED RESULT OR STRUCTURED ERROR

|

v

CLAUDE decides next step

The 10-second decision tree

MEMORY HOOK: Tool = DO. Resource = READ. Prompt = GUIDE.

EXAM RULE: The model should not have to guess tool boundaries, valid arguments, whether a failure is retryable, or whether a call has dangerous side effects. Good architecture makes those facts explicit.

2. MCP Foundations

What MCP is

Model Context Protocol (MCP) is an open standard that lets AI applications connect to external systems through a consistent protocol. It standardizes how applications discover and use capabilities such as tools, resources, and prompts instead of requiring a one-off integration contract for every service.

Why MCP matters for the exam

- It separates the AI host from the implementation details of external systems. - It provides discoverable, typed capabilities rather than vague natural-language integrations. - It makes the same server potentially usable by multiple compatible AI hosts. - It creates clear security and authorization boundaries around access to external data and actions.

MCP architecture: Host, Client, Server

MEMORY HOOK: HOST coordinates. CLIENT connects. SERVER provides.

TRAP - Host vs Client: The user-facing AI app is the host. The MCP client is the protocol component the host creates to communicate with a specific server.

MCP is not the model

MCP does not replace Claude, agent logic, or your business rules. It is the integration protocol between the host and external capability providers. The host/model still decides what context to use and which tools to invoke, subject to application policy and user approval.

3. MCP Primitives: Tools vs Resources vs Prompts

This distinction is extremely exam-friendly because multiple options may sound plausible. Classify by intent, not implementation technology.

Tool

- Use when Claude needs to invoke an operation on demand. - A tool has a name, description, and input schema; results flow back to Claude. - Tools may be read-only (lookup) or side-effecting (send, update, delete, pay). - Tool descriptions are selection signals: they tell Claude when and why the tool should be chosen.

Resource

- Use for data that should be read as context rather than treated as an operation. - Resources are identified by URI and may represent files, database schemas, application-specific information, or other contextual data. - Resources can be surfaced in pickers, searched, filtered, or automatically included according to host policy.

Prompt

- Use for reusable, server-defined prompt templates or structured messages. - Prompts may take arguments to customize the template. - In MCP, prompts are designed to be user-controlled: think discoverable commands/templates rather than autonomous actions.

Primitive selection examples

TRAP - Everything is a tool: Do not expose static/reference content or reusable instruction templates as tools merely because they come from a server. Use the primitive that matches intent.

EXAM RULE: If the question says "perform", "create", "send", "update", "query live data", or "execute", think Tool. If it says "reference/read context", think Resource. If it says "reusable template/command", think Prompt.

4. Tool Use Contract

Tool use is a typed contract between the model and the application. Claude selects a tool and emits structured arguments. The application or server executes the operation and returns a result. Claude does not magically execute arbitrary external code by itself.

1. Application supplies tool definitions 2. Claude chooses whether/which tool to call 3. Claude emits structured tool_use + arguments 4. Tool executes outside the model (client or server side) 5. Result returns to Claude 6. Claude uses result and decides whether more calls are needed

Client tools vs server tools in the Claude API

Why this matters

- Know where credentials, permissions, and side effects actually live. - A model-generated tool request is not proof that the operation succeeded; success comes from the tool result. - Your application still owns validation, authorization, logging, retries, idempotency, and user confirmation policy.

EXAM RULE: Never confuse "Claude requested the tool" with "the tool action completed." Architecture must inspect and return the actual execution result.

5. Designing Excellent Tool Definitions

Claude primarily selects tools from their names, descriptions, argument names, argument descriptions, and surrounding prompt/context. A precise description is one of the highest-leverage reliability improvements.

An effective tool definition answers six questions

- WHAT does the tool do? - WHEN should Claude use it? - WHEN should Claude NOT use it? - WHAT does each input mean, including format/range/units? - WHAT does the tool return? - WHAT limitations, boundaries, and edge cases matter?

Weak vs strong description

Naming

- Use action-oriented, unambiguous names: get_order, search_customers, create_ticket. - Use meaningful namespacing when tools span services: github_list_prs, slack_send_message, jira_create_issue. - Avoid near-duplicates whose boundaries are unclear: search_user, find_user, lookup_user unless each has a very distinct role.

Descriptions vs examples

Descriptions are the primary tool-selection signal. Input examples are useful when the schema is complex, nested, optional-heavy, or format-sensitive, but examples should reinforce a clear description rather than replace it.

TRAP - Implementation detail instead of user intent: "Reads from table CUSTOMER_X9" is not a useful selection description. Tell Claude what capability it provides, what it returns, and when to use it.

TRAP - Vague boundaries: If two tools look interchangeable, Claude has to infer the distinction. Make boundaries explicit or consolidate the operations.

EXAM RULE: On a multiple-choice question, the strongest tool description usually contains purpose + use-when condition + parameter meaning + return behavior + important boundaries.

6. Input Schemas: Make Invalid Calls Hard to Produce

A tool input schema is the contract for arguments. Use JSON Schema to describe the shape and constrain values. The goal is not maximum complexity; it is enough structure to prevent ambiguous or malformed calls.

High-value schema rules

- Use the correct primitive type: string, number/integer, boolean, array, object. - Put truly mandatory fields in required. - Use enum for a closed set such as currency, action type, status, region, or sort order. - Add field descriptions explaining semantics, units, expected formats, and cross-field rules. - Avoid one giant free-form string when structured parameters are available. - Do not require data the operation does not need; unnecessary required fields increase friction and failure. - For complex/nested inputs, provide valid examples when supported.

Example: weak schema

{

"name": "process_order",

"input_schema": {

"type": "object",

"properties": {

"data": {"type": "string"}

}

}

}

Problems: the operation is unclear, data is unstructured, no required field is declared, and Claude must invent an encoding.

Example: stronger schema

{

"name": "update_order_status",

"input_schema": {

"type": "object",

"properties": {

"order_id": {

"type": "string",

"description": "Existing order identifier, e.g. ORD-12345"

},

"status": {

"type": "string",

"enum": ["processing", "shipped", "cancelled"]

}

},

"required": ["order_id", "status"]

}

}

Strict tool use

The Claude API supports strict tool use for custom tools. With strict schema enforcement enabled, tool calls must conform to the declared schema. Treat this as a reliability mechanism, not a substitute for authorization or business-rule validation.

Schema vs business rules

Schema validation answers "is this argument structurally valid?" Business validation answers "is this operation permitted and logically valid?" Example: an amount may be a valid number but still exceed a refund limit. You need both layers.

TRAP - Claude will infer it: Do not leave a closed set as a free-form string or omit important constraints merely because the model may guess correctly.

TRAP - Schema equals authorization: A valid schema does not mean the user is allowed to perform the operation. Authorization remains separate.

EXAM RULE: Prefer schemas that constrain exactly what can be known in advance, while leaving true business decisions to validated server-side logic.

7. Tool Selection, Tool Choice, and Tool Distribution

Tool reliability is partly a catalog-design problem. Claude chooses better when available tools are relevant, distinguishable, and not bloating context.

Claude API tool_choice

How many tools?

Do not memorize a magical fixed number. The stable principle is: as the tool catalog grows, especially with overlapping definitions, tool-selection accuracy and context efficiency degrade. Scope tools to the task, use specialized agents or groups where appropriate, and use on-demand tool discovery/search at large scale.

Current Anthropic guidance supports tool search for very large catalogs, loading only a small relevant subset instead of placing hundreds or thousands of definitions into the context window.

Strategies for large tool catalogs

- Scope: give an agent only the capabilities relevant to its job. - Consolidate: combine tightly related operations behind an action parameter when this reduces ambiguity. - Namespace: identify service/domain clearly in tool names. - Discover on demand: search/load relevant tools instead of always loading the entire catalog. - Specialize: distribute distinct business capabilities across specialized subagents when orchestration justifies it.

Consolidate vs split

TRAP - Fixed "4-5 tools" rule: Some study material presents a small preferred count as an absolute. For the exam, remember the deeper rule: minimize irrelevant/ambiguous tools and manage large catalogs deliberately. Current Anthropic tooling supports on-demand discovery at scale.

EXAM RULE: If a question gives one agent dozens of unrelated tools, the answer is usually to reduce the exposed surface, specialize, consolidate sensibly, or discover tools on demand - not merely to write a longer system prompt.

8. Parallel Tool Use

Claude can request multiple tool calls in one turn. Parallelism is valuable when operations are independent and safe to execute concurrently.

Parallelism and tool_choice

The API can allow or disable parallel tool calls. If parallel use is disabled, auto mode allows at most one tool call in a response, while a forced tool-choice mode can require exactly one. The exam-level principle is dependency and safety, not memorizing every parameter interaction.

TRAP - Faster = always better: Do not parallelize dependent calls or side-effecting actions merely to reduce latency.

EXAM RULE: Independent + safe = parallel candidate. Dependency or ordering requirement = sequential.

9. Tool Results and Structured Error Handling

A good tool result gives Claude enough information to continue correctly without flooding the context window. A good error tells Claude what failed and what recovery path is sensible.

Return high-signal results

- Return only fields relevant to reasoning or the next operation. - Use stable semantic identifiers such as order IDs, slugs, or UUIDs where possible. - Clearly distinguish result data from metadata and error information. - Avoid dumping huge raw API responses if a compact structured summary is sufficient. - Preserve data needed for the next step; over-trimming can force extra calls.

The critical distinction: empty result vs failed access

Claude tool_result error signaling

In Claude tool-use flows, a tool result can explicitly indicate an error (for example, is_error on the tool_result). The content should still explain the failure clearly enough for the model to recover or report it. In MCP, tool results also have defined error-handling semantics. The architecture goal is the same: never disguise an execution failure as a successful empty result.

Useful structured error fields

Your application-level error payload can include fields such as:

- error_code / category: stable machine-readable classification. - message: concise explanation of what failed. - retryable: whether repeating the same operation might succeed. - suggested_action: retry later, request missing input, use another tool, or escalate. - context: what operation/identifier was attempted, without exposing secrets. - details safe for the model: validation information or allowed values.

{

"error_code": "RATE_LIMITED",

"message": "Order service rate limit reached.",

"retryable": true,

"suggested_action": "Retry with backoff",

"context": {"operation": "lookup_order", "order_id": "ORD-12345"}

}

Retryability examples

TRAP - Return \[\] when service is down: An empty result asserts the search succeeded. If access failed, signal failure explicitly.

TRAP - Generic "Operation failed": A message with no category or recovery information forces Claude to guess whether to retry, change input, or escalate.

EXAM RULE: The agent must be able to distinguish: success-with-no-data, invalid input, auth failure, transient infrastructure failure, and business-rule rejection.

10. Idempotency, Side Effects, and Safe Retries

This is where traditional distributed-systems thinking pays off. Agentic systems can retry, parallelize, or revisit steps. Tool design must make repeated calls safe or explicitly prevent them.

Idempotent vs side-effecting

Safeguards for side-effecting tools

- Use idempotency keys or request IDs where the underlying service supports them. - Require explicit user confirmation for consequential/irreversible operations. - Separate preview/validate from execute when useful. - Validate permissions and business rules server-side immediately before execution. - Log/audit who requested the operation and the result. - Avoid ambiguous retry behavior; return enough information to know whether an effect may already have occurred.

The uncertain-outcome problem

Suppose a payment request times out after being sent. You do not know whether the processor completed it. A blind retry can duplicate the charge. Correct architecture uses an idempotency key or queries transaction state before trying again.

EXAM RULE: Retries are an architectural decision, not an automatic response to every error. Ask: Is the tool idempotent? Could the first attempt have had a side effect? Can we prove whether it completed?

11. MCP Server Configuration and Transports

For CCAR-F, focus on why you would choose a local vs remote server and what security/configuration boundary that creates. Do not over-index on version-specific wire details.

STDIO vs Streamable HTTP

MEMORY HOOK: Local process -> STDIO. Remote service -> Streamable HTTP.

Claude Code configuration scopes - exam intuition

Claude Code can configure MCP servers at different scopes. Project-shared MCP configuration belongs with the project so teammates can use the same server definition, while user-level configuration is appropriate for personal integrations. Exact configuration-file precedence is covered more deeply in Domain 3; here, remember the security/design distinction: project configuration should not embed personal secrets.

Do not store secrets in shared config

- Use environment variables, credential managers, OAuth, or another appropriate secret mechanism. - Treat project MCP configuration as potentially committed/shared. - Grant the server only the credentials/scopes it actually requires.

2026 MCP protocol update - know the concept, not trivia

The MCP 2026-07-28 specification removed protocol-level sessions and the old initialize/initialized handshake from the core HTTP flow, added server discovery, and changed parts of notification/state handling. Older courses and examples may still show previous lifecycle details. For exam prep, prioritize the stable concepts: host/client/server, tools/resources/prompts, local vs remote transport, capability discovery, structured requests/results, security, and explicit application state.

TRAP - Memorizing obsolete lifecycle details: If your course shows older session/handshake behavior, understand it as historical/version-specific unless the official exam guide explicitly requires that version.

12. MCP Security and Authorization

MCP makes external capabilities easy to connect; that makes permission design more important, not less. Treat every tool/resource boundary like an API-security boundary.

Least privilege

- Expose only required tools/resources. - Grant the narrowest scopes and data access that satisfy the workflow. - Keep read and write permissions distinct where possible. - Do not let a model bypass server-side authorization through prompt instructions. - Validate user identity and authorization at execution time, not only when the server was configured.

Human approval

The MCP tools specification emphasizes keeping humans able to deny tool invocations and making tool exposure/invocation visible. For high-impact actions, the host should provide confirmation or another explicit approval gate.

Remote MCP authorization

For HTTP-based MCP servers, authorization follows OAuth-style patterns in the MCP specification. Exam intuition: user-specific or enterprise data/actions require authenticated, scoped access. Local STDIO servers commonly obtain credentials from the environment or local secure configuration instead of using the HTTP authorization flow.

Prompt injection and untrusted tool content

- Treat tool/resource output as data, not automatically trusted instructions. - Do not let retrieved content expand permissions or override system/business policy. - Validate URLs, file paths, identifiers, and actions before execution. - Prefer allowlists and narrow operations for sensitive domains. - Keep secrets out of model-visible results unless genuinely required.

Security decision matrix

EXAM RULE: Tool descriptions influence model behavior; authorization controls what is actually allowed. Never use prompt text as the sole security boundary.

13. Claude Code Built-in Tool Selection

Some CCAR-F Domain 2 material tests whether you choose the purpose-built Claude Code operation rather than shelling out unnecessarily. Names/capabilities can evolve, so remember the functional distinctions.

MEMORY HOOK: Grep = content. Glob = filenames/paths. Edit = targeted change. Bash = actual shell command.

TRAP - Use Bash for everything: If a dedicated tool exists for reading, editing, or searching files, purpose-built tools are usually clearer and safer than shell equivalents. Bash is appropriate for commands that genuinely require the shell.

Built-in tools vs MCP tools

Built-in Claude Code tools provide native development-environment capabilities. MCP extends Claude Code to external systems and custom services. A question asking how to connect to an organization-specific API or SaaS capability is often pointing to MCP/custom tooling, not abusing Bash to curl everything manually.

14. Common Domain 2 Exam Traps

TRAP - Vague tool description: "Gets data" is not enough. Prefer explicit purpose, use conditions, arguments, return behavior, and boundaries.

TRAP - Too many overlapping tools: More tools are not automatically more capable. Reduce ambiguity through scoping, grouping, naming, or on-demand discovery.

TRAP - Empty result hides failure: A failed database connection is not the same as a successful search with zero records.

TRAP - Retry everything: Auth errors, invalid inputs, business-rule rejection, and uncertain side effects should not be blindly retried.

TRAP - Everything is a Tool: Reference content -> Resource; reusable instruction template -> Prompt.

TRAP - Schema is optional documentation: Schema constrains model-generated arguments. Use types, required fields, enums, and descriptions.

TRAP - Schema is security: Schema validation does not authorize an operation.

TRAP - Tool call means success: A requested tool can fail; the execution result is authoritative.

TRAP - Parallel is always faster/better: Only parallelize independent, safe work.

TRAP - Secrets in project config: Shared MCP config must not contain personal/static credentials.

TRAP - Prompt instructions enforce permission: Server-side authorization and application policy must enforce permission.

TRAP - Local vs remote does not matter: Transport affects deployment, credentials, authorization, availability, and threat model.

TRAP - Memorize obsolete MCP handshake details: Prioritize stable architecture; protocol lifecycle changed in July 2026.

15. Scenario Drills

Try to answer each scenario before reading the explanation.

1. Customer lookup ambiguity

Scenario: An agent has search_customer, find_customer, lookup_customer, and get_customer tools with nearly identical one-line descriptions. It often picks the wrong one.

Best answer: Redesign the tool surface. Consolidate truly equivalent operations or make each boundary explicit with meaningful names/descriptions. The problem is catalog ambiguity, not insufficient prompting.

2. Database outage

Scenario: The customer database is offline. The lookup tool returns customers: \[\] so the agent says the customer does not exist.

Best answer: Return an explicit execution error. An empty result means a successful search found nothing; an outage means the system could not check.

3. Refund timeout

Scenario: A refund call times out after reaching the payment processor.

Best answer: Do not blindly retry. Use an idempotency key or query transaction state first because the first call may have completed.

4. Policy document

Scenario: You need Claude to reference a static internal reimbursement policy.

Best answer: Expose as a Resource (or otherwise provide it as context), not a side-effecting tool.

5. Incident template

Scenario: Operations wants a discoverable reusable template for "Create incident postmortem".

Best answer: Expose as an MCP Prompt: reusable structured instructions that a user can select/invoke.

6. Send email

Scenario: Claude needs to send an external email after user approval.

Best answer: Tool. Treat as side-effecting, validate recipient/content/permission, and require approval according to policy.

7. 300 MCP tools

Scenario: The host connects to dozens of servers and loads hundreds of definitions on every turn. Context cost and selection quality degrade.

Best answer: Use tool discovery/search or other just-in-time loading and scope tools to the task instead of loading every definition.

8. Fixed status field

Scenario: A tool accepts status as any string, but the backend only supports open, pending, closed.

Best answer: Use an enum in the schema. This prevents malformed values before execution.

9. Independent lookups

Scenario: The user asks for balances from four independent read-only accounts.

Best answer: Parallel tool calls are appropriate if each lookup is independent and allowed.

10. Create then update

Scenario: A tool creates a ticket and returns the new ticket ID; another adds an attachment.

Best answer: Sequential: attachment call depends on the created ticket ID.

11. Remote enterprise MCP

Scenario: A remote MCP server exposes employee HR records.

Best answer: Use authenticated/scoped authorization and enforce permissions server-side. Do not rely on the system prompt to restrict access.

12. Local developer MCP

Scenario: A local server needs a GitHub token.

Best answer: Use environment/secure credential storage; do not commit the token into shared project MCP configuration.

16. "If You See X, Think Y"

17. Night-Before Rapid Review

Memorize these

- Tool = action/dynamic operation. Resource = readable context. Prompt = reusable instruction template. - Host = AI app. Client = connector to one MCP server. Server = provider of capabilities. - A good tool description says what it does, when to use it, what inputs mean, what it returns, and important boundaries. - Use correct JSON Schema types, required fields, enums for closed sets, and descriptions. Strict schema can improve conformance but is not authorization. - Tool call requested != operation succeeded. Trust the tool result. - Successful zero matches != access failure. Never hide infrastructure failure as an empty success result. - Retry transient failures only when safe. Side effects require idempotency/confirmation/state checks. - Independent safe calls -> parallel. Dependencies -> sequential. - Large tool catalogs -> scope, specialize, consolidate sensibly, or discover tools on demand. - STDIO -> usually local process. Streamable HTTP -> usually remote server. - Remote/user-specific sensitive data -> proper authorization and scopes. Project config should not contain secrets. - Prompt text is not a security control. Authorization/business validation belongs in application/server logic. - Grep = content; Glob = paths; Edit = targeted modification; Bash = actual shell work. - MCP changed July 28, 2026: do not over-memorize obsolete session/handshake details.

Five questions to ask on every Domain 2 scenario

1. What primitive/capability is actually required?

2. How can I make selection and input generation unambiguous?

3. What does success vs failure look like?

4. Can this call be retried or parallelized safely?

5. What permissions, approval, and state safeguards are required?

EXAM RULE: Choose the design that gives Claude the clearest contract while preserving deterministic validation, least privilege, safe side effects, and truthful error signaling.

18. Official References Used for This Sheet

These are the primary sources to revisit if a practice question conflicts with third-party study material:

- Anthropic Academy - Claude Certified Architect - Foundations (official domain weighting; Domain 2 = Tool Design & MCP Integration, 18%). - Claude Platform Docs - Tool use with Claude / How tool use works / Define tools / Parallel tool use / Tool search. - Model Context Protocol - 2026-07-28 specification: Architecture, Tools, Resources, Prompts, Authorization, and Key Changes. - Claude Code Docs - Connect Claude Code to tools via MCP.

Study note

Certification questions may lag the newest protocol release. If a course or practice bank disagrees with the current MCP specification on lifecycle/session details, prioritize the official CCAR-F exam guide for what the exam expects. The stable design principles in this document remain the main study target.

---

Domain 3 — Claude Code Configuration & Workflows

CCAR-F

Domain 3 Claude Code Configuration & Workflows

COMPLETE CHEAT SHEET

Exam-oriented • Scenario-based • Print-friendly

THE CORE IDEA Use the right control surface for the job: persistent guidance belongs in CLAUDE.md, enforceable behavior in settings/permissions/hooks, reusable procedures in Skills, isolated specialist work in subagents, and automation in non-interactive workflows.

Domain focus: configuration scopes • CLAUDE.md • permissions • plan mode • hooks • skills • subagents • sessions • CI/CD • worktrees • verification

Current-product details can evolve faster than certification exams. Prioritize the architectural distinctions and scenario rules; version-specific notes are marked as current-reference items.

1. Domain 3 Mental Model

Claude Code is an agentic coding environment: it can inspect a repository, read files, edit files, run commands, use integrations, and iterate until a task is complete. Domain 3 tests how you configure and operationalize that behavior safely and repeatably.

EXAM MEMORY HOOK Instructions = what Claude should know. Settings/permissions = what Claude may do. Hooks = what must happen deterministically. Skills = reusable procedures. Subagents = isolated specialist contexts.

The six surfaces you must not confuse

The fastest discriminator If the requirement says "Claude should usually follow this," think instruction. If it says "Claude must not be allowed to violate this," think permissions or a blocking hook.

2. CLAUDE.md — Persistent Instructions

CLAUDE.md is persistent context, not an enforcement mechanism. Claude reads it to understand project conventions, architecture, commands, and workflows. Because it consumes context, concise and specific instructions work better than long prose.

Where CLAUDE.md belongs

Load-order concept Broad instructions load before more specific project instructions. Nested CLAUDE.md files can apply contextually as Claude enters subdirectories. Think "broad → specific."

What belongs in CLAUDE.md

• Build, test, lint, and validation commands that should be remembered every session.

• Repository layout and architectural constraints.

• Naming, formatting, framework, and coding conventions.

• Workflow expectations such as “run tests before finishing.”

• Project facts you would otherwise keep re-explaining.

What does NOT belong there

• A hard security boundary that must be enforced regardless of model behavior → use permissions or hooks.

• A long multi-step procedure used only occasionally → use a Skill so the body loads on demand.

• A rule that applies only to a narrow path/file type → prefer path-scoped project rules.

• Secrets, credentials, or sensitive values.

• Huge reference manuals that consume context every session.

Practical quality rule Anthropic currently recommends concise, specific, structured CLAUDE.md content and targets under roughly 200 lines per file. Treat that as a quality heuristic, not a magic exam number.

Example project CLAUDE.md # Build and test - Run npm test before completing code changes. - Run npm run lint after editing TypeScript. # Architecture - API handlers live in src/api/handlers/. - Do not access the database directly from UI components.

3. CLAUDE.md Organization, Imports & Rules

/init

Use /init to bootstrap project instructions. Claude analyzes the repository and proposes a starting CLAUDE.md based on discovered build commands and conventions. If a CLAUDE.md already exists, current Claude Code suggests improvements rather than simply overwriting it.

Imports

CLAUDE.md can import other files with @path syntax. Imports help organize content, but imported content still enters the startup context. Therefore imports organize instructions; they do not necessarily save tokens.

### CLAUDE.md

@docs/architecture.md

@package.json

Use the architecture rules above when modifying services.

Exam trap Moving 500 lines from CLAUDE.md into an imported file does NOT magically make it lazy-loaded. If the content is only needed for a procedure, a Skill is usually the better mechanism.

Path-scoped rules

For large repositories, use project rules when guidance only applies to certain files or directories. This avoids forcing every instruction into every task and helps reduce conflicting guidance.

4. Settings Scopes & Precedence

settings.json controls Claude Code behavior. You need to know both scope and precedence because the exam can describe a requirement and ask where it belongs.

Four main scopes

Precedence — memorize this

Highest → Lowest MANAGED → CLI ARGUMENTS → LOCAL → PROJECT → USER

Scalar settings generally follow the highest-priority applicable value. Permission rules are special: they can merge across scopes rather than acting like a simple scalar override.

Exam clue If the policy "cannot be overridden by developers," the answer should usually involve managed configuration, not a project CLAUDE.md.

5. Permissions — What Claude May Do

Permissions are the safety boundary around tool use. The core design question is whether an action should be allowed automatically, require approval, or be denied.

Rule intent

Strong exam rule DENY is stronger than “please do not” in CLAUDE.md. If the requirement is a security control, enforce it.

Permission modes

Current-reference note: Claude Code permission modes have evolved in 2026. The exam-relevant concept is the approval boundary: read-only/planning, normal approval, safe edit automation, fail-closed unattended automation, and isolated-environment bypass.

DO NOT confuse acceptEdits is not the same as bypassPermissions. Accepting edits does not mean “allow everything.” Bypass mode is intentionally dangerous and should be isolated.

6. Plan Mode — Analyze Before Editing

Plan mode is a high-value exam concept because it creates a clear human approval boundary. Claude may inspect the codebase and propose a plan, but it does not make edits until the plan is approved.

Start in plan mode:

claude --permission-mode plan

Interactive shortcut:

Shift+Tab cycles through common modes, including plan mode.

Memory hook PLAN = READ + REASON + PROPOSE. Editing waits for approval.

7. Hooks — Deterministic Lifecycle Control

Hooks execute automatically at defined Claude Code lifecycle events. Their key value is deterministic behavior: if something must happen every time, do not rely on Claude remembering to choose it.

Core distinction CLAUDE.md says “please follow this.” A hook says “this action executes at this event.”

Exam favorite “Must block the command before it executes” → PreToolUse. “Always format after editing” → PostToolUse.

Hooks can be command-based and, in current Claude Code, may also use HTTP or model-based evaluation for cases that need judgment. For exam scenarios, prefer deterministic command/hooks when the rule itself is deterministic.

Conceptual hook:

PreToolUse(Bash)

→ inspect command

→ if destructive or policy violation: BLOCK

→ otherwise: allow normal permission flow

Security principle Hooks execute code. Treat hook configuration and scripts as privileged project infrastructure: review them, avoid secrets in source, and scope permissions carefully.

8. Skills — Reusable Procedures Loaded on Demand

Skills extend Claude Code with reusable instructions and optional supporting files. A Skill is ideal when you repeatedly use the same checklist, workflow, or domain procedure but do not need it in context for every task.

Memory hook CLAUDE.md = facts/rules always relevant. SKILL.md = procedure relevant only sometimes.

• Skill body loads when invoked/relevant instead of consuming full context every session.

• Skills can be invoked directly as slash commands, depending on configuration.

• Skills can include supporting files and executable instructions.

• Current Claude Code merges legacy custom commands into the Skills model; older .claude/commands files can still work.

9. Subagents — Specialist Work in Isolated Context

Subagents are delegated Claude instances with their own context. Use them when a task benefits from specialization, restricted tools, or isolating large amounts of investigation from the main conversation.

Why subagents matter Large research reads consume context. A subagent can inspect many files in its own context and return only the findings to the parent session.

A custom subagent can define a prompt, model, tool restrictions, permission mode, hooks, and skills. This makes subagents useful for least-privilege specialization.

Exam distinction Subagent = separate context for delegated work. Skill = reusable procedure. A Skill can even be preloaded into a subagent; they solve different problems.

10. MCP in Claude Code — Domain 3 View

Domain 2 covers MCP in depth. For Domain 3, remember how Claude Code uses MCP operationally: MCP servers add external tools and data sources to the coding workflow, and configuration scope determines who gets the integration.

Exam trap MCP gives Claude capabilities; it does not replace permission design. “Claude can call it” and “Claude may call it without approval” are separate questions.

11. Sessions, Resume & Interactive Workflows

A Claude Code session contains the conversation and tool history for a task. You can continue or resume work without re-explaining everything, but session history is not a substitute for durable project instructions.

Exam principle Persistent team rules belong in CLAUDE.md, not only in a long-running chat. Conversation history can be compacted or cleared; project instructions should survive.

12. Non-Interactive Mode, CI/CD & Automation

Non-interactive mode runs Claude Code programmatically. This is the bridge from “developer at a terminal” to CI jobs, pre-commit checks, batch tasks, and scripts.

One-shot automation:

claude -p "Review this diff for security issues"

JSON for scripts:

claude -p "List API endpoints" --output-format json

Structured schema:

claude -p "Extract findings" --output-format json --json-schema '{...}'

Unattended automation rule CI cannot rely on a human being present to click “Allow.” Pre-approve only the minimum required tools, use fail-closed behavior for everything else, and isolate the environment.

For automation, structured outputs are safer than parsing prose. Combine deterministic validation, explicit permission boundaries, budget/turn limits, and a narrow task scope.

13. Worktrees & Parallel Claude Code Sessions

Parallel sessions can accelerate independent work, but concurrent edits to the same checkout create collisions. Git worktrees isolate each session in a separate checkout/branch.

Start an isolated session:

claude --worktree feature-auth

### shorthand: claude -w feature-auth

Do not confuse Worktree solves EDIT ISOLATION. Subagent solves CONTEXT / DELEGATION. They can be used together.

• Use parallelism for independent tasks, not tightly coupled edits to the same code.

• Prefer separate worktrees when concurrent sessions might touch overlapping files.

• Review and integrate branches intentionally; parallel speed does not remove merge/review responsibility.

14. Verification Loops & Claude Code Best Practices

Anthropic’s current best-practice guidance emphasizes giving Claude a way to verify its own work. The agent is more effective when success is observable through tests, builds, linters, screenshots, or other deterministic checks.

High-yield pattern EXPLORE → PLAN (when needed) → IMPLEMENT → VERIFY → FIX → RE-VERIFY

Exam principle A model-generated claim that “the change works” is weaker than an observable verification step. Prefer architecture that lets Claude run or inspect objective checks.

15. Security, Sandboxing & Least Privilege

Claude Code is powerful because it can act on the development environment. Architecture must control blast radius: permissions, sandboxing, scoped credentials, hooks, managed settings, and isolated automation environments all contribute.

Least privilege Grant only the tools, paths, commands, and network access required for the task. More autonomy should come with tighter environmental boundaries, not broader trust.

16. Common CCAR-F Domain 3 Traps

1. TRAP: “Put the security rule in CLAUDE.md.” → Wrong when the rule must be enforced. Use permissions or a blocking hook.

2. TRAP: “Project settings are highest priority.” → Managed policy and session CLI overrides can take precedence; local can override project for ordinary settings.

3. TRAP: “Local settings should be committed so everyone shares them.” → Local is intended for personal project-specific overrides; project settings are the team-shared layer.

4. TRAP: “A Skill is just a big CLAUDE.md.” → No. Skills are reusable/lazy-loaded procedures; CLAUDE.md is persistent context.

5. TRAP: “Subagents and worktrees are the same isolation.” → No. Subagents isolate model context; worktrees isolate file edits/checkouts.

6. TRAP: “acceptEdits means no permissions.” → No. It is not equivalent to bypassPermissions.

7. TRAP: “Plan mode is just a polite request not to edit.” → No. It is an explicit permission mode designed for read/explore + proposal before writes.

8. TRAP: “CI can pause and ask a user.” → Usually wrong. Design unattended runs to pre-allow narrowly or fail closed.

9. TRAP: “Imports make CLAUDE.md content free.” → No. Imported CLAUDE.md content still loads into context.

10. TRAP: “MCP integrations bypass Claude Code security.” → No. Capability and permission are separate layers.

17. Scenario Drills — Pattern Recognition

1. A team wants every developer to use the same lint hook in one repository.

Answer: Project settings / project hook configuration. Why: Shared project behavior belongs in the repository.

2. Security requires Claude never execute \rm -rf\ on production paths.

Answer: Managed deny rule and/or deterministic PreToolUse blocking hook. Why: Hard enforcement beats instructions.

3. You want Claude to inspect a refactor and present a change plan before touching files.

Answer: Plan mode. Why: Read/explore/propose first; writes wait for approval.

4. You keep pasting the same deployment checklist into chat.

Answer: Project Skill. Why: Reusable procedure that should load only when needed.

5. Claude repeatedly forgets where service interfaces live.

Answer: Project CLAUDE.md. Why: Persistent project fact/instruction.

6. A security research task requires reading hundreds of files but you want the main conversation clean.

Answer: Subagent. Why: Separate context returns summarized findings.

7. Two Claude sessions need to implement unrelated features simultaneously in the same repo.

Answer: Separate worktrees. Why: Isolate file edits and branches.

8. A CI job needs machine-readable findings.

Answer: claude -p with JSON/structured output. Why: Programmatic non-interactive automation.

9. An unattended CI job tries an action not pre-approved.

Answer: Deny/fail closed rather than wait indefinitely for a human. Why: Unattended systems need deterministic permission behavior.

10. A policy applies only to TypeScript files under src/api/.

Answer: Path-scoped rule. Why: Avoid polluting all sessions with narrowly relevant guidance.

11. Every edit should automatically run a formatter.

Answer: PostToolUse hook. Why: Deterministic action after editing.

12. A command must be inspected before execution and blocked if it violates policy.

Answer: PreToolUse hook. Why: Decision must happen before the action.

13. A user wants a personal preferred model/configuration across all repositories.

Answer: User settings. Why: Personal cross-project scope.

14. IT must prevent a team from weakening a security setting in their repo.

Answer: Managed settings. Why: Highest policy layer; not repository-controlled.

15. A project needs access to Jira and a monitoring system.

Answer: MCP integrations plus appropriate permissions. Why: MCP supplies external capabilities; permissions still govern actions.

16. A long session is full of old debugging output and you are switching to an unrelated feature.

Answer: /clear or a new session. Why: Do not carry irrelevant context into new work.

17. A long but related task is nearing context pressure.

Answer: /context, then focused /compact as appropriate. Why: Preserve relevant task state while reducing context.

18. A developer wants no permission prompts at all on their laptop because they are annoying.

Answer: Do not choose bypassPermissions merely for convenience; use scoped permissions/sandboxing or safer modes. Why: Autonomy should not expand blast radius without isolation.

19. A repository-specific API expert should only have read/test tools and a specialized prompt.

Answer: Project subagent with restricted tools/permissions. Why: Role specialization + least privilege.

20. A 30-step monthly release procedure is currently stored in CLAUDE.md and bloating every session.

Answer: Move it to a Skill. Why: Procedure becomes on-demand instead of persistent context.

18. Night-Before Rapid Review

THE ONE-LINE MODEL Persistent knowledge → CLAUDE.md. Enforced behavior → settings/permissions/hooks. Reusable procedure → Skill. Specialist isolated context → subagent. Isolated parallel edits → worktree. Programmatic automation → claude -p.

Precedence: MANAGED → CLI → LOCAL → PROJECT → USER

Core permission idea: ALLOW safe known actions • ASK for consequential actions • DENY forbidden actions

Core workflow: EXPLORE → PLAN if needed → IMPLEMENT → VERIFY → FIX → RE-VERIFY

Final exam instinct When two answers both work, prefer the one that is simpler, more deterministic, least-privileged, and easier to verify.

19. Source & Currency Notes

This study sheet was checked against Anthropic’s official Claude Code documentation on 13 August 2026. The certification exam can lag behind rapidly evolving product details, so treat exact current CLI flags, newly added permission modes, and very recent defaults as reference knowledge unless your official CCAR-F course explicitly emphasizes them.

Primary Anthropic references used

• Claude Code: Settings and permissions

• Claude Code: How Claude remembers your project (CLAUDE.md and memory)

• Claude Code: Configure permissions / Permission modes

• Claude Code: Automate actions with hooks / Hooks reference

• Claude Code: Extend Claude with Skills

• Claude Code: Create custom subagents

• Claude Code: Common workflows and Best practices

• Claude Code: CLI reference / Run Claude Code programmatically

• Claude Code: Worktrees and parallel sessions

• Claude Code: MCP integration

• Claude Code: Security and sandboxing

How to study this domain 1) Read Sections 1–9 once. 2) Do the Udemy Domain 3 section. 3) Re-read only the mechanisms you missed. 4) Do scenario drills without looking at the answers. 5) Use Section 18 for the final refresh.

---

Domain 4 — Prompt Engineering & Structured Output

CCAR-F

DOMAIN 4

Prompt Engineering & Structured Output

Complete Cheat Sheet & Exam Study Guide

DOMAIN WEIGHT 20% of the CCAR-F exam blueprint Multiple-choice and multiple-response questions are scenario-oriented.

WHAT THIS DOCUMENT IS FOR Use this as the single Domain 4 reference while watching the course, then again for final review. It emphasizes decision rules and exam distinctions rather than memorizing marketing language.

The Domain 4 mental model

ONE SENTENCE TO REMEMBER Prompt engineering steers behavior; Structured Outputs constrain machine-readable shape.

1. The 30-Second Domain 4 Decision Tree

Is the problem that Claude misunderstands the TASK? → Improve prompt clarity, context, instructions, examples.

Is the problem that Claude returns the wrong STYLE/FORMAT? → State the desired format positively; show examples; use XML to separate sections.

Must the final response be VALID JSON matching a schema? → Use Structured Outputs (output_config.format).

Must TOOL ARGUMENTS match the tool schema? → Use strict tool use (strict: true).

Is the task too complex for one prompt and intermediate outputs matter? → Chain prompts / use a workflow.

Is the input huge (20k+ tokens / multiple documents)? → Put long data first, structure documents, put query/instructions after the data.

Do you lack a measurable definition of “good”? → Define success criteria + evals BEFORE endless prompt tweaking.

EXAM DEFAULT Choose the least complicated mechanism that directly solves the failure mode. Do not answer “add more prompt instructions” when the requirement is a hard machine-validated contract.

Prompting vs programmatic guarantees

2. Before You Prompt Engineer: Success Criteria & Evals

Anthropic’s prompt-engineering guidance starts with a prerequisite: define what success means and have a way to test it. Prompt engineering is not the first answer to every model problem.

The three prerequisites

1. Define explicit success criteria for the use case.

2. Create an empirical way to test those criteria (eval set, rubric, pass/fail checks, metrics).

3. Start from a real prompt that you can improve iteratively.

EXAM CLUE If a team keeps rewriting prompts based only on anecdotes, the best architectural next step is often to define an evaluation set and measurable success criteria.

What prompt engineering can vs cannot fix

Evaluation loop

Define success → Build test cases → Run prompt → Score output → Analyze failures ↑ ↓ └──────────── Improve ONE meaningful variable ───────┘

• Use representative cases, not only easy examples. • Include edge cases and likely production failures. • Change one major prompt variable at a time when you need to understand causality. • Prefer repeatable evaluation over “this prompt feels better.”

3. Anatomy of a Strong Claude Prompt

Not every prompt needs every element. The exam-oriented skill is knowing which element solves which problem.

Clear and direct

• Say exactly what outcome you want instead of expecting Claude to infer “above and beyond” behavior. • Be specific about output format and constraints. • Use numbered steps or bullets when order or complete coverage matters.

GOLDEN RULE If a capable colleague with minimal context would be confused by your prompt, Claude may be confused too.

Positive instructions beat vague prohibitions

When controlling format, tell Claude what to produce rather than only what to avoid.

4. Context, Motivation & System Roles

Why context helps

Explain why an instruction matters when that reasoning helps Claude generalize to cases you did not enumerate. Context can be more robust than a pile of brittle exception rules.

MEMORY HOOK Instruction = WHAT. Context = WHY. Example = SHOW ME.

Roles

A role in the system prompt can focus behavior and tone. Keep roles useful and job-relevant; avoid theatrical personas that add no decision value.

System: You are a senior fraud-operations analyst. Focus on evidence, uncertainty, and escalation criteria. Do not invent facts that are not present in the case record.

System prompt vs user prompt

EXAM TRAP A system role can steer behavior, but it is not an authorization boundary, database constraint, or safety control by itself. Enforce hard controls outside the model where appropriate.

Avoid role overload

• Do not stack conflicting identities or goals. • Put the most important behavioral constraints clearly and consistently. • For long system prompts, reinforce critical output expectations close to the task when useful.

5. Few-Shot Examples & XML Prompt Structure

Few-shot / multishot prompting

Examples are one of the most reliable ways to steer format, tone, and structure. Anthropic’s current best-practices guidance recommends 3–5 examples when examples are warranted.

Good examples are

• Relevant — closely resemble the real task. • Diverse — cover different cases and edge conditions so Claude does not infer an accidental pattern. • Structured — clearly separated from instructions and live input.

<examples>
  <example>
    <input>Server returned 429</input>
    <output>{"category":"rate_limit","retryable":true}</output>
  </example>
  <example>
    <input>Invalid API key</input>
    <output>{"category":"auth","retryable":false}</output>
  </example>
</examples>

EXAM CLUE If abstract instructions are being interpreted inconsistently, strong representative examples are often a better answer than adding more adjectives.

XML tags

XML tags help separate instructions, context, examples, and variable input in complex prompts. They are a parsing/organization technique, not a magical schema guarantee.

<instructions>Classify the incident.</instructions>
<context>Use only the supplied runbook.</context>
<examples>...</examples>
<input>...</input>

XML best practices

• Use descriptive, consistent tag names. • Nest tags where there is a natural hierarchy. • Keep user-provided content clearly separated from your instructions.

TRAP “Use XML tags” is not the answer to “must always return valid JSON matching this JSON Schema.” That is Structured Outputs.

6. Long-Context Prompting

Anthropic gives specific guidance for large documents or data-rich inputs, especially around 20k+ tokens.

Recommended structure

<documents>
  <document index="1">
    <source>policy-a.pdf</source>
    <document_content>...long document...</document_content>
  </document>
  <document index="2">...</document>
</documents>

<instructions>Compare the policies using only the documents.</instructions>
<question>Which policy has the stricter retention rule, and why?</question>

Key rules

1. Put longform documents/data near the top of the prompt.

2. Put the query and task instructions after the long source material.

3. Use XML structure for multi-document content and metadata.

4. For evidence-heavy tasks, have Claude identify relevant excerpts before synthesizing.

WHY THIS MATTERS The point is to make evidence easier to locate and separate source material from instructions. Long context is not an excuse to dump unstructured data into a prompt.

Grounding pattern

1. Identify the evidence relevant to the question.
2. State which source each piece of evidence came from.
3. Then produce the conclusion.
4. If the documents do not support a conclusion, say so.

Common traps

• Putting a critical question at the very beginning, followed by tens of thousands of tokens of data. • Mixing source text and instructions without boundaries. • Assuming a large context window automatically solves retrieval/relevance. • Asking for a confident answer even if the supplied evidence does not contain one.

7. Controlling Output Format Without Structured Outputs

Sometimes you want consistency, not a hard machine-validated JSON contract. Prompt techniques are still appropriate for prose, XML, templates, headings, tone, and flexible structures.

Four strong levers

1. Describe the target format explicitly and positively.

2. Use examples that demonstrate the exact output shape.

3. Use XML tags when output sections need clear boundaries.

4. Match the style of your prompt to the style you want returned when useful.

Prompt template example

Return exactly these sections: Summary: 2–3 sentences Evidence: 3 bullets, each tied to source text Risk: Low \| Medium \| High Next action: one sentence

If evidence is insufficient, write “Insufficient evidence” in Risk and explain why.

When a prompt template is enough

• A human reads the response. • Minor formatting variation is acceptable. • You need prose quality more than strict parsing. • The output is not fed directly into a brittle machine workflow.

When it is NOT enough

• A parser requires valid JSON every time. • Required fields and types must be enforced. • Tool arguments must be schema-valid. • A downstream service would fail on malformed or missing fields.

EXAM RULE Human-readable consistency → prompt. Machine-enforced schema → Structured Outputs.

8. Structured Outputs: The Core Distinction

Structured Outputs use constrained decoding so Claude’s direct output follows a JSON Schema. This is fundamentally stronger than saying “please return JSON.”

Two complementary features

MEMORY HOOK JSON output = response contract. Strict tool use = function-call contract.

Current JSON output shape (conceptual)

output_config={ "format": { "type": "json_schema", "schema": { "type": "object", "properties": { "category": {"type": "string"}, "confidence": {"type": "number"} }, "required": \["category", "confidence"\], "additionalProperties": false } } }

Use JSON outputs for

• Data extraction from text/images into typed fields. • Classification results consumed by applications. • Structured reports or API responses. • Any final model output that must parse and match a known schema.

IMPORTANT Schema-valid does NOT mean semantically correct. Claude can still put the wrong fact into a perfectly valid field. Validate business semantics separately.

9. JSON Schema Design for Exam Scenarios

Use the schema to encode what the application actually needs

Schema design principles

• Keep schemas as simple as the downstream contract allows. • Make required fields genuinely required; do not rely on prose to fill critical fields. • Use narrow enums for closed categories rather than arbitrary free text when appropriate. • Do not put volatile or sensitive instance data into the schema definition; values belong in message content/output. • Treat schema compilation and caching as implementation details, not the core exam concept.

Property order nuance

Current Structured Outputs preserve schema-defined property ordering with required properties first, followed by optional properties. Do not build a fragile system that depends on casual object key order unless the contract requires it.

Schema complexity

More complex strict schemas are more expensive to compile and have explicit platform limits. For CCAR-F, the durable lesson is: prefer a clean, purpose-built schema over an enormous “everything” schema.

TRAP If the requirement is “return exactly these fields with these types,” examples alone are weaker than encoding the contract in JSON Schema.

10. Strict Tool Use & Structured Output Failure Conditions

Strict tool use

\strict: true\ applies schema-constrained sampling to tool calls so the tool name/input structure follows the declared contract. It solves a different problem from final JSON outputs.

tools=\[{ "name": "create_ticket", "strict": true, "input_schema": { "type": "object", "properties": { "priority": {"type":"string", "enum":\["low","medium","high"\]}, "summary": {"type":"string"} }, "required": \["priority","summary"\], "additionalProperties": false } }\]

BOTH CAN BE USED TOGETHER A workflow can require schema-valid tool parameters AND a schema-valid final response. Use strict tools for the actions; JSON outputs for the final answer.

Important exceptions: “guaranteed” still has boundaries

IMPLEMENTATION DETAIL — LOWER STUDY PRIORITY As of Aug. 2026, Anthropic documents grammar compilation/caching and some schema-complexity limits. Know the concept, but prioritize the architecture distinction over memorizing numeric limits unless your exam material explicitly highlights them.

11. Reliability: Prompting, Validation, Retries & Chaining

Consistency ladder

Vague request ↓ Clear instructions ↓ Examples + XML + explicit output format ↓ External validation / business-rule checks ↓ Structured Outputs for hard JSON/schema requirements

Validation belongs outside the model too

• Validate domain rules after parsing: totals, IDs, dates, authorization, allowed transitions, etc. • Do not confuse syntactic/schema validity with business correctness. • If a value can be deterministically computed, compute it in code rather than asking Claude to guess it.

Retry strategically

Retries are useful for transient or recoverable failures, but a repeat of the same weak prompt is not a robust architecture. Fix the cause: better prompt, better context, a schema, or deterministic validation.

Prompt chaining

Break a complex task into sequential calls when you need to inspect intermediate outputs or enforce a fixed pipeline. Newer Claude models can reason through many multistep tasks internally, so chain only when the workflow benefits from explicit stages.

Extract facts → Validate facts → Classify → Generate final report

EXAM CLUE If the requirement says “the intermediate result must be reviewed/validated before the next stage,” prompt chaining or a deterministic workflow is stronger than one giant prompt.

12. Thinking & Reasoning Prompts: What to Remember

Do not memorize obsolete “chain-of-thought hacks.” For the exam, focus on when extra reasoning depth is useful and when a deterministic workflow is a better control mechanism.

Use more reasoning when

• The task is genuinely complex, multi-step, or ambiguous. • Claude must interpret tool results and decide the next action. • A difficult coding/analysis task benefits from more deliberation.

Do not use “more thinking” as a universal fix

• Simple extraction/classification often benefits more from clear schemas/examples. • Excessive reasoning can add cost and latency. • If correctness can be deterministically validated, use validation. • If the process must follow fixed stages, use a workflow rather than hoping reasoning follows the sequence.

2026 MODEL NOTE Anthropic’s current models increasingly use adaptive thinking/effort controls. Model-specific configuration changes quickly; the durable CCAR-F idea is to match reasoning depth to task complexity and cost/latency needs.

Avoid brittle instructions

Prompts that demand hidden reasoning text, force unnecessary verbosity, or use aggressive “MUST think step-by-step” language are not the same as designing a reliable reasoning workflow.

13. Common Domain 4 Exam Traps

THE DOMAIN 4 QUESTION TO ASK YOURSELF What exactly is failing: understanding, context, style, structure, tool arguments, or semantic correctness? Choose the mechanism that targets that failure.

14. Scenario Drills — Set A

Scenario 1

A support classifier returns labels with inconsistent capitalization and occasionally adds commentary. A downstream service only accepts one of four exact categories.

Best answer: Use a structured JSON schema with an enum for the category; validate downstream semantics. Why: This is a machine-consumed closed contract, not merely a prose-format preference. Trap: Adding “return only the category” helps but does not provide the same contract.

Scenario 2

Claude writes good reports but sometimes uses too many bullets. A human reads the report and minor variation is acceptable.

Best answer: Prompt the desired prose style positively and show an example. Why: This is a style-steering problem, not a hard schema requirement.

Scenario 3

A team has changed a prompt 15 times but cannot agree whether version B is better than version A.

Best answer: Define success criteria and create an evaluation set/rubric. Why: You need empirical comparison before more prompt tuning.

Scenario 4

The prompt contains instructions, two policies, user input, and three examples. Claude occasionally treats example text as live instructions.

Best answer: Separate sections with descriptive XML tags. Why: The issue is ambiguous prompt structure.

Scenario 5

A tool call must always include \account_id\ as a string and an action from a fixed enum.

Best answer: Use a strict tool schema (\strict: true\) with required fields and enum. Why: The contract applies to tool arguments.

Scenario Drills — Set A (continued)

Scenario 6

The final response must be JSON, but tool calls may be ordinary non-strict tools.

Best answer: Use JSON Structured Outputs for the final response. Why: Strict tool use is not required unless tool arguments also need constrained validation.

Scenario 7

You have 80k tokens of source documents and a complex question.

Best answer: Place long documents first, structure them, then put the query/instructions after the data. Why: This follows Anthropic’s long-context guidance.

Scenario 8

Claude invents a policy detail that is absent from the source packet.

Best answer: Ground the task in the supplied documents and explicitly allow an “insufficient evidence” result; validate with citations/quotes where compatible. Why: You need evidence discipline, not more confident prompting.

Scenario 9

The application needs to extract \invoice_total\ and then deterministically verify subtotal + tax = total.

Best answer: Use structured extraction for the fields, then perform the math validation in code. Why: Schema validity cannot replace deterministic arithmetic/business validation.

Scenario 10

A three-stage process requires a human to inspect the classification before a customer message is generated.

Best answer: Use an explicit chained workflow with an approval checkpoint. Why: Intermediate inspection is a reason to externalize the stages.

15. Scenario Drills — Set B

Scenario 11

Claude’s tone is generic even though it must consistently write for experienced database administrators.

Best answer: Set a concise expert role in the system prompt and provide relevant examples. Why: Role + examples target tone and domain framing.

Scenario 12

A parser occasionally fails because Claude puts a preamble before JSON.

Best answer: Use Structured Outputs instead of relying on a “no preamble” instruction. Why: The downstream parser needs a hard structured contract.

Scenario 13

The model follows most instructions but misses one step in a five-step compliance review.

Best answer: State the steps explicitly in a numbered sequence and evaluate completion. Why: Order/completeness should be made explicit.

Scenario 14

A company wants Claude to answer from an internal handbook but the handbook is not included or retrievable.

Best answer: Provide/retrieve the handbook content. Why: Prompt engineering cannot conjure unavailable facts.

Scenario 15

A prompt asks Claude to “be accurate, concise, thorough, creative, exhaustive, brief, and never omit detail.” Output quality is erratic.

Best answer: Remove conflicting goals and define concrete success/length criteria. Why: Contradictory adjectives are not a usable contract.

Scenario Drills — Set B (continued)

Scenario 16

A workflow requires a strict tool call followed by a strict final JSON summary.

Best answer: Use \strict: true\ for the tool and JSON Structured Outputs for the final response. Why: The two features solve complementary contracts and can be combined.

Scenario 17

A structured-output request hits \max_tokens\ and returns incomplete JSON.

Best answer: Detect \stop_reason: max_tokens\ and retry with sufficient output budget. Why: Schema constraints cannot finish output after the response is truncated.

Scenario 18

Claude returns schema-valid JSON but classifies a transaction incorrectly.

Best answer: Improve context/examples/evals and validate the business rule; do not blame the JSON parser. Why: Structured Outputs guarantee shape, not semantic correctness.

Scenario 19

A prompt uses five examples that are nearly identical and the model fails on edge cases.

Best answer: Replace some examples with diverse representative edge cases. Why: Few-shot quality and diversity matter more than repetition.

Scenario 20

The requirement is “no extra keys under any circumstances.”

Best answer: Encode a closed schema such as \additionalProperties: false\ where supported and use Structured Outputs. Why: A prose instruction is weaker than a constrained schema for a machine contract.

16. Night-Before Rapid Review

THE 12 RULES 1. Define success + evals before endless prompt tuning. 2. Be clear, direct, specific, and explicit about constraints. 3. Explain WHY when context helps Claude generalize. 4. Use roles for persistent behavior/tone, not as security boundaries. 5. Use 3–5 relevant, diverse examples when examples are the right lever. 6. XML tags separate prompt sections; they do not guarantee schema validity. 7. Long data first; query/instructions later for large inputs. 8. Human-readable format consistency → prompting/examples. 9. Guaranteed final JSON shape → output_config.format. 10. Guaranteed tool-argument shape → strict: true. 11. Schema-valid ≠ semantically correct; validate business rules. 12. Chain prompts when intermediate stages need inspection/control.

If you see X, think Y

FINAL ONE-LINER Prompting tells Claude what good looks like. Structured Outputs make the response/tool call fit a machine contract. Code still owns deterministic validation.

17. Current 2026 Details vs Durable Exam Concepts

High-priority durable concepts

• Success criteria and eval-driven prompt iteration. • Clear/direct instructions, context, roles, examples, XML structure. • Long-context placement and evidence grounding. • Prompted format vs schema-constrained Structured Outputs. • JSON output vs strict tool input distinction. • Schema validity vs semantic/business validity. • Prompt chaining when explicit stages/checkpoints matter.

Current implementation details — know lightly unless highlighted by your course

• Current JSON Structured Output parameter is \output_config.format\; older beta naming has been superseded. • Current docs describe schema grammar compilation/caching and explicit schema-complexity limits. • Current model generations have moved away from last-assistant-message prefilling for newer models. • Thinking configuration has evolved toward adaptive thinking/effort on newer models.

WHY SEPARATE THESE? Certification questions should reward architectural understanding. Product syntax and model-specific behavior can change. Memorize the stable decision rule first; learn current syntax second.

Official references used for this guide

Anthropic Academy — Claude Certified Architect, Foundations: https://anthropic.skilljar.com/claude-certified-architect-foundations-access-request

Claude Platform Docs — Prompt engineering overview: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview

Claude Platform Docs — Prompting best practices: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices

Claude Platform Docs — Structured outputs: https://platform.claude.com/docs/en/build-with-claude/structured-outputs

Claude Platform Docs — Increase output consistency: https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/increase-consistency

Document verified against the official pages above on August 13, 2026. Model names and API syntax can change; use the current Anthropic documentation as the source of truth for implementation details.

---

Domain 5 — Context Management & Reliability

CCAR-F

DOMAIN 5

Context Management & Reliability

Complete Cheat Sheet & Exam Study Guide

THE DOMAIN 5 MENTAL MODEL Context is a finite working set. More context is not automatically better. Keep the active context relevant; move durable knowledge outside the context window and retrieve it when needed. Caching saves repeated processing cost/latency. It does NOT create more context-window capacity. Compaction summarizes old conversation. Context editing removes selected stale content. RAG retrieves external knowledge. Memory persists information across sessions. Reliability means designing for errors, limits, truncation, retries, observability, validation, and graceful recovery - not assuming every model call succeeds.

How to use this document

• Study the decision rules first. They are more valuable than memorizing exact API syntax. • Use the comparison tables to separate concepts that sound similar. • Do the scenario drills without looking at the answer, then explain why the distractors are wrong. • Exact model limits, beta headers, and product details change quickly. Durable architecture concepts are labeled as the priority.

Verified against current Anthropic Platform and engineering documentation on August 13, 2026.

1. The 30-Second Domain 5 Decision Tree

Is the problem TOO MUCH ACTIVE CONVERSATION HISTORY? -> Compaction (primary long-running strategy) Is OLD TOOL OUTPUT cluttering the context? -> Context editing / tool-result clearing Is the SAME LARGE PREFIX sent repeatedly? -> Prompt caching Is KNOWLEDGE too large or dynamic to put in every prompt? -> Retrieval / RAG Must information survive a NEW SESSION? -> Persistent memory / durable state Need to know request size BEFORE sending? -> Token counting Transient API failure / 429 / 5xx? -> Bounded retry + exponential backoff; honor retry-after Long response risks connection timeout? -> Streaming (interactive) or Message Batches (async bulk)

The five questions to ask on exam scenarios

1. What is consuming the context window: history, tool schemas, tool results, documents, or generated output? 2. Does the information need to be visible now, retrievable later, or persisted across sessions? 3. Is the goal to reduce context size, reduce cost/latency, improve retrieval quality, or improve fault tolerance? 4. Is the failure transient and safe to retry, or deterministic and requiring a fix? 5. What evidence tells the application that the response is complete and valid?

EXAM SHORTCUT If an answer says "use prompt caching to fit more data into the context window," it is wrong. If an answer says "store everything in conversation history so Claude remembers it," it is usually wrong for long-running systems. If an answer says "retry every error indefinitely," it is wrong.

2. Context Window Fundamentals

The context window is Claude's working memory for the current request. It is not the model's training data and it is not persistent application memory.

What consumes context

Context capacity is not the same as context quality

• A larger window lets you include more information, but irrelevant or redundant material can reduce focus. • Anthropic describes long-context degradation as context rot: recall and accuracy can degrade as token count grows. • The architectural goal is therefore not "fill the window." It is "provide the smallest high-signal working set that solves the task."

Memory hook

CONTEXT = DESK, NOT WAREHOUSE Context window: what is on the desk right now. Persistent memory/state: what is stored in filing cabinets. RAG: finding the right files and putting only those on the desk. Compaction: replacing a pile of old notes with a concise summary. Prompt caching: making repeated setup faster/cheaper - the papers still occupy desk space.

3. Context Engineering: Optimize Signal, Not Volume

Context engineering is the practice of curating the information available to the model so the most relevant instructions, facts, state, and tool information are present when needed.

High-signal context principles

• Keep stable global instructions concise and unambiguous. • Retrieve task-specific information just in time instead of loading an entire knowledge base upfront. • Remove stale intermediate outputs once their conclusions have been captured. • Persist durable decisions and progress in structured state so they can be recovered later. • Preserve recent task state and unresolved issues when compacting; discard redundant history and dead tool output. • Measure token usage rather than guessing.

Common sources of context bloat

When starting fresh can beat carrying history

If a new task can reconstruct the necessary state from durable artifacts (files, database records, checkpoints, memory), starting with a fresh context can be cleaner than preserving a very long conversation. The key is that required state must be recoverable.

EXAM CLUE "Long-running agent becomes less accurate even though it has not hit the hard token limit" -> think context quality / context rot, not merely increase the window. "Agent needs old conclusions but not hundreds of raw tool responses" -> summarize/persist conclusions and clear stale tool results.

4. Token Budgets & Token Counting

Token counting lets an application estimate the size of a Messages request before sending it. This is useful for fitting requests, managing cost/rate limits, and routing work.

What to budget for

AVAILABLE CONTEXT = model context capacity - system + tools + messages + documents/images - room needed for the model's output • Do not budget only for input. The generated response also consumes context capacity. • Tool schemas can be a significant hidden baseline cost in tool-heavy systems. • Images/documents count toward request/context usage even though their tokenization differs from plain text. • Prompt-cache reads still occupy the context window even when billed/limited differently.

When token counting is the best answer

Trap: max_tokens is not a context-management strategy

Setting a high max_tokens does not create more context capacity. If the total input plus generated output reaches the model context limit, output can truncate or terminate because the context window is exhausted.

5. Compaction: Primary Strategy for Long Conversations

Anthropic currently recommends server-side compaction as the primary context-management strategy for long-running conversations and agentic workflows.

What compaction does

Full conversation history \| \| reaches threshold v Summarize older context -> COMPACTION SUMMARY + Recent / current context \| v Continue working with a smaller active context • Summarizes older conversation rather than retaining every prior token. • Extends effective task duration beyond what raw accumulated history would permit. • Keeps active context smaller, which can improve focus as sessions grow.

What the summary should preserve

Compaction trade-off

Compaction is lossy by design. A summary may omit a detail that becomes important later. Reliability improves when important durable facts are also stored externally and can be retrieved again.

MEMORY HOOK Compaction = summarize the HISTORY. Context editing = selectively REMOVE stale content. RAG = retrieve EXTERNAL knowledge. Memory = persist knowledge ACROSS sessions.

6. Context Editing: Selective Cleanup

Context editing is for fine-grained control over specific content that no longer deserves space in the active conversation. Anthropic currently positions compaction as the default long-running strategy and context editing as a more targeted tool.

Tool-result clearing

Agentic workflows can generate hundreds of tool_result blocks. Early raw results may be dead weight once Claude has extracted the needed conclusion.

Search tool result: 25,000 tokens Claude extracts: "Customer contract expires 2027-03-31" Later turns need the conclusion, not the entire 25,000-token result. -> Persist/summarize the fact, then clear stale tool result.

Thinking-block clearing

When extended thinking is used, older thinking blocks can also consume context. Fine-grained context editing can clear old thinking while preserving enough recent context for continuity.

When to prefer context editing

EXAM TRAP Clearing a tool result is safe only if the information is no longer needed OR the important parts have been preserved elsewhere. Do not remove evidence that later verification or audit steps still require.

7. Prompt Caching: Cost & Latency, Not Context Capacity

Prompt caching reuses a stable prompt prefix across requests. It is especially useful for long system instructions, tool definitions, examples, reference material, and growing multi-turn conversations with a repeated prefix.

What caching changes

Good cache candidates

• Stable system instructions. • Large, mostly static tool definitions. • Long few-shot example sets. • Reference documents repeatedly queried within the cache lifetime. • Repeated conversation prefixes in active multi-turn sessions.

Prompt structure matters

Cacheable stable content should appear before highly variable content. Anthropic prompt caching operates on prefixes; changing earlier content can invalidate reuse of later cached prefixes.

Current implementation note - fast changing

As of August 2026, Anthropic supports automatic caching as well as explicit cache breakpoints, and documents 5-minute and 1-hour TTL choices. Treat TTLs and specific beta/platform constraints as implementation details to verify near exam day.

THE CLASSIC DISTRACTOR Question: "A 150k-token reference prompt is reused for thousands of questions. How do we reduce repeated cost?" Answer: prompt caching. Question: "The 150k tokens leave too little room for useful task context." Answer: caching alone does NOT solve it; reduce/retrieve/compact the context.

8. Master Comparison: Context Tools That Sound Similar

Decision examples

• Same 80-page policy manual on every request -> cache it if it truly must be present; RAG may be better if only small portions are relevant. • Chat session grows for hours -> compaction. • Agent has 100 old web-search results -> context editing/tool-result clearing. • Need to remember a project convention next week -> persistent memory/state. • 10 million documents -> RAG, not a gigantic prompt. • Need to prevent oversized requests -> token counting.

Exam rule

MATCH THE SOLUTION TO THE BOTTLENECK Cost problem -> caching / model choice / batch where appropriate. Context-size problem -> retrieval / compaction / editing / smaller tool surface. Persistence problem -> memory or durable state. Reliability problem -> validation, bounded retries, stop-reason handling, checkpoints, monitoring.

9. Context vs Memory vs Durable State

Do not treat conversational memory as the authoritative state of a production application.

Context

• Ephemeral working set for the current request/session. • Optimized for reasoning over what is relevant now.

Persistent memory

• Useful knowledge retained across conversations, such as preferences, lessons, project conventions, or summaries. • Retrieved just in time rather than automatically loading everything into every prompt. • Anthropic's Memory tool is client-side: your application owns and executes storage operations.

Durable application state

• Authoritative facts that drive workflow correctness: job status, order ID, completed steps, approvals, balances, checkpoint version, etc. • Should usually live in a database/state store, not only in model-generated memory text.

Memory is not a database transaction log

RELIABILITY PRINCIPLE Use the model to reason about state; do not make the model the only place state exists. If restarting the process would destroy a fact you need for correctness, persist that fact outside the context window.

10. Retrieval-Augmented Generation (RAG)

RAG keeps a large or changing knowledge base outside the prompt and retrieves relevant pieces at runtime. This lets Claude answer using information beyond its training data without loading the entire corpus into every request.

Basic RAG flow

Documents / knowledge base \| chunk + index \| User query -> retrieve relevant chunks -> optional rerank -> Claude prompt -> grounded answer

When RAG is a strong answer

• Knowledge base is much larger than practical prompt size. • Information changes frequently. • Queries touch only a small subset of the corpus. • You need source grounding/citations. • You want lower context cost than sending entire documents repeatedly.

When full long context can be reasonable

• A single document or small set fits comfortably and the question requires cross-document/global reasoning. • Retrieval may omit subtle information that is distributed throughout the source. • The task is one-off and building a retrieval pipeline adds unnecessary complexity.

RAG is only as good as retrieval

If the correct evidence is not retrieved, Claude cannot reliably use it. Retrieval recall, chunk quality, metadata, ranking, and source freshness are therefore architectural reliability concerns.

11. Retrieval Quality: Chunking, Hybrid Search & Reranking

Chunking

Documents are usually split into smaller retrievable units. Chunks that are too large waste context and blur relevance; chunks that are too small may lose the surrounding meaning needed to interpret them.

• Preserve semantic boundaries where possible: sections, paragraphs, procedures, records. • Keep useful metadata: document title, date, section, product, permissions, source ID. • Choose chunk size empirically using retrieval/evaluation results, not a universal magic number.

Semantic vs lexical retrieval

Contextual retrieval

Traditional chunking can strip a passage of the document context needed to retrieve it correctly. Anthropic's contextual retrieval approach augments chunks with short document-specific context before indexing, helping retrieval distinguish otherwise ambiguous chunks.

Reranking

A first retrieval stage can return candidates quickly, then a reranker can reorder them for the exact query. This is useful when top-K recall is acceptable but initial ordering is noisy.

EXAM CLUES Exact error code / SKU / contract number missed by semantic search -> add lexical/BM25 or hybrid retrieval. Retrieved chunk says "revenue increased 3%" but company/year are missing -> preserve or add chunk context/metadata. Too many weak chunks crowd out the best evidence -> improve ranking/reranking, not merely increase top-K.

12. Grounding, Citations & Verifiability

Reliability is improved when generated claims can be traced back to the evidence Claude used. For document/RAG applications, source attribution also helps users and downstream systems verify answers.

Grounding principles

• Provide authoritative source material rather than asking the model to infer changing facts from training data. • Preserve source identity with retrieved chunks. • Ask the system to distinguish supported facts from uncertainty when the evidence is incomplete. • Use citations/search-result content when the application requires traceability. • Do not assume citations fix poor retrieval; citations only point to what was actually supplied/used.

Citation granularity

If precise sentence-level attribution is required, structure retrieved content so the model can cite the appropriate unit. Anthropic supports document citations and search-result content blocks for RAG-style source attribution.

Reliability pattern

Retrieve evidence -> Verify source/permissions/freshness -> Ask Claude to answer from supplied evidence -> Return citations -> Validate critical claims / escalate when evidence is insufficient

TRAP "Use RAG" does not automatically mean "the answer is correct." You still need retrieval quality, source quality, grounding instructions, and evaluation.

13. Long-Running Agents: Checkpoints, Notes & Recovery

Long-horizon tasks often outlive a single context window and may also outlive a process or session. Design explicit artifacts that let a new context reconstruct what matters.

Structured note-taking

Anthropic recommends structured notes as a lightweight persistent-memory pattern. The agent records concise progress, decisions, unresolved tasks, and references to artifacts rather than relying on raw conversation history.

A useful checkpoint should answer

• What is the goal? • What has already been completed? • What decisions were made and why? • What remains unresolved? • What external artifacts/IDs/files contain authoritative details? • What is the next safe action?

Checkpoint example

GOAL: migrate service A to API v3 DONE: schema mapping; integration tests 1-42 pass DECISIONS: keep legacy auth until cutover; reason = partner dependency BLOCKER: partner sandbox returns 429 after 20 req/min ARTIFACTS: /work/migration-plan.md, DB job_id=8742 NEXT: implement bounded backoff; rerun tests 43-60

Recovery principle

A restarted agent should be able to inspect durable artifacts and resume without requiring the entire historical conversation. This improves both reliability and context efficiency.

14. Reliability Starts With Classifying Failures

Not every failure should be retried. First determine whether the failure is transient, request-related, authorization-related, truncation-related, or an application-quality failure.

Bounded retries

• Use exponential backoff for transient failures. • Honor server retry guidance such as retry-after where provided. • Limit attempts; do not create infinite retry loops. • Use jitter in distributed systems to avoid synchronized retry storms (general reliability best practice). • Ensure repeated actions are safe, especially if a request may have caused a side effect before the client lost the response.

EXAM RULE Transient failure -> retry. Deterministic bad request -> fix. Permission failure -> remediate access. Model output failure -> validate and change the strategy; a blind identical retry is not a reliability architecture.

15. Rate Limits & Throughput

Anthropic rate limits can constrain requests per minute, input tokens per minute, and output tokens per minute. Production architecture should treat limits as expected operating constraints, not exceptional surprises.

429 handling

429 received -> inspect rate-limit / retry-after information -> wait/back off -> retry within bounded policy -> reduce concurrency or smooth traffic if sustained

Avoid acceleration problems

Sharp sudden increases in traffic can trigger acceleration-related rate limiting. Ramp traffic gradually and maintain steadier usage patterns when scaling workloads.

Caching and throughput

For most current Claude models, cached input reads do not count toward input-token-per-minute limits the same way uncached input does. This can substantially improve effective throughput for repeated prefixes. The exam-level point: caching can improve cost/latency and effective throughput, but cached tokens still occupy the context window.

Concurrency architecture

• Queue work instead of letting every caller hit the model simultaneously. • Use per-model/request concurrency limits. • Apply backpressure when downstream limits are reached. • Prefer batch processing for high-volume work that does not need immediate results.

16. Streaming vs Message Batches

Streaming

• Uses server-sent events (SSE) to deliver response pieces incrementally. • Useful for user experience and for long outputs that risk non-streaming network timeouts. • Applications must handle stream errors that can occur after an HTTP 200 has already been returned.

Message Batches

• Asynchronous processing for large volumes of independent Messages requests. • Good when immediate response is not required. • Supports higher-throughput/offline workflows and currently offers a cost discount; exact limits/pricing are implementation details that can change.

EXAM SHORTCUT Interactive + long output -> streaming. Bulk + asynchronous + independent requests -> Message Batches.

17. Stop Reasons: Do Not Treat Every HTTP 200 as Complete

A successful Messages API response includes a stop_reason that explains why generation stopped. Reliable applications inspect it rather than assuming every 200 response is a complete final answer.

Stop reason vs HTTP error

• Stop reason: the request succeeded and tells you why generation ended. • HTTP/API error: request processing failed or could not proceed normally.

Why this matters

A partial response can look syntactically plausible. If the application never checks the stop reason, it may accept truncated text, incomplete JSON, or a half-finished tool call as complete.

18. Validation, Evals & Observability

Reliability is an end-to-end property. Good prompting helps, but production systems also need deterministic checks, evaluation, and operational telemetry.

Validate what can be validated deterministically

• JSON/schema structure and required fields. • Ranges, formats, IDs, dates, and numeric invariants. • Permissions before executing side effects. • Tool response status and completeness. • Stop reason / truncation conditions.

Evaluate what requires judgment

Anthropic recommends choosing the fastest reliable grading method that fits the criterion: code-based grading for objective checks, human grading for nuanced high-value cases, and tested LLM-based grading for scalable subjective criteria.

Observability to capture

RELIABILITY = CORRECTNESS + RECOVERY + VISIBILITY A system that silently produces wrong answers is not reliable just because the API stayed up. A system that retries forever without visibility is also not reliable.

19. Common CCAR-F Domain 5 Traps

Trap 1

"We are out of context; enable prompt caching."

Wrong. Caching reduces repeated processing cost/latency but cached tokens still consume context.

Trap 2

"The context window is huge, so include the entire knowledge base."

Usually wrong. More irrelevant context can hurt focus and cost. Use retrieval when only a subset is needed.

Trap 3

"The agent must remember next month, so keep the chat running."

Wrong architecture. Persist memory/state externally and retrieve it later.

Trap 4

"Any error should be retried."

Wrong. Invalid requests/auth/permission failures require remediation, not unchanged retries.

Trap 5

"429 means increase max_tokens."

Wrong. 429 is rate limiting; back off and honor retry guidance.

Trap 6

"A 200 response means the answer is complete."

Wrong. Check stop_reason for truncation, tool use, pause, refusal, etc.

Trap 7

"RAG makes hallucinations impossible."

Wrong. RAG improves grounding only if retrieval/source quality and answer behavior are reliable.

Trap 8

"Top-K should be as large as possible."

Wrong. Too many weak chunks waste context and can dilute relevant evidence.

Trap 9

"Compaction is lossless storage."

Wrong. Summarization is lossy; persist critical facts externally.

Trap 10

"Memory should contain every raw tool result."

Wrong. Memory should be useful and retrievable; raw high-volume data belongs in appropriate storage.

Trap 11

"Long requests should always be non-streaming because the final answer is all we need."

Wrong. Streaming can be used internally even if the application ultimately returns a complete message.

Trap 12

"Retrying the same low-quality model response five times is a validation strategy."

Wrong. Use explicit validation/evals and meaningful fallbacks or corrective prompts.

20. If You See X, Think Y

21. Scenario Drills - Set A

1. A support agent has a 4-hour conversation. The user wants continuity, but the history is approaching the context limit.

Answer: Use compaction. Preserve goals, decisions, unresolved issues, and critical state; replace older raw history with a concise summary.

2. An agent searches ten large repositories. Earlier file-search outputs remain in history even after the relevant files are identified.

Answer: Use context editing/tool-result clearing after preserving needed conclusions or references.

3. Every request sends the same 60k-token regulatory policy followed by a short user question. The policy truly must be present in full. Cost is the main issue.

Answer: Use prompt caching for the stable prefix. Remember: it reduces repeated processing cost/latency but not context occupancy.

4. A company has 8 million knowledge-base articles and users normally need only 3-8 articles per question.

Answer: Use RAG. Retrieve a small relevant set rather than stuffing the corpus into context.

5. A coding agent must remember project conventions when a brand-new session starts tomorrow.

Answer: Persist conventions in memory/project artifacts and retrieve them in the new session.

6. A request is rejected with 400 because the prompt is too long.

Answer: Reduce/split/retrieve/compact the request. Retrying unchanged is pointless.

7. API calls intermittently return 529 during a traffic spike.

Answer: Bounded retries with exponential backoff; monitor service state and avoid retry storms.

8. The service receives 429 plus retry-after.

Answer: Wait according to retry guidance, back off, and reduce/smooth concurrency if sustained.

9. A response returns HTTP 200 but stop_reason=max_tokens.

Answer: Treat it as truncated; continue safely or adjust the output budget.

10. A model is asked to answer from retrieved policy text, but the retriever frequently omits the correct section.

Answer: Fix retrieval quality/evals. Prompting the model harder cannot recover evidence it never received.

22. Scenario Drills - Set B

11. Semantic retrieval finds general error documentation but misses exact code XR-4421.

Answer: Add lexical/BM25 or hybrid retrieval so exact identifiers are matched.

12. Retrieved chunks are individually ambiguous because company and reporting period were in the document heading.

Answer: Preserve metadata or use contextual retrieval so chunks carry document-specific meaning.

13. An interactive report can take several minutes to generate and some corporate proxies drop idle HTTP connections.

Answer: Use streaming. The application can still accumulate the stream and return a final complete object to the caller.

14. An overnight job must summarize 50,000 independent documents; nobody needs an immediate response.

Answer: Use Message Batches / asynchronous batch processing.

15. A long agent must survive process restarts and continue exactly from completed workflow steps.

Answer: Persist authoritative workflow state/checkpoints outside the model context. Memory summaries alone are not enough for transactional correctness.

16. The team wants to know whether a prompt will leave enough room for a 10k-token answer before sending it.

Answer: Use token counting and reserve an output budget.

17. The agent stores every raw search result in persistent memory and performance degrades over time.

Answer: Store concise durable knowledge/pointers; retrieve raw source material on demand instead of turning memory into an unbounded dump.

18. A long conversation still fits the model window, but answers are becoming less focused.

Answer: Treat it as context-quality/context-rot pressure. Compact or curate irrelevant history instead of waiting for a hard limit.

19. The API returns 403 for a tool/resource.

Answer: Fix authorization or access policy. Do not repeatedly retry the same forbidden request.

20. A critical extraction occasionally produces a syntactically valid but impossible negative quantity.

Answer: Add deterministic validation/business rules and an explicit repair/escalation path. Schema validity alone is insufficient.

23. Night-Before Rapid Review

THE 12 LINES TO MEMORIZE 1. Context is working memory; more is not automatically better. 2. Cached tokens still occupy context. 3. Compaction = summarize old conversation. 4. Context editing = selectively clear stale content. 5. RAG = retrieve external knowledge just in time. 6. Memory/state = persist what must survive sessions. 7. Token counting = measure before sending. 8. 429 = back off and honor retry-after. 9. 5xx/529 = bounded exponential backoff. 10. 400/401/403 are not blind-retry problems. 11. Streaming = long interactive; batches = bulk async. 12. HTTP 200 is not enough: always inspect stop_reason.

One-line pattern map

The sentence that solves much of Domain 5

KEEP THE ACTIVE CONTEXT SMALL, RELEVANT, AND RECOVERABLE Put only what Claude needs now in context; cache repeated prefixes for efficiency, retrieve external knowledge on demand, persist durable state outside the model, and design every API interaction for observable bounded failure and recovery.

24. Fast-Changing 2026 Implementation Details

These are useful to recognize, but do not prioritize memorizing exact headers/model-specific limits over the architecture concepts unless your official exam guide explicitly calls them out.

Do not memorize volatile trivia at the expense of decisions

• Exact context-window size per model. • Exact beta header strings unless named in your official objective list. • Current pricing multipliers or batch limits unless the exam guide says they are in scope. • Specific model marketing names.

Do memorize the behavior, trade-offs, and architecture selection rules.

25. Official Anthropic References Used

Use these as the source of truth if your Udemy material and a current product detail disagree. Product behavior can change after this document was created.

Context windows: https://platform.claude.com/docs/en/build-with-claude/context-windows

Compaction: https://platform.claude.com/docs/en/build-with-claude/compaction

Context editing: https://platform.claude.com/docs/en/build-with-claude/context-editing

Prompt caching: https://platform.claude.com/docs/en/build-with-claude/prompt-caching

Token counting: https://platform.claude.com/docs/en/build-with-claude/token-counting

Memory tool: https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool

Manage tool context: https://platform.claude.com/docs/en/agents-and-tools/tool-use/manage-tool-context

Claude API errors: https://platform.claude.com/docs/en/api/errors

Rate limits: https://platform.claude.com/docs/en/api/rate-limits

Streaming messages: https://platform.claude.com/docs/en/build-with-claude/streaming

Message Batches: https://platform.claude.com/docs/en/build-with-claude/batch-processing

Stop reasons and fallback: https://platform.claude.com/docs/en/build-with-claude/handling-stop-reasons

Effective context engineering for AI agents: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

Contextual Retrieval: https://www.anthropic.com/engineering/contextual-retrieval

Citations: https://platform.claude.com/docs/en/build-with-claude/citations

Define success criteria and build evaluations: https://platform.claude.com/docs/en/test-and-evaluate/develop-tests

End of Domain 5

You now have a complete Domain 1-5 CCAR-F study set. Use this guide together with the official exam objectives and current Anthropic documentation.

Integrated Scenario Practice

The original CloudNinjas certification page also included six cross-domain scenarios and sample questions. They are retained below as an additional practice layer after the expanded domain-by-domain guide.

The 6 Exam Scenarios in Detail

You will be presented with 4 of these 6 scenarios randomly. Each scenario tests multiple domains simultaneously with realistic production contexts.

Scenario 1: Customer Support Resolution Agent

You are building a customer support agent using the Claude Agent SDK handling high-ambiguity requests (returns, billing disputes, account issues). MCP tools: get_customer, lookup_order, process_refund, escalate_to_human. Target: 80%+ first-contact resolution. Primary domains: Agentic Architecture, Tool Design, Context Management.

Scenario 2: Code Generation with Claude Code

You are using Claude Code to accelerate software development for a team. Covers code generation, refactoring, debugging, documentation, custom slash commands, CLAUDE.md configurations, and plan mode vs direct execution decisions. Primary domains: Claude Code Configuration, Context Management.

Scenario 3: Multi-Agent Research System

You are building a coordinator agent delegating to specialized subagents: web search, document analysis, synthesis, and report generation. The system researches topics and produces comprehensive cited reports. Primary domains: Agentic Architecture, Tool Design, Context Management.

Scenario 4: Developer Productivity with Claude

You are building developer tools using the Claude Agent SDK. The agent explores unfamiliar codebases, understands legacy systems, generates boilerplate, and automates repetitive tasks. Uses built-in tools (Read, Write, Bash, Grep, Glob) and MCP servers. Primary domains: Tool Design, Claude Code Configuration, Agentic Architecture.

Scenario 5: Claude Code for CI/CD

You are integrating Claude Code into CI/CD pipelines for automated code reviews, test generation, and PR feedback. Covers -p flag usage, structured output, Batch API, and multi-pass review. Primary domains: Claude Code Configuration, Prompt Engineering.

Scenario 6: Structured Data Extraction

You are building a structured data extraction pipeline from unstructured documents with JSON schema validation and high-accuracy requirements. Covers JSON schemas, tool\_use, validation-retry loops, few-shot prompting, confidence calibration. Primary domains: Prompt Engineering, Context Management.

Sample Exam Questions with Full Explanations

Question 1 (Domain 1 — Customer Support Agent)

Production data shows your agent skips get_customer in 12% of cases and calls lookup_order using only the customer name, causing misidentified accounts and incorrect refunds. What change most effectively addresses this?

• A) Add a programmatic prerequisite blocking lookup_order and process_refund until get_customer returns a verified customer ID
• B) Enhance the system prompt stating customer verification is mandatory before any order operations
• C) Add few-shot examples showing the agent always calling get_customer first
• D) Implement a routing classifier that enables only appropriate tools per request type

Correct: A. When a specific tool sequence is required for critical business logic with financial consequences, programmatic enforcement provides deterministic guarantees that prompt-based approaches cannot. Options B and C rely on probabilistic LLM compliance — insufficient when errors cause incorrect refunds. Option D addresses tool availability rather than tool ordering, which is not the actual problem.

Question 2 (Domain 2 — Tool Selection)

Your agent frequently calls get_customer when users ask about orders (e.g., "check my order #12345"), instead of calling lookup_order. Both tools have minimal descriptions and accept similar identifier formats. What is the most effective first step?

• A) Add 5-8 few-shot examples demonstrating correct tool selection patterns
• B) Expand each tool description to include input formats, example queries, edge cases, and boundaries explaining when to use it versus similar tools
• C) Implement a routing layer that parses user input and pre-selects the appropriate tool based on detected keywords
• D) Consolidate both tools into a single lookup_entity tool

Correct: B. Tool descriptions are the primary mechanism LLMs use for tool selection — minimal descriptions are the root cause. This is a low-effort, high-leverage fix. Few-shot examples (A) add token overhead without fixing the underlying issue. A routing layer (C) is over-engineered and bypasses natural language understanding. Consolidating tools (D) requires more effort than a first step warrants.

Question 3 (Domain 3 — CI/CD Pipeline)

Your pipeline runs claude "Analyze this pull request for security issues" but hangs indefinitely. Logs show Claude Code is waiting for interactive input. What is the correct fix?

• A) Add the -p flag: claude -p "Analyze this pull request for security issues"
• B) Set environment variable CLAUDE_HEADLESS=true before running
• C) Redirect stdin: claude "..." < /dev/null
• D) Add the --batch flag

Correct: A. The -p (or --print) flag is the documented way to run Claude Code in non-interactive mode — processes the prompt, outputs to stdout, and exits. Options B and D reference non-existent features. Option C uses a Unix workaround that doesn't properly address Claude Code's command syntax.

Question 4 (Domain 4 — Batch Processing)

Your manager proposes switching both your blocking pre-merge check AND your overnight technical debt report to the Message Batches API for 50% cost savings. How should you evaluate this?

• A) Use batch processing for technical debt reports only; keep real-time calls for pre-merge checks
• B) Switch both workflows to batch processing with status polling to check for completion
• C) Keep real-time calls for both workflows to avoid batch result ordering issues
• D) Switch both to batch with a timeout fallback to real-time if batches take too long

Correct: A. The Message Batches API has up to 24-hour processing with no guaranteed latency SLA — unsuitable for blocking pre-merge checks where developers wait for results, but ideal for overnight batch jobs. Option C reflects a misconception — batch results can be correlated using custom_id fields. Options B and D don't match API to appropriate use case.

Question 5 (Domain 1 — Multi-Agent Research)

Your multi-agent research system covering "impact of AI on creative industries" produces reports covering only visual arts, missing music, writing, and film. The coordinator decomposed the topic into: "AI in digital art creation," "AI in graphic design," and "AI in photography." What is the most likely root cause?

• A) The synthesis agent lacks instructions for identifying coverage gaps
• B) The coordinator's task decomposition is too narrow, missing relevant domains
• C) The web search agent's queries are not comprehensive enough
• D) The document analysis agent is filtering out non-visual industry sources

Correct: B. The coordinator's logs reveal the root cause directly — it decomposed "creative industries" into only visual arts subtasks. The subagents executed their assigned tasks correctly. The problem is what they were assigned. Options A, C, and D incorrectly blame downstream agents that are working correctly within their scope.

Question 6 (Domain 3 — CLAUDE.md Configuration)

Your codebase has React components, API handlers, and database models with different conventions. Test files are spread throughout the codebase alongside the code they test (Button.test.tsx next to Button.tsx). You want all tests to follow the same conventions regardless of location. What is the most maintainable approach?

• A) Create rule files in .claude/rules/ with YAML frontmatter glob patterns (e.g., **/*.test.tsx)
• B) Consolidate all conventions in root CLAUDE.md under headers for each area
• C) Create skills in .claude/skills/ for each code type with relevant conventions
• D) Place a separate CLAUDE.md in each subdirectory with that area's conventions

Correct: A. .claude/rules/ with glob patterns allows conventions to automatically apply based on file paths regardless of directory location — essential for test files spread throughout the codebase. Option B relies on inference rather than explicit matching. Option C requires manual skill invocation. Option D cannot handle files spread across many directories since CLAUDE.md files are directory-bound.

Register for the Exam

Claude Certified Architect Foundations — $99 USD

Available to everyone through Anthropic's official Skilljar portal. 60 questions, 120 minutes, passing score 720/1000.

Go to Registration Portal

Affiliate disclaimer: CloudNinjas may receive compensation for referrals.

Source & Maintenance Note

This CloudNinjas article combines the original production certification page with the supplied 2026 five-domain CCAR-F study guide. The expanded domain sections are the newer study source and should be treated as the primary study reference when older legacy wording differs. Product syntax and protocol details can evolve; use the official Anthropic exam guide and current Anthropic documentation as the final authority for version-specific exam requirements.