CCA Professional Complete Study Guide: Everything You Need to Pass

The HITL Routing Rule

Route to human review when two conditions are both met:

1. Low confidence (below a defined threshold)
2. AND (irreversible OR high-cost)

Routing on volume alone is always wrong. Routing 100% of decisions to a human is not the cautious choice — it collapses review into rubber-stamping (consent fatigue). Routing 0% is obviously wrong. The correct signal is: confidence × (reversibility + cost).

The Compliance Control Register

Every regulatory obligation must be mapped to:

Evidence artifacts are concrete and inspectable: a signed agreement, a config screen screenshot, an authorization record, a returned log query. A control asserted without an artifact is a claim, not proof. This is the Master Pattern applied directly to compliance.

Module 4 — Stakeholder Engagement & Lifecycle Management

Total content time: 178 minutes

Discovery: Three Steps

Every discovery conversation follows the same sequence:

1. Listen — capture what the stakeholder actually said, verbatim
2. Translate — convert their preference words into testable, bounded constraints
3. Write it down — produce a translation table row for every item

The Four Discovery Question Categories

Cover all four before moving to design:

The translation test: when a stakeholder says "seamless," ask "what would break the experience?" That answer is the actual testable constraint.

The Translation Table

One row per discovery item, four columns:

The documentation completeness test: Can a competent Architect who was not in the room make a safe change after reading this document? If no — because decisions are missing, alternatives aren't recorded, or assumptions aren't labeled — the document is incomplete.

Tradeoff Framing — Three Elements

Every tradeoff presented to a stakeholder must have all three:

1. Gain — what this option provides
2. Give-up — what this option costs or forfeits
3. Reversal cost — what it costs to undo this decision after the system is built around it

The reversal cost is the element most presentations skip, and the one that most often changes the meeting. A low-cost option with a high reversal cost (e.g. vendor lock-in) is different from a high-cost option with a low reversal cost (e.g. an abstraction layer). Stakeholders can't make an informed decision without it.

The Outcome Document — Six Fields

The before-metric is unrecoverable if not captured at the start. After deployment, the baseline no longer exists. If you skip it, you can never prove the system improved anything.

The Governance Table

Before any production launch, produce a table mapping every production signal to:

• The trigger (threshold that fires the signal)
• The Architect's action (what happens in response)
• Any scheduled regulated checkpoint (a periodic external review obligation)

This table must exist before launch. Governance designed after a problem occurs is incident management, not governance.

Stakeholder Objection Scripts

Two objection patterns the exam tests:

Objection 1: "Why can't we just use the AI for this? It seems obvious." Answer structure: Acknowledge the intuition → run the four-property feasibility check aloud → state the verdict with the specific constraint that changes it → offer the feasible version.

Objection 2: "The demo looked perfect. Why do we need all these guardrails?" Answer structure: Name the POC-to-production gap → identify the specific dimensions the demo didn't test → connect each gap to a specific failure mode in production → propose the minimum evidence to close each gap.

Module 5 — Team Enablement & Operational Readiness

Total content time: 45 minutes

Skills Distribution Mechanisms

Four mechanisms to distribute Claude capabilities to a team, with different reach and rollback tradeoffs:

The exam tests the reach vs. rollback tradeoff: org-provisioned has the widest reach but you can't roll it back natively; API Skill is version-pinned so rollback is precise but requires code changes.

Spend Posture — Set Before the First Bill

Spend posture must be configured before the first team member uses Claude, not after the first invoice arrives:

• Model defaults — which model tier is the default (not "whatever they choose")
• Allowlists — which capabilities are accessible to which roles
• Effort guidance — prompting conventions that prevent unnecessary token usage
• Spend/rate/per-user caps — hard limits enforced at the platform level

Unmanaged model choice multiplies across every team member. One engineer defaulting to the largest model for every task is an invisible spend multiplier.

The Champion-Per-Department Rollout Pattern

1. Enable one champion per team first — give them full access, let them discover and solve real friction
2. Capture the champion's workflow and tooling into shared configuration
3. Seed adoption in batches from that baseline — teams start from proven configuration, not from scratch

This avoids lumpy adoption (where teams stall at basic chat because nobody solved the setup friction before them).

Shared Configuration vs Personal Configuration

Teams default to personal configuration drift — everyone sets up Claude their own way. The correct architecture:

• Shared CLAUDE.md — team-level context, conventions, and constraints in version control
• Shared tool/MCP configuration — everyone starts with the same integrations
• Shared permission posture — agreed allowlists committed to the repo

A team where every member has a different Claude configuration is a team with no institutional knowledge about how Claude is being used.

The Verification Checklist for AI-Generated Code

AI-generated code must pass four dimensions before production:

Human understanding is the dimension that can never be automated away. Shipping code that no one on the team understands is the slow-burn failure mode: it passes all tests, goes live, and becomes unmaintainable the moment it needs to change. This is "diligence" — taking responsibility for verifying and vouching for AI-generated output.

The Runbook Structure

A runbook is not documentation — it is a captured decision path:

Symptom: [observable signal in production]
  ↓
Cause: [what this signal indicates about the system state]
  ↓
Action: [specific steps to take, in order]
  ↓
Escalation: [when to escalate, and to whom]

Runbooks let the team resolve recurring operational issues without the Architect. The symptom-to-cause-to-action structure prevents well-meaning but incorrect interventions (e.g., restarting a service that is fine because a different dependency is failing).

The Independent Review Principle

The same session that wrote the code cannot be the final reviewer of that code. The model is anchored to its own output and will rationalize rather than critique. Code review by a fresh session (or a human) catches the errors that anchoring conceals.

The 12 Trap Patterns

These are the 12 named failure modes the exam is written to catch. Review the full list in the 24 hours before the exam.

How to use this list on the exam: when a question has a "too elaborate," "too cautious," or "sounds thorough" wrong answer, check it against traps 10, 11, and 12. When it has a "sounds fine" wrong answer that misses something, check against traps 4, 5, 6, and 7.

The 42-Term Glossary

These are the terms the exam expects you to use precisely. The module label tells you which domain each term anchors to.

Module 1 Terms

Non-determinism — Same input can yield different outputs across runs. Design consequence: why evaluation frameworks exist — you cannot certify behavior observed once.

Knowledge boundary — The model cannot reliably supply rare, private, or post-cutoff knowledge from memory. Design consequence: why retrieval and tools exist.

Context as a finite resource — Fixed token budget; what enters it and when is an active design decision, not a default.

Confidence is not correctness — A wrong output can be as fluent and assured as a right one. Design consequence: why human-in-the-loop placement is architectural, not an afterthought.

Entry point / build-time interface / delivery route — Three distinct platform layers. Claude Code = entry point (dev, terminal). MCP = build-time interface. Bedrock/Vertex/Foundry = delivery route.

Tools / Subagents / Hooks / Skills — Act / Isolate-parallelize / Guarantee / Package-a-procedure — the one-word job of each primitive.

Feasibility verdict — Feasible as scoped / feasible with constraints / not feasible — the three allowed outcomes of running a use case through the four AI properties.

Prompt caching — Reduces cost of a stable, repeated prefix — only pays off if request frequency clears the cache TTL (default 5 min); writes cost more than standard input on first use.

Module 2 Terms

Code-based / model-based / human-review eval — Grading ladder: use the cheapest reliable method — code where checkable mechanically, a judge model where interpretation is required, human review only where neither can be trusted.

Judge calibration — Running an LLM judge against human-labeled outputs to confirm agreement before trusting it at scale. An uncalibrated judge is worse than no automated grade.

POC-to-production gap — Cost, latency, reliability, and failure modes are all invisible in a low-volume, single-request, developer-supervised demo.

Retry / Circuit breaker / Fallback chain — Reliability controls placed at the API call, the service boundary, and the orchestration layer respectively — placing one in the wrong layer leaves the real failure point exposed.

Shadow testing — New version runs on real traffic in parallel, output logged but never shown to users. Trades real downstream signal for zero exposure — often the only acceptable path in regulated deployments.

Change attribution — Distinguishing model drift, data drift, and model-update effects when a metric moves — each needs a different fix; mixing them up produces the wrong one.

Module 3 Terms

Alignment boundary — The line between what trained behavior already reduces (broad, general harm) and what the application layer must still enforce (domain policy, data rules, authorization).

Four-layer safety stack — Trained behavior → system-prompt instruction → runtime screening → authorization. Each layer's blind spot is exactly what the next layer catches.

Fail open vs. fail closed — How a guardrail behaves when it itself errors. An operator-built control that silently passes traffic on error is worse than no control — it looks like protection while providing none.

Tool-call authorization — Checks whether this caller may take this specific action, in this context, before a side-effecting action runs. Must be deterministic — provable and replayable.

Indirect prompt injection — Malicious instructions arriving via retrieved content or tool outputs rather than the user's own message — invisible to input screening unless retrieved content is screened too.

Skill supply-chain risk — A distributable skill can carry a code-execution exploit. Mitigate with audit (anomalous calls, out-of-scope operations) plus runtime least-privilege sandboxing — audit alone is insufficient.

Injection point (fairness) — Retrieval corpus, prompt framing, chosen examples, or downstream routing — the four places unequal outcomes can enter a system you control, independent of the model vendor.

Human-in-the-loop routing rule — Route to a person when low-confidence AND (irreversible OR high-cost). Confidence sets volume through the gate, not the stakes themselves.

Consent fatigue — Reviewing too many items degrades review into rubber-stamped approval — the failure mode of routing every decision to a human.

Compliance control register — Maps each regulatory obligation to a technical control, a named owner, and an evidence artifact a reviewer can inspect.

Evidence artifact — Concrete proof a control is live — a signed agreement, config screen, authorization record, or returned log query. A control asserted with no artifact is a claim, not proof.

Module 4 Terms

Discovery translation — Converting a stakeholder preference into a testable, bounded constraint by asking what would break the experience.

Translation table — One row per discovery item: stakeholder statement (as said) → implied constraint → architectural decision → assumption (labeled, with an owner to confirm).

Reversal cost — What it costs to undo a decision after the system is built around it — the tradeoff element most presentations skip, and the one that most often changes the meeting.

Scenario-specific demo — A demo built against the buyer's own workflow and data shapes. Creates confidence; a generic capabilities demo only creates interest.

Feedback loop — The decision layer above observability: Signals → Triage → Decide → Act → Review. A signal is not yet a decision.

Governance table — Pre-launch table mapping every production signal to its trigger, the Architect's action, and any scheduled regulated checkpoint — must exist before launch.

Documentation completeness — Test: can a competent Architect not in the room make a safe change after reading the document? Requires decision, rejected alternatives, tradeoff, owner, and evidence — with assumptions labeled as such.

Entry-point-responsibility map — Documents which Claude entry point owns which task and why, across a multi-platform deployment — prevents scope creep between routes.

Outcome document — Six fields: use case + scope boundary, metric before, metric after (same definition), auditable control, measurement owner, reuse potential. The before-metric is unrecoverable if not captured at the start.

Module 5 Terms

Champion-per-department rollout — Enable one champion per team first to prove the workflow and absorb friction, then seed adoption in batches — avoids lumpy adoption and stalling at basic chat.

Shared configuration — A single team baseline (CLAUDE.md, tools/MCP, permission posture) that every member starts from instead of drifting personal setups.

Skills distribution mechanisms — Org-provisioned (reach, no native rollback) / plugin (group-targeted, versioned, rollback) / project Skill (repo-scoped) / API Skill (programmatic, version-pinned) — reach and rollback trade off across the four.

Spend posture — Model defaults, allowlists, effort guidance, and spend/rate/per-user caps set before the first bill — unmanaged model choice multiplies across every team member.

Verification checklist — Correctness, security, maintainability, human-understanding checks AI-generated code must pass before production. Human-understanding is the dimension that can never be automated away.

Diligence — Taking responsibility for verifying and vouching for AI-generated output — the discipline that catches judgment erosion (shipping code no one on the team actually understands).

Runbook — Captured symptom-to-cause-to-action paths letting a team resolve recurring operational issues without the Architect.

Escalation path — A named definition of who handles what, and when an issue leaves the team — the organizational counterpart to a runbook's technical knowledge.

The 15-Item Final Checklist

Use this in the 24 hours before the exam. If you can answer each item fluently, you're ready.

• 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 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.

7-Domain Weight Reference

Integration carries the most weight (19%) and is the domain most people underestimate. The traps that appear there — authorization by instruction, tool bloat, uncalibrated retrieval, stale indexes — are all forms of the Master Pattern.

Practice

All 63 questions from the official blueprint's item count and domain weighting are available at /quiz/cca-professional. Practice Mode shows the full rationale for every wrong answer immediately. Exam Mode gives you 120 minutes with no feedback, matching the real exam timing.

For Foundations-level review: /cca-quiz and /quiz/claude-certified-architect.

Good luck. If you can apply the Master Pattern to any question — ask "which option is verified vs. assumed?" — you are ready for the exam.