CCA Professional · M1 — Platform & Solution Design

Exam domains covered: D1 — Solution Design & Architecture (17%), D2 — Claude Models, Prompting & Context Engineering (13%)

Approximate module runtime: 238 minutes of Anthropic learning content

The Four AI Properties

These four properties are the foundation of every architecture decision in the Professional exam. Memorise each property and its design consequence as a pair — the exam tests both halves.

How these map to exam domains:

• Non-determinism → evaluation frameworks (Domain 4)
• Knowledge boundary → retrieval design (Domain 3)
• Finite context → context engineering (Domain 2)
• Confidence ≠ correctness → human-in-the-loop design (Domain 5)

Known exam swap: Non-determinism and confidence-is-not-correctness get reversed constantly. Anchor on the exact verb: non-determinism → "you cannot certify behavior observed once" → evals. Confidence-is-not-correctness → fluent-but-wrong outputs → a human checkpoint is the architectural fix.

The Four AI Properties — Capability / Limitation / Mitigation Table

The exam uses two parallel naming systems for the four properties. Memorise both — either can appear in a question stem.

Context is a hard edge, not a gradual slope — design toward margin under the ceiling, never toward the ceiling itself.

The Four Architecture Patterns

The Decision Rule

Run this mental check in order:

1. Is the task a single transformation with supplied context? → Single augmented call
2. Are all steps known in advance and identical per request? → Fixed workflow
3. Does the path emerge during execution? → Autonomous agent
4. Do sub-tasks need different tools/specialisation AND can run in parallel? → Multi-agent

Invalid Reasons for Multi-Agent

The exam frequently offers options that select multi-agent for the wrong reason. These are never valid architectural drivers:

• High request volume
• Large project budget
• Executive enthusiasm for "sophisticated" architecture
• "Most advanced" = automatically best

The only valid drivers are task structure: known vs. emergent steps, and genuine need for parallel or specialised sub-tasks.

Fixed Workflow — When It Earns Its Design

Two conditions most strongly favor a fixed workflow:

1. Steps are known in advance and are the same for every request
2. The business requires each step to be individually auditable and reproducible

An autonomous agent that could "plan its own approach" is worse than a fixed workflow when auditability and reproducibility are required — you can't audit a plan that changes every run.

Also the answer when: a long single prompt is producing shallow or incomplete output on a multi-part task — decompose into sequenced subtasks rather than reaching for a bigger model.

Five-Factor Decision — Augmented LLM vs Workflow vs Agent

Agents score worse on nearly every factor except genuine unpredictability — the only factor that should pull you toward one.

"Uncertain how to structure it" ≠ "genuinely can't be determined in advance." If traces eventually reveal a small, fixed number of paths, that was a workflow from the start.

Four Workflow Sub-Patterns

Not mutually exclusive — most production workflows combine several.

Platform Entry Points

The exam distinguishes three layers of the Claude platform stack:

The Claude Code Disqualifier

Claude Code is a developer tool — an entry point for the terminal. It is automatically disqualified as an application backend the moment a brief contains any of:

• "multi-user"
• "customer-facing"
• "backend service"
• "deployed to users"

The exam will offer Claude Code as an option in questions about production systems. Recognize it as a trap immediately.

Compliance Precondition Override

When one option has a signed, confirmed compliance agreement (e.g. an existing BAA confirmed covered for the exact configuration), and another option proposes negotiating a new one — the existing coverage wins outright. This resolves the question before any other tradeoff (control, latency, residency) is even considered.

GDPR Residency Clarification

GDPR compliance does not require EU data residency. Cross-border transfer is lawful with a valid mechanism (SCCs, adequacy decision). Only select a "data residency" answer if the brief actually states a residency requirement — not merely GDPR compliance.

Three Deployment Layers — Exam-Exact Names

Three separate conversations, three different stakeholders. A decision in one layer rarely dictates the others.

Name the user before the entry point, then the entry point before the shaping/governing layers.

All Seven Primitives

Use the minimum primitives needed. A single tool call beats a team of agents when a tool call would suffice — cost scales with how heavy the primitive is, on every request.

The exam tests whether you match the right primitive to the requirement:

• "Guarantee a notification fires every time" → Hook
• "Run five sub-tasks in parallel" → Subagent
• "Distribute a standard document-review procedure to all teams" → Skill
• "Multiple AI apps need standardised access to one system" → MCP

Ownership Decomposition — The Three-Question Delegation Test

Every capability in a system lands in exactly one of three buckets:

1. What Claude does — language understanding, summarisation, planning, drafting, tool-mediated action
2. What existing systems do — anything already paid to be reliable (the order-status service, the policy engine, the rules table)
3. What humans do — judgment calls, exceptions, approvals — where being right matters more than being fast

For each capability, apply the three-question test before assigning it:

The over-assignment trap: Collapsing all three buckets into "what Claude does" makes the process more expensive, slower, and harder to debug. A deterministic rule that must be correct every time belongs to the rule engine, not a probabilistic model.

Worked example — claims triage:

• "Read the claim" → Claude (pattern-rich language work, constrained output schema)
• "Decide priority" → existing system (a deterministic rule the partner already defines)
• "Look up policy coverage" → existing system via tool use (coverage tables update; model training data goes stale)
• "Email the adjuster" → Claude drafts, email system sends, human reviews anything above a value threshold

The Four-Part Architecture

A complete architecture has exactly four parts. An answer that stops at output describes an incomplete system.

The feedback loop is the part most often omitted from answer choices that describe "a complete architecture." An architecture without it has no mechanism for detecting when it's degrading.

Feasibility Verdicts

When you run a use case through the four AI properties, you arrive at exactly one of three verdicts:

1. Feasible as scoped — the use case can be built as described
2. Feasible with constraints — buildable, but only under specific conditions (retrieval required, HITL required, scope must narrow, expectations must be set)
3. Not feasible — the use case cannot be built reliably

The exam presents ambiguous use cases and asks which verdict applies. The key is applying all four properties, not stopping at the first one that looks fine:

• A task might be deterministic-looking but require post-cutoff data → knowledge boundary → verdict shifts to "feasible with constraints (retrieval required)"
• A task might be well-defined but expect 100% accuracy → confidence ≠ correctness → verdict shifts to "feasible with constraints (HITL required)"

"Not feasible" is a correct outcome — it's the assessment doing its job, catching in design what would otherwise surface as a much costlier failure later.

The Scoping-Call Trap

"We can do that" (capability confirmed) ≠ "this is feasible" (feasibility verdict). A verdict requires volume, latency, and input-size constraints gathered first. The commitment to a build timeline must wait for the constraints — a confident capability answer is not a completed feasibility check.

Counter-intuitive arithmetic: A scary-sounding latency number (e.g. "under 30 seconds") can be trivially met at low volume. Meanwhile, a quiet detail like corpus scale or per-request cost at volume is often the actual binding constraint. Always run the numbers rather than trusting which constraint sounds scariest.

Prompt Caching Mechanics

How It Works

Caching matches on the prompt prefix — the beginning of the prompt, character for character. If the prefix matches a cached version, you get the cached result.

Cache TTL: 5 minutes by default. Prompt caching only pays off if your request frequency clears the TTL.

First-write cost: Writing a new prefix to cache costs more than a standard input token on first use. The saving only comes on subsequent hits. High-volume applications with stable prefixes benefit most.

The Placement Rule

Dynamic values must come after the static prefix. If you place a timestamp or request ID at position zero, every prefix is unique — zero cache hits guaranteed.

Wrong pattern:

[timestamp] [request-id] → [9,000 tokens of static policy] → [user message]

Correct pattern:

[9,000 tokens of static policy] → [timestamp] [request-id] → [user message]

When Caching Doesn't Help

• Request frequency is too low to clear the 5-minute TTL
• The "static" prefix actually changes per request (user names, context IDs embedded in it)
• The prompt is short enough that caching saves negligible tokens

Context Window Strategy

Positional Attention

Critical rules buried mid-context suffer from positional attention effects — the model attends most strongly to the start and end of the prompt. The fix:

• Place the most critical rules at the beginning or end of the system prompt
• Use clear structural separation between rules and reference content
• Never bury a hard constraint in the middle of 12,000 tokens of product context

What doesn't work: Repeating the rule after every paragraph, switching to uppercase, or lowering temperature. These don't change positional attention — they add noise or affect sampling randomness, not rule salience.

The Long-Document Problem

Placing a 150,000-token collection in the context window on every request causes two problems:

1. Mid-context recall degradation (content in the middle is less reliably used)
2. High cost per request

The fix is retrieval — serve only the sections relevant to each request, not the full corpus. This fixes both problems simultaneously, unlike reordering the prompt or asking the model to "read twice."

Technique Selection — When Each Earns Its Tokens

Uniform CoT application is a trap. Adding chain-of-thought to a simple field-extraction endpoint adds cost and latency with no accuracy improvement. Apply techniques per-task based on measured benefit, not as a default.

Model-Tier Discipline

The disciplined approach to model selection:

1. Test accuracy on a representative evaluation set across the model family
2. Select the smallest model that meets the accuracy target
3. Validate with ongoing evaluation to confirm it keeps meeting it

"Use the most capable model for everything" is never the correct answer. At 400,000 requests per day, the cost difference between model tiers is enormous — and if accuracy is comparable, the smallest model is the right choice.

Start with Sonnet class. Upgrade when evals show reasoning failures; downgrade when evals show the cheaper tier holds accuracy. "Best available model" is not a strategy — it's the absence of one.

Model-Tier API Patterns

"Every model swap is a release" — treat a model version change like a code release. Run the full evaluation suite against the new version before shifting traffic. Spot checks are insufficient.

Fine-Tuning — Last Resort, Not First Fix

Fine-tuning is the last step, not the first fix. The correct order:

1. Optimise the prompt — most reliability problems are prompt problems
2. Add tool use or retrieval — for knowledge boundary issues
3. Move to a stronger pattern — evaluator-optimizer, fixed workflow decomposition
4. Only then consider fine-tuning

Fine-tuning has a place at very high volume where inference cost is the real constraint, or for a consistent output format that prompting hasn't reliably solved. Fine-tuning Claude is not broadly available — confirm current options with the Anthropic account team before planning a fine-tuning approach.

Reference Architectures — Where Each Fails

Retrieval vs Live-State Principle

Retrieval is for stable knowledge — true yesterday, true tomorrow (documentation, policy text, manuals, training material).

Tool use is for live state — values a system owns and changes independently (order status, inventory levels, account balances, real-time prices).

Symptoms of the wrong choice:

• Stale chunks that contradict the database
• Results that shift with each index refresh
• Answers that don't match what the system-of-record actually holds

A better embedding model or a shorter refresh interval will not fix this — only calling the system that owns the live state directly does.

The exam trap: A retailer's assistant retrieved two chunks about the same order from different points in time. The order had shipped, been returned, and was awaiting re-dispatch — a state in neither chunk. A live order-status API existed and wasn't called. Similarity score measures semantic closeness to the query, not truth or freshness.

Module 1 Trap Patterns

Trap 3 — Platform name ≠ config: Selecting Claude Code, MCP, or Bedrock doesn't answer "how is it configured, what permissions does it have, and what integrations are wired." Naming the entry point and specifying its configuration are different claims.

Trap 11 — Architectural complexity justified by the wrong reason: Multi-agent selected because of volume, budget, or executive enthusiasm. The architecture should be driven by task structure, not any of those.

Over-assignment trap: Collapsing all three capability buckets into "what Claude does" makes the system more expensive, slower, and harder to debug. Deterministic rules that must be correct every time belong to the rule engine.

Scoping-call trap: "We can do that" is not a feasibility verdict. A verdict requires constraints gathered first — volume, latency, input size. Don't commit to a timeline before the constraints are known.

RAG-for-live-state trap: Using a retrieval index for data that changes frequently (order status, inventory) produces wrong answers that look right. The fix is tool use calling the system that owns the live state.

Key Rules to Memorise

• Four AI properties → four design consequences (non-determinism → evals, knowledge boundary → retrieval, finite context → strategy, confidence ≠ correctness → HITL)
• Three feasibility verdicts: feasible as scoped / feasible with constraints / not feasible
• Claude Code is disqualified the instant "multi-user" or "customer-facing" appears
• All seven primitives: Tool (act) / Subagent (isolate-parallelize) / Hook (guarantee) / Skill (package-a-procedure) / MCP (connect) / Agent Teams (coordinate peers) / Dynamic Workflows (compose at runtime)
• Prompt caching: dynamic values go after static prefix, not before; TTL is 5 min default
• CoT adds value on multi-step reasoning; adds cost only on simple extraction
• Model tier: smallest model that clears the accuracy bar, validated by eval; start with Sonnet class; every model swap is a release
• Ownership decomposition: Claude (language work) / existing systems (deterministic rules) / humans (judgment, exceptions)
• Four-part architecture: Input → Processing → Output → Feedback loop (the feedback loop is most often omitted)
• Three deployment layers: Entry Points / Build-time Interfaces / Delivery Routes
• Retrieval = stable knowledge; tool use = live state
• Fine-tuning is the last resort: prompt → tools/retrieval → stronger pattern → fine-tune
• GDPR compliance ≠ EU data residency requirement
• Compliance precondition override: existing signed agreement wins before any other tradeoff