CCAR-P Learning Guide · Cheat sheet
CCAR-P exam cheat sheet
The whole Professional guide on three printed pages or fewer: the decision rules, the tables worth memorising and the distractors the exam keeps offering, domain by domain. Read it the day before the exam.
Numbers like 1.1 open the lesson behind each point.
63items
120minutes
720to pass, of 1000
- D1 Solution Design & Architecture 17%
- D2 Claude Models, Prompting & Context Engineering 13%
- D3 Integration 19%
- D4 Evaluation, Testing & Optimization 16%
- D5 Governance, Safety & Risk Management 14%
- D6 Stakeholder Communication & Lifecycle Management 14%
- D7 Developer Productivity & Operational Enablement 7%
How to read a CCAR-P question
Most items give a scenario, a constraint and four designs. Six habits pick the right option:
- Find the binding constraint first. A p95 latency target, an audit need, data residency, a budget or an approved vendor usually rules out two options.
- Authoritative values come from owning systems. Balances, prices and status are fetched by a tool call; numbers are computed in code. Claude does the language work.
- Enforce outside the model. Authorization, limits and approvals live in code, permissions and gates, never only in the prompt.
- Start simple, escalate on evidence. The simplest pattern, model tier and prompt that meet the bar; change only when an evaluation shows the gap.
- Measure the right thing. The tail of latency under load, cost per successful outcome, results by slice rather than one average.
- Classify before fixing. The model upgrade is rarely the first answer.
Domain 1 · 17%Solution Design & Architecture
| Pattern | Pick it when | Watch out for |
|---|---|---|
| Augmented LLM (one call with tools or retrieval) | One bounded task, tight latency | Having a tool does not make it an agent |
| Workflow (chaining, routing, parallelization, evaluator-optimizer) | Steps can be listed in advance; audit needs | Cost and latency add up per step |
| Agent (the model chooses the sequence) | The path differs every time | Bound it with budgets, permissions and approval gates |
- Feasibility: Claude reads, extracts, classifies, drafts and explains; a person checks where a wrong answer is costly or irreversible. "Feasible with constraints" and "not feasible" are valid verdicts. 1.1
- Two kinds of data: facts that stay true between index refreshes (policies, manuals) go to retrieval; values that change on their own (balances, order status) are fetched at request time. Stale answers are an access-pattern problem, not a retrieval-tuning one. 1.2
- Multi-agent for breadth, not sequence. Independent sub-tasks can justify parallel subagents; dependent steps want a single agent or a chain. Add trace IDs, a conflict rule, validation of subagent output and checkpoints (a lost coordinator state needs checkpointing, not subagent retries). 1.4
- Decompose by owner: language tasks to Claude, data and rules to existing systems, consequential approvals to people. Numbers belong to code. Split only at real seams. 1.5
- Value cases: state the benefit in the stakeholder's unit, from a measured baseline, with real run cost and the review labour the design keeps. Cost from the distribution, not the average request. SLAs are about the tail (p95 or p99 under concurrent load). 1.6
Domain 2 · 13%Claude Models, Prompting & Context Engineering
- Models: start with the balanced tier; move up or down only on evaluation evidence; route mixed workloads by difficulty; treat every model change as a release with a threshold set in advance. Wrong facts are not fixed by a bigger model. 2.1
- System prompts: role, explicit constraints and an output contract; fixed rules in the scaffolding, never in fields user content can influence; structured outputs (a JSON schema) when code parses the reply; consequential rules backed by checks outside the model. 2.2
- Technique progression: zero-shot and measure; add few-shot for inconsistency or subtle categories (include borderline cases); add step-by-step reasoning for real intermediate steps; exact figures come from code, not chain-of-thought. 2.3
| Context strategy | Fits | Main risk |
|---|---|---|
| Monolithic | Bounded tasks needing all material at once | Cost and clutter as it grows |
| Progressive | Multi-step workflows, agents | Dropping something needed later |
| Retrieval | Large or changing knowledge, citations | Missing the right passage |
| Compaction | Long sessions near the limit | Losing identifiers, numbers, decisions |
- Two ways to run out of room: the request is too large to send (rejected, nothing generated), or it fits and the output hits the ceiling (cut off). Count tokens, reserve output room, trim. The API remembers nothing; the application carries state. 2.4
- Reuse: caching for the cost and latency of a repeated prefix; a modular prompt library for phrases teams adapt; a Skill for a governed, versioned procedure or bundled scripts. Caching puts static content first, dynamic content after the breakpoint; any change before it (a timestamp at the top) is a miss. Caching is not memory. 2.5
Domain 3 · 19%Integration
| Interface | Choose it when |
|---|---|
| Direct API or client SDK | One request, one response inside your product (SDK is the default) |
| Agent SDK | Claude must act over many turns inside your application |
| MCP | The same tools must reach several Claude clients |
| Claude Code | The users are developers in a codebase, never a customer backend |
- Compliance, approved vendors and data location rule routes out first; then pick the API or the cloud platform the organization's agreements cover. 3.1
- Security: identity established on the server, authorization at the data (the order service refuses other customers' orders), least-privilege tools and credentials, reads where writes are not needed. Authentication is not authorization. 3.2
- Capability bloat: every tool must justify itself; remove what no step uses, especially destructive tools. A bigger model does not fix a cluttered tool list. 3.3
- Monolithic until it hurts, then discover: a small, stable tool set is loaded up front and cached; dozens of tools or procedures move behind Skills, tool search or just-in-time retrieval. 3.4
- RAG: chunk by document shape (keep sections and clause numbers), hybrid search when identifiers matter, refresh as often as documents change, and measure retrieval separately from answers. Live data never goes in the index. 3.5
| Data shape | Retrieval method |
|---|---|
| Unstructured text | Chunked index: dense, sparse or hybrid |
| Structured records | A query or API call with filters, never embeddings over rows |
| Tables and metrics | SQL, drafted by the model, run by code with read-only scoped access |
| Live state | A tool call to the owning system |
| Codebases | Agentic search: list, grep, open step by step |
- Filter first, rank second when the question names a scope (a policy year, a product). Rerank only where accuracy outweighs latency. 3.6
- Accuracy and latency: find the binding constraint, then move thinking, tier, caching, parallel tools, reranking or batch. Streaming does not cut latency for a step the next step must wait for. 3.7
- Observability: trace IDs across components, prompt and model versions in every log line, outcome signals, per-tenant keys or workspaces for cost attribution, anomaly alerts. Do not keep full transcripts by default. 3.8
Domain 4 · 16%Evaluation, Testing & Optimization
- Metrics: specific and measurable across accuracy, latency, cost, safety and security, defined before building. Code checks for binary safety rules, latency at a high percentile, cost per success not per call, results read by category. 4.1
- Datasets and graders: a golden set from real traffic plus hard, adversarial and negative cases, growing with every production failure. Grade with code first, a calibrated rubric-based model judge for interpretation, people for high stakes and calibration. 4.2
- Experiments: offline evaluation first; shadow test when one bad output could cause harm or traffic is low; A/B test when user behaviour must be measured. Hypothesis, primary metric, sample size and stop rule fixed in advance; random, sticky assignment. 4.3
| Failure | What you see | First action |
|---|---|---|
| Prompt failure | Reasonable but not what was wanted | Specific instruction, output contract, examples |
| Hallucination | Fluent, unsupported facts | Ground it with a tool or retrieval; allow "I don't know" |
| Retrieval failure | Wrong passage, or "not found" when it exists | Inspect what was retrieved; fix chunking or filters |
| Model mismatch | Shallow on hard cases only | Evaluate another tier on that slice |
| Context problem | Worse late in long sessions | Trim, compact or split |
| Orchestration failure | Silent gaps in multi-agent output | Trace across agents; validate coverage |
- Diagnose with evidence: what was retrieved, the stop reason, which slice fails, what changed recently (a prompt version in the logs). 4.4
- Monitoring: sampled online evaluation, outcome signals, baselines with thresholds, pinned model versions (not floating aliases), findings fed back into the evaluation set. A green error dashboard can hide wrong answers. 4.5
- Optimization order: remove what is not needed, cache stable prefixes, trim tool results and compact, limit output, then evidence-backed thinking and tier changes, then batch what can wait (about half the cost). Find the cost distribution first; never cut quality controls. 4.6
Domain 5 · 14%Governance, Safety & Risk Management
- Assume the model can be fooled. A fully manipulated model must still be unable to reach data the user may not see, take actions the user may not take, or act irreversibly without approval. Screen documents and tool results too, because injection is often indirect. 5.1
| Control point | Runs | Typical checks |
|---|---|---|
| Input screening | Before the model call | Limits, injection classifier, PII redaction |
| Output screening | Before the reply is delivered | Schema, forbidden content, grounding |
| Action authorization | Before any side-effecting tool runs | Identity, permission, scope, limits, approval |
- Deterministic checks for exact rules and authorization; model-based checks for open-ended language risks. Consequential controls fail closed. An output filter cannot undo a refund already issued. 5.2
- Human review routing: a person when confidence is low and the decision is irreversible or costly; high-stakes decisions may need review even at high confidence. Pre-action approval for irreversible actions, sampling or audit for reversible ones. Give reviewers evidence; avoid flooding them. 5.3
- Compliance: every obligation (HIPAA, GDPR, residency, FedRAMP) gets a control, an owner and current evidence. The route must be covered for the exact features used; logs, caches, traces, backups and embeddings are copies of the data too. 5.4
- Fairness: check every step that retrieves, classifies or routes; measure outcomes by group where lawful, use counterfactual tests, and log decisions well enough to explain each one. 5.5
Domain 6 · 14%Stakeholder Communication & Lifecycle Management
- Discovery's four questions: what must it do, what must it not do, what must it cost, what must it prove? Turn phrases into measurable constraints ("feel instant" becomes a p95 target). A requirement without a source is an assumption: label it and confirm it. 6.1
- Trade-offs: for every option state the gain, the cost and the reversal cost, in the decider's language, then recommend. Stated requirements (an audit trail) cannot be traded away for speed. 6.2
- Feedback loop: signals, triage, decide, act, review. Triage to internal monitoring, architect review, stakeholder review or noise. An SLA has a metric, a threshold, a breach definition and a response. Calendar checks run whatever the metrics say. 6.3
- Handoff documentation: a decision log with rejected options and reasons, an assumption register, runbooks and a control register with evidence. A diagram shows what, not why. 6.4
- Lifecycle: diagnose before re-architecting (a prompt problem is fixed by iteration); expansion waits for an outcome document with a real before-and-after measurement, a working control and a named owner. 6.5
Domain 7 · 7%Developer Productivity & Operational Enablement
- Musts in settings, shoulds in instructions: denied secrets, protected-branch pushes and approved MCP servers go in managed settings, permissions or hooks; conventions go in CLAUDE.md. Distribute Skills by audience, set spend limits up front, roll out through champions and batches. 7.1
- Workflows: give Claude a way to verify its work, keep changes reviewable, and keep the author accountable: passing tests is not understanding, and an AI review is input, not the verdict. 7.2
- Operations: connect the symptom to a cause using traces, change history and evaluation runs; end every incident with a runbook entry and an escalation path. Do not swap models first. 7.3
Distractors the exam keeps offering
| Tempting option | Why it is wrong |
|---|---|
| The most capable model "to be safe" | Not evidence-based; costs more |
| "Tell the model to verify the user" | The model can be persuaded; the server cannot |
| Multi-agent or MCP as the "advanced" answer | Adds cost and failure points without a need |
| Output filter as the safety net for actions | Authorization must come before the action |
| Fail open to stay available | Wrong for money, data or safety controls |
| One overall score or average latency | Hides slices and the tail |
| "The provider is certified, so we comply" | Coverage depends on the exact configuration |
On exam day
- 63 items in 120 minutes is just under two minutes each. Flag anything slow and come back to it.
- Each item says how many responses to select. Read that line before the options.
- The score is scaled to 1,000 with 720 to pass, so a raw percentage does not convert directly. Aim for 80% or more in the practice tests.
Unsure about a point? Open its lesson from the number beside it. Ready to check yourself? Take the CCAR-P practice tests.