CCAR-P - Fact Sheet¶

Exam Overview¶

Released July 2026. Register via the Anthropic Partner Academy (free Claude Partner Network membership required). Badge issued via Credly by Pearson. Renewal: free non-proctored assessment in Partner Academy if completed before the 12-month expiry. Retakes: 14 days after attempt 1, 30 days after attempt 2, 90 days after attempt 3; max 4 attempts per rolling 12 months. Reschedule or cancel up to 24 hours before the appointment.

Exam Domains (Blueprint v1.0, effective July 2026)¶

Core Model IDs (2026)¶

Bedrock and Vertex have their own region-scoped IDs. Always check current documentation.

Official Documentation¶

Core API¶

• Messages API
• Streaming
• Message Batches
• Token Counting
• Errors
• Rate Limits

Advanced Features¶

• Extended Thinking
• Prompt Caching
• Batch Processing
• Files API
• Citations
• Vision
• PDF Support
• Memory Tool

Tool Use¶

• Tool Use Overview
• Code Execution Tool
• Computer Use
• Bash Tool
• Text Editor Tool
• Web Search Tool

Agent SDK and MCP¶

• Claude Agent SDK Overview
• Agent SDK Python
• Agent SDK TypeScript
• MCP Introduction
• MCP Specification

Enterprise Deployment and Trust¶

• Claude on Amazon Bedrock
• Claude on Vertex AI
• Anthropic Trust Center

Exam Logistics¶

• Partner Certifications (Partner Academy)
• Pearson VUE - Anthropic

Domain 1 - Integration¶

Tool Design at Scale¶

• Target under 20 tools per agent when possible; prune aggressively
• Group related tools behind a single dispatcher tool if the count explodes
• Descriptions are prompts - treat them with prompt-engineering rigor
• Use examples in descriptions when parameter semantics are non-obvious
• Return errors as structured content with is_error: true

First-Party Tools¶

• code_execution - sandboxed Python runtime
• computer_use - mouse/keyboard/screenshot
• bash - shell execution (Claude Code and Agent SDK)
• text_editor - file editing primitive
• web_search - Anthropic-hosted search
• web_fetch - URL content retrieval
• memory - durable client-side memory

MCP Transports¶

MCP at Scale¶

• Multi-tenant MCP servers must enforce per-user auth (OAuth 2.1 for remote servers)
• Cache tool schemas in the client; do not refetch per request
• Apply timeouts per tool; surface timeouts as tool errors to Claude
• Version MCP servers; expose version in server metadata

Domain 2 - Solution Design and Architecture¶

Orchestrator-Worker Pattern¶

A parent agent receives a task, decomposes it into parallelizable sub-tasks, dispatches each to a worker (often Haiku for cost), and aggregates results. Use when:

• The task can be split into independent units (research across many sources, code review across files)
• Workers do not need shared state mid-task
• Parallelism pays for the orchestration overhead

Anti-pattern: using orchestrator-worker when a single tool-use loop on Sonnet finishes in the same wall clock time at half the token cost.

Planner-Executor Pattern¶

Opus plans, Sonnet or Haiku executes. Planner produces an explicit plan (often as structured output), executor runs each step. Good when planning is expensive but execution is cheap and verifiable.

Swarm / Peer Pattern¶

Multiple peer agents with complementary specialties communicate. Rare in production - coordination overhead usually costs more than it saves. Prefer orchestrator-worker.

Single-Agent Tool Loop¶

One Claude instance with a rich tool set, looped until a stop condition. Still the default choice for most agentic workloads. Multi-agent is an optimization, not a starting point.

Bounding Agentic Loops¶

• Max iterations (typically 10-50 for user-facing, 100-500 for batch)
• Max tokens per run
• Max wall-clock time
• Circuit breakers on repeated tool errors
• Budget enforcement per trace

Enterprise Deployment Paths¶

Amazon Bedrock¶

• Regional model IDs (e.g., anthropic.claude-sonnet-4-6-20260101-v1:0)
• IAM-based auth, no Anthropic API key
• PrivateLink for VPC-only traffic
• Bedrock Guardrails layered on top
• CloudTrail for audit logging
• Cross-region inference profiles for capacity

Google Cloud Vertex AI¶

• Publisher model IDs (e.g., claude-sonnet-4-6@20260101)
• IAM and service account auth
• VPC Service Controls for data exfiltration protection
• Cloud Logging and Cloud Monitoring native integration
• Regional endpoints; check per-model availability

Domain 3 - Evaluation, Testing and Optimization¶

Eval Types¶

• Unit evals - deterministic, string/regex/schema checks
• LLM-as-judge - Claude grades Claude's output against a rubric
• Human-in-the-loop - SMEs grade a sample
• A/B diff evals - run old and new prompts side by side on held-out set

Observability Signals¶

• Per-request: input tokens, output tokens, thinking tokens, cache read/write tokens, latency, stop reason
• Per-trace: total cost, total tool calls, total iterations, final status
• Per-cohort: quality score trends, error rate, latency P50/P95/P99
• Alert on: quality drift, cost spike, cache hit rate drop

Prompt Caching Layers¶

• 5-minute ephemeral cache (default)
• 1-hour cache for long-lived prefixes
• Cache breakpoints: up to 4 per request
• Cache hit reads are ~90% cheaper than input tokens
• Cache writes cost ~25% more than input tokens - only cache if you will read 2+ times

Batch API¶

• 50% discount vs real-time
• 24-hour SLA
• Up to 100K requests or 256MB per batch
• Use for: backfills, nightly evals, offline enrichment
• Do NOT use for: user-facing requests, sub-hour SLAs

Model Routing¶

Route cheap-to-classify tasks to Haiku 4.5, general work to Sonnet 4.6, deep reasoning to Opus 4.6. A common pattern: Haiku triages, Sonnet executes, Opus only when Sonnet flags low confidence.

Streaming¶

Reduces perceived latency but does not reduce total latency. Always stream for interactive UX. Stream tool calls when possible; Claude emits input_json_delta events as tool arguments are built.

Domain 4 - Governance, Safety and Risk Management¶

Safety Patterns¶

• Input classifier (Haiku) for jailbreak detection upstream of Opus
• Output classifier for PII or policy violations
• Structured refusal handling (do not retry refusals as if they were errors)
• Prompt injection defense: separate system instructions from untrusted content with XML tags and explicit warnings; assume injection can succeed and bound consequences at the tool boundary

Compliance Posture¶

• SOC 2 Type II, ISO 27001, ISO 42001
• HIPAA eligible on BAA (first-party API and Bedrock)
• Zero data retention (ZDR) available for qualified customers
• GDPR: Claude deployments are processor relationships; document lawful basis, retention, and data subject rights
• EU AI Act GPAI obligations apply; document your downstream use

Governance Essentials¶

• Audit log every model call: who, what, which model, prompt hash, cost
• Human-in-the-loop approval for irreversible or high-stakes actions
• Model risk management: inventory, owner, eval evidence, review cadence per deployed model
• See notes/08-governance-safety-and-risk-management.md

Domain 5 - Stakeholder Communication and Lifecycle Management¶

• Frame cost as cost-per-outcome, not tokens; executives buy outcomes
• Set expectations: probabilistic behavior, failure modes, and what "good" looks like, before launch
• Phase rollouts: internal pilot, limited cohort, general availability, each behind an eval gate
• Model lifecycle: track deprecation notices, pin model versions in production, plan migrations with eval comparisons, hold the old version for rollback
• Go/no-go gates: pre-agreed quality, safety, and cost thresholds measured on a held-out eval set
• Documentation: architecture decision records, runbooks, and enablement plans are deliverables, not afterthoughts
• See notes/09-stakeholder-communication-and-lifecycle-management.md

Domain 6 - Claude Models, Prompting and Context Engineering¶

Context Window Economics¶

Claude 4.x models support 200K tokens with 1M available in some configurations. Every token in context is paid for on every turn. Strategies:

• Cache the static prefix (system prompt, tool definitions, reference docs)
• Retrieve just-in-time rather than pre-loading
• Summarize old turns once they exceed a threshold
• Offload durable state to the memory tool
• Order: cache-eligible content first, then volatile content

Extended Thinking¶

Claude 4.x models expose a thinking block with configurable budget.

• Enable via thinking: {type: "enabled", budget_tokens: N}
• Budget is a soft cap; Claude may stop thinking early
• Thinking tokens are billed at output rates
• Thinking blocks are returned in the response and must be preserved when continuing a turn (opaque signature)
• Interleaved thinking lets Claude think between tool calls

When to Use Extended Thinking¶

• Complex multi-step reasoning (math, planning, difficult code)
• Tasks where a wrong answer is expensive
• Research and synthesis tasks
• NOT for: classification, simple rewrites, chit-chat

Memory Tool¶

Client-side persistent memory Claude can read and write across sessions. Key patterns:

• User-scoped memory for personalization
• Project-scoped memory for long-running agents
• Treat memory as append-mostly; prune aggressively
• Memory content still counts toward context when loaded

Domain 7 - Developer Productivity and Operational Enablement¶

• Claude Code and the Agent SDK share primitives (skills, hooks, subagents); capabilities built for one can be reused in the other
• Hooks enforce policy (PII redaction, audit) without touching agent business logic
• Shared MCP servers centralize tool access across teams; version them and log every execution
• Runbooks, on-call procedures, and internal training are part of shipping an agent, not optional extras

Exam Tips¶

Likely High-Yield Topics¶

1. Orchestrator-worker vs single-agent tradeoffs
2. Extended thinking token accounting and preservation
3. Prompt caching breakpoints and TTLs
4. Tool description design for large toolsets
5. MCP streamable HTTP vs stdio vs SSE
6. LLM-as-judge eval design
7. Bedrock vs Vertex vs first-party selection criteria
8. Batch API economics vs real-time
9. Prompt injection defense and human-in-the-loop gating
10. Model deprecation handling: pinning, migration evals, rollback

Common Traps¶

1. Defaulting to multi-agent when a single loop is cheaper
2. Caching content that is never re-read
3. Forgetting to preserve thinking signatures on turn continuation
4. Assuming Bedrock model IDs match Anthropic API IDs
5. Conflating memory tool with prompt caching
6. Using Batch API for user-facing paths
7. Over-tooling agents past ~20 tools
8. Treating refusals as retryable errors
9. Ignoring cache write cost when designing breakpoints
10. Using SSE transport for new MCP deployments
11. Answering governance questions with purely technical controls when the question asks for policy or process
12. Auto-upgrading production to new model versions without an eval gate

High-Yield Study Sequence¶

1. Take the free official CCAR-P prep courses in Partner Academy
2. Re-read the Anthropic engineering blog posts on multi-agent research and Claude Code
3. Build one orchestrator-worker agent end to end with evals
4. Deploy the same workload to Bedrock and Vertex; feel the diffs
5. Run a cost audit: cache hit rate, thinking ratio, tool-call count
6. Write a one-page governance memo and a rollout plan for that agent (Domains 4 and 5)
7. Walk through scenarios.md under timed conditions