Review this lesson in the 24 hours before the exam — not weeks before.
The cheatsheet is most effective when it serves as activation of knowledge you already built through the module lessons, not as first exposure.
The Master Pattern
A thing that looks handled and a thing that has been verified to be handled are different claims.
Every wrong answer on the Professional exam is a form of collapsing this distinction. When you are unsure which answer is correct, ask: which option is verified, evidenced, or owned — and which one is merely assumed or asserted?
All 12 Trap Patterns
| # | Trap | One-line description | Module |
|---|---|---|---|
| 1 | Right tradeoff word, wrong conclusion | Uses gain/give-up/reversal language correctly but inverts the content — quotes a gain as a give-up, or misidentifies the reversal cost | M4 |
| 2 | Collapsing layers | Conflates trained behavior (Anthropic's) with system-prompt enforcement (yours) — "Claude won't do X by nature" treated as equivalent to "the system prevents X" | M3 |
| 3 | Platform name ≠ config | Names an entry point (Claude Code, MCP, Bedrock) without specifying the configuration, permission posture, or integration that would actually enforce the requirement | M1 |
| 4 | Presence ≠ verified function | A control appears in the architecture diagram but has no named owner, no evidence artifact, and no test — it is asserted, not verified | M3 |
| 5 | Confidence ≠ correctness | Uses model output confidence as a proxy for accuracy — "95% confident" treated as "95% likely correct" | M1/M3 |
| 6 | Aggregate metric hides tail | Average accuracy looks acceptable while a specific demographic, document type, or query pattern is failing at a much worse rate | M2/M4 |
| 7 | Named-but-unowned = unenforced | A control is named in the compliance register but has no named owner and no evidence — it is a claim with the appearance of a control | M3 |
| 8 | Missing the third element | Gain and give-up are presented; reversal cost is omitted — the element that most often changes the decision | M4 |
| 9 | Scariest-sounding constraint isn't the binding one | A tight latency window or large document sounds alarming but is trivially met; the real bottleneck is corpus scale, not document size | M2/M3 |
| 10 | Everything reviewed = nothing reviewed | Routing 100% of decisions to a human is not the cautious choice — volume without triage collapses into rubber-stamping (consent fatigue) | M3 |
| 11 | Architectural complexity justified by the wrong reason | Multi-agent selected because of volume, budget, or executive enthusiasm — none of which are valid architectural drivers | M1 |
| 12 | An instruction asked to do a security layer's job | System-prompt instruction used to enforce data access control — instructions are not security boundaries; access control must make data structurally unreachable | M3 |
Decision Tables — Quick Reference
Architecture Pattern Selection
| Use when | Pattern |
|---|---|
| One transformation, context supplied | Single augmented LLM call |
| Steps known, stable, identical per request + auditability required | Fixed workflow |
| Path emerges during execution | Autonomous agent |
| Different specialisations + genuinely parallel sub-tasks | Multi-agent system |
Integration Mechanism Selection
| Use when | Mechanism |
|---|---|
| Multiple AI apps need standardised reuse of one system | MCP server |
| Single deterministic pipeline, owned internally | Direct API integration |
| Two orgs' agents must coordinate without internal exposure | Agent-to-agent protocol |
Reliability Control Placement
| Control | Layer |
|---|---|
| Retry | API call layer |
| Circuit breaker | Service boundary |
| Fallback chain | Orchestration layer |
Eval Method Selection
| Output type | Evaluation method |
|---|---|
| Checkable mechanically (format, schema, math) | Code-based |
| Requires interpretation (tone, reasoning quality) | Model-based (calibrated LLM judge) |
| Genuinely ambiguous or regulated | Human review |
HITL Routing Rule
Route to human when: low confidence AND (irreversible OR high cost)
Never route by volume alone.
Skills Distribution
| Requirement | Mechanism |
|---|---|
| Widest reach, entire org | Org-provisioned |
| Group-targeted, rollback needed | Plugin |
| Repo-scoped workflow | Project Skill |
| Programmatic, version-pinned | API Skill |
Feasibility Verdicts
Three and only three: feasible as scoped / feasible with constraints / not feasible
System Prompt — Four Required Components (in order)
- Role definition
- Testable criteria
- Boundary statements (explicit prohibition + named refusal response)
- Output format
A criterion is testable if you can write an eval test case that passes or fails based on it. Underspecification is a gap the model fills with its own assumption — differently each time.
Guardrail Layers — Type Column
| Layer | Type | Guarantee |
|---|---|---|
| 1. Input validation & injection screening | Deterministic | Yes |
| 2. System prompt constraints | Probabilistic | No |
| 3. Tool permission scoping | Deterministic | Yes |
| 4. Output filtering & moderation | Deterministic | Yes |
| 5. Human review | Human | — |
"What single control guarantees the agent cannot call the billing API?" → only removing it from the tool list (Layer 3).
Four Named Failure Modes
| Failure mode | Correct fix |
|---|---|
| Hallucination | Grounding: citations, retrieval requirements, output filtering for uncited claims — not a stronger instruction |
| Prompt injection | Screen retrieved content/tool outputs before injecting into context; treat external content as data not instructions |
| Data leakage | Least-privilege tool scoping; field-level access, not full record |
| Over-permissioned agents | Audit and trim tool list to the minimum required for the task |
Credential Storage
| Acceptable | Always wrong |
|---|---|
| Environment variables on deployment server | Hardcoded in source code |
| Dedicated secrets manager (Vault, AWS Secrets Manager) | Embedded in any prompt |
| — | In a README or documentation file |
Decision Logging — Three Audiences
| Audience | Needs |
|---|---|
| Affected user | Inputs + reason, in terms they can act on |
| Regulator | Durable queryable record of inputs, outputs, and decision path |
| Build team | Full trace: prompt, retrieved context, output, every routing step |
The Four AI Properties → Design Consequences
| Property | Design consequence |
|---|---|
| Non-determinism | Why evaluation frameworks exist |
| Knowledge boundary | Why retrieval and tools exist |
| Context as finite resource | Active context design, not passive "include everything" |
| Confidence ≠ correctness | Why HITL is architectural, not an afterthought |
The Four-Layer Safety Stack
| Layer | Blind spot |
|---|---|
| Trained behavior | Can't know your domain-specific rules |
| System-prompt instruction | Instructions can be ignored, misinterpreted, or injected past |
| Runtime screening | Can't see indirect injection via retrieved content/tool outputs |
| Authorization | Timing attacks and race conditions if not atomic |
Each layer's blind spot is what the next layer catches. Removing any layer leaves the next layer's predecessor's blind spot exposed.
Outcome Document — Six Fields
- Use case + scope boundary
- Metric before (same units as metric after — unrecoverable after launch)
- Metric after (same definition as before)
- Auditable control
- Measurement owner (named)
- Reuse potential
42-Term Master Glossary
Module 1
Non-determinism — Same input → different outputs. Consequence: why evals exist.
Knowledge boundary — Can't reliably supply rare/private/post-cutoff knowledge from memory. Consequence: why retrieval and tools exist.
Context as a finite resource — Fixed token budget; what enters it is an active design decision.
Confidence is not correctness — A wrong output can be as fluent as a right one. Consequence: why HITL is architectural.
Entry point / build-time interface / delivery route — Claude Code (entry point) / MCP (build-time) / Bedrock-Vertex-Foundry (delivery route).
Tools / Subagents / Hooks / Skills — Act / Isolate-parallelize / Guarantee / Package-a-procedure.
Feasibility verdict — Feasible as scoped / feasible with constraints / not feasible.
Prompt caching — Matches on prefix; only pays off if frequency clears TTL (5 min default); writes cost more on first use.
Module 2
Code-based / model-based / human-review eval — Grading ladder: use cheapest reliable method; escalate only when the tier below can't be trusted.
Judge calibration — Running an LLM judge against human-labeled outputs before trusting it at scale. Uncalibrated judge = worse than no automated grade.
POC-to-production gap — Cost, latency, reliability, and failure modes are invisible in a developer-supervised demo at low volume.
Retry / Circuit breaker / Fallback chain — API call layer / service boundary / orchestration layer.
Shadow testing — New version on real traffic, logged but never shown. Zero exposure; no real downstream signal.
Change attribution — Distinguishing model drift vs data drift vs model-update effect — each needs a different fix.
Testable criterion — A system-prompt rule you can write an eval test case for. "Be careful about security" is not testable; "Flag SQL injection and authentication bypass vulnerabilities" is.
Context strategy spectrum — Monolithic (full context always) / Progressive (append per turn) / Retrieval (RAG — fetch at query time) / Compaction (summarize old turns). Production systems almost always combine these.
Tool attribution — Every tool invocation must record: who triggered it / which permissions / against which resource / when. Logging only a service-account identity provides zero attribution.
Module 3
Alignment boundary — What trained behavior reduces (broad harm) vs what the application layer must enforce (domain policy, authorization).
Four-layer safety stack — Trained behavior / system-prompt / runtime screening / authorization. Each layer's blind spot is caught by the next.
Fail open vs fail closed — Per-guardrail decision based on the stakes of the guardrail erroring. Not a blanket policy.
Tool-call authorization — Must be deterministic, provable, and replayable. Runs before the side-effecting action.
Indirect prompt injection — Malicious instructions arriving via retrieved content or tool outputs, invisible to user-message screening.
Skill supply-chain risk — Distributable skill can carry a code-execution exploit. Mitigate with audit + runtime least-privilege sandboxing. Audit alone is insufficient.
Injection point (fairness) — Retrieval corpus / prompt framing / chosen examples / downstream routing. Four places unequal outcomes can enter.
Human-in-the-loop routing rule — Route when low-confidence AND (irreversible OR high-cost). Never by volume.
Consent fatigue — Reviewing too many items degrades review into rubber-stamping. Failure mode of routing 100% to humans.
Compliance control register — Maps obligation → technical control → named owner → evidence artifact.
Evidence artifact — Concrete, inspectable proof: signed agreement, config screen, authorization record, or log query. Not assertion.
Four named failure modes — Hallucination (confident falsehood) / Prompt injection (malicious instructions via user input or retrieved content) / Data leakage (sensitive data escapes) / Over-permissioned agents (broader tool access than task requires).
Proxy variable — A non-protected attribute (postcode, employment gap, school) that correlates with a protected attribute. Excluding the protected attribute doesn't remove the bias if a proxy variable encodes the same signal.
GDPR minimization — Architecturally: send less data rather than protect more of the same amount. Redact/pseudonymize PII before it leaves the system boundary — encryption in transit alone is insufficient.
Discernment — The reviewer skill of judging whether an output is acceptable, needs revision, or needs override. Requires a decision log as prerequisite — without a record of inputs and reasoning, there is nothing to judge against.
Decision log (three audiences) — Affected user (reason in actionable terms) / Regulator (durable queryable record) / Build team (full trace including retrieved context and routing).
Module 4
Discovery translation — Converting a preference word into a testable, bounded constraint by asking what would break the experience.
Translation table — Verbatim quote → implied constraint → architectural decision → labeled assumption with owner.
Reversal cost — What it costs to undo a decision after the system is built around it. The tradeoff element most presentations omit.
Scenario-specific demo — Built against the buyer's own workflow and data shapes. Creates confidence; generic demos create only interest.
Feedback loop — Signals → Triage → Decide → Act → Review. A signal is not yet a decision.
Governance table — Maps every production signal → trigger → Architect's action → scheduled checkpoint. Must exist before launch.
Documentation completeness — Test: can a competent Architect not in the room make a safe change after reading this? Required: decision, rejected alternatives, tradeoff, owner, evidence, and labeled assumptions.
Entry-point-responsibility map — Documents which Claude entry point owns which task and why in a multi-platform deployment.
Outcome document — Six fields: use case + scope / metric before / metric after (same definition) / auditable control / measurement owner / reuse potential.
Module 5
Champion-per-department rollout — Enable one champion per team first, capture their solved configuration, seed adoption in batches.
Shared configuration — CLAUDE.md + tool/MCP config + permission posture in version control; everyone starts from this baseline.
Skills distribution mechanisms — Org-provisioned (reach, no rollback) / plugin (versioned, rollback) / project Skill (repo-scoped) / API Skill (pinned).
Spend posture — Model defaults + allowlists + effort guidance + spend/rate/per-user caps — configured before the first bill.
Verification checklist — Correctness / security / maintainability / human understanding. Human understanding can never be automated.
Diligence — Taking responsibility for verifying and vouching for AI-generated output — catches judgment erosion.
Runbook — Symptom → cause → action → escalation. The cause layer prevents wrong-action pattern-matching.
Escalation path — Named definition of who handles what and when an issue leaves the team.
15-Item Final Checklist
Work through each item. If any takes more than 10 seconds, re-read the corresponding module lesson.
- Can recite the four AI properties → design consequence mapping without hesitation, including which one maps to evals vs. human-in-the-loop
- Can explain why Claude Code is disqualified as a backend the instant "multi-user" or "customer-facing" appears in a brief
- Know the eval grading ladder (code → model → human) and can state why an uncalibrated judge is worse than no automated grade
- Can name which reliability control (retry / circuit breaker / fallback) belongs at which layer of the stack
- Can state the training-time vs inference-time boundary and give an example of a rule Claude was "never given"
- Know the four-layer safety stack and each layer's specific blind spot, in order; can extend to the five-layer stack and identify which layers are deterministic vs probabilistic
- Can name the four named failure modes (hallucination / prompt injection / data leakage / over-permissioned agents) and the correct fix for each
- Know the system-prompt four-component structure (role → testable criteria → boundary statements → output format) and can distinguish testable from non-testable criteria
- Can explain why tool-call authorization is "almost always deterministic" while input/output screening can be model-based
- Know the human-review routing rule (confidence + reversibility + cost) and can spot "route by volume" as the wrong answer on sight
- Can name all three fields a compliance control register requires (control, owner, evidence artifact)
- Know the four discovery question categories and can invert a preference word ("seamless") into a testable constraint on the spot
- Can list all three elements of a tradeoff presentation and explain why reversal cost is the one that changes the meeting
- Know the outcome document's six fields, and which two become load-bearing under a strict regulatory obligation
- Can match all four Skills distribution mechanisms to their reach/rollback tradeoff without looking it up
- Know the four dimensions of a verification checklist for AI-generated code, and which one can never be automated away
- Reviewed the Trap Pattern Library once, end to end, within 24 hours of the exam
What to Do in the Exam Room
First 5 minutes: skim all 63 questions. Flag the ones you want to return to. Don't get stuck on question 3 when there are 60 more.
Per question:
- Read the question stem first
- Before reading options, form your own answer
- Check your answer against the options
- If your answer doesn't appear, apply the Master Pattern: which option is verified vs assumed?
Multi-select questions: find both correct answers before confirming. The first plausible-sounding answer is often a trap to make you stop looking.
Scenario-matching questions: the option set is small (3–4 choices). Map each scenario to its distinguishing characteristic: step structure (workflow vs autonomous), ownership (internal vs cross-org), reuse (one app vs many).
Time pace: 63 questions in 120 minutes = ~1:54 per question. Check your position at question 21 (40 min) and question 42 (80 min). Adjust pace if behind.
Practice the full 63-question exam under timed conditions at /quiz/cca-professional before sitting the real exam.