Last Step

How the CCA-F exam thinks

The exam rarely asks for a definition. It gives you a production failure and asks which mechanism owns the fix. This page teaches that reasoning layer. The five domain pages then teach each task statement in full, with mechanisms, worked examples, traps, and build exercises.

15 minute read·Five domains weighted 27, 20, 20, 18, and 15 percent·720 of 1000 to pass
The six pages
One page per exam domain, plus this reasoning overview.
01Overview
How the exam thinks
Decision axes, trigger wording, distractor styles, and a six-step algorithm
You are here
0227%
Agentic Architecture and Orchestration
Loops, orchestration, subagent context, enforcement, hooks, decomposition, sessions
Open
0318%
Tool Design and MCP Integration
Schemas, structured errors, toolkit shape, MCP configuration, built-in tools
Open
0420%
Claude Code Configuration and Workflows
Memory hierarchy, skills and commands, scoped rules, plan mode, refinement, CI
Open
0520%
Prompt Engineering and Structured Output
System prompts, examples, schemas, validation loops, batching, multi-pass review
Open
0615%
Context Management and Reliability
Context budgets, escalation, error propagation, degradation, calibration, provenance
Open
The recurring decision axes
Twelve distinctions the exam reuses across every domain. Identifying the axis a question sits on usually eliminates half the options immediately.
Guidance versus enforcement
Shaping model behaviour with prompts and examples, versus guaranteeing an outcome with a hook, gate, or schema. This is the most reused axis in the exam.
Syntactic versus semantic correctness
Whether the output parses, versus whether it is true. A schema validator and a business validator answer different questions.
Transient versus permanent failure
Timeouts and rate limits justify a bounded retry with backoff. Missing data, permission denials, and business rule violations need a different exit.
Prompt change versus architecture change
Some failures are wording problems. Others are allocation problems that only a different structure fixes: multiple passes, routing, isolation, caching.
Shared versus personal scope
Configuration that must reach every clone belongs in the repository. Personal preference belongs in a user-scoped file.
Same context versus independent review
A reviewer that carries the generator's justifications is a weaker reviewer. Independence has to be structural.
Access failure versus valid empty result
A query that could not execute and a query that executed and found nothing look similar in a response body and mean opposite things.
Parallel versus dependency-bound
Independent work runs concurrently. A prerequisite chain runs in order, with the prerequisite enforced rather than requested.
Helping selection versus forcing selection
Better descriptions and scoped toolkits improve which tool the model picks. Forcing a tool removes the choice entirely.
Preserving versus compressing context
Summarization buys budget and costs fidelity. Transactional facts, exact wording, and structured data should survive outside the summary.
Aggregate versus segmented measurement
One headline accuracy number can hide a segment that fails badly. Calibration is per document type and per field.
Asserting versus attributing
A claim with a source, an excerpt, and a date can be audited. The same sentence without them cannot, no matter how plausible it reads.
Wording that should make you stop
These phrases are not decoration. Each one narrows the space of correct mechanisms.
If the question saysThink about
must always / every time / guaranteeDeterministic enforcement. A hook, a prerequisite gate, or a schema constraint. Prompting raises the odds; it does not remove the failure rate.
sometimes / occasionally / inconsistentBehavioural guidance. Clearer criteria, examples, or a sharper system prompt. The model understands the task and drifts on variance.
after tool execution / after each tool callA PostToolUse hook or normalization step in application code, so the model never has to reinterpret heterogeneous formats.
before the action happens / must never runA PreToolUse hook. Post-execution logic can flag, but it cannot prevent.
shared with every developer / same repositoryProject-scoped configuration committed to the repo, not user-scoped configuration in a home directory that never travels with a clone.
the information is absentNot retryable. A retry cannot invent data that was never present. Ask, escalate, or return an explicit gap.
the information is present but in the wrong fieldRetryable with targeted feedback. Return the document, the failed output, and the specific validation error.
structurally valid but semantically wrongSyntax validation passed. You need a semantic layer. Valid JSON is not correct business data.
independent review / second opinionA separate session or agent. Same-session self-review inherits the reasoning that produced the output and is less likely to challenge it.
overnight / weekly / results consumed laterBatch processing for the cost saving. Anything blocking a person or a merge stays synchronous.
human approval required / high stakesA policy gate that surfaces the operation for approval. A self-reported confidence number is not a policy.
the model must use a tool but may choose whichForcing any tool differs from forcing one named tool. Read which one the stem needs.
steps are independentParallel tool calls or parallel subagents. A producer-consumer dependency has to stay sequential.
one agent has more than ten toolsSelection complexity. Consolidate near-duplicates, scope by role, or split agents. Better wording alone may not rescue it.
the same long prefix on every requestPrompt caching. The cached prefix must be byte-identical and everything dynamic has to come after the breakpoint.
97 percent overall accuracyAn aggregate is not permission to automate. Segment by document type and field before reducing review.
the enum keeps growingA resilient schema with an other value plus a free-text detail field, not an endless enum.
the stated total does not match the line itemsCross-field validation in the schema, with human review only on mismatch.
resumed after several hours and the files changedOld tool results are stale. Start clean with an injected summary and re-read only what changed.
the agent now describes typical patternsContext degradation. Externalize findings to a scratchpad and isolate verbose exploration in subagents.
The eight distractor styles
Wrong answers are engineered, not random. Recognising the style lets you eliminate before you finish the full analysis.
01Guidance where enforcement is required
Why it tempts. Examples and firmer wording genuinely improve behaviour, so the option reads like good practice. It is bait whenever the stem uses an absolute.
Eliminate by asking. Choose the mechanism that runs outside the model's discretion.
02Right idea at the wrong layer
Why it tempts. The concept is correct but placed in the wrong owner: tool definitions described in prose, transport concerns handled by a prompt, policy expressed as a request.
Eliminate by asking. Ask which layer owns the guarantee: API parameter, prompt, tool schema, application code, or infrastructure.
03Treats the symptom, not the cause
Why it tempts. Retrying a missing-information failure, truncating instead of restructuring, adding agents instead of widening the decomposition.
Eliminate by asking. Ask whether the option changes why it failed or only what the failure looked like.
04More machinery than the problem needs
Why it tempts. A multi-agent system for a single-agent task, or a routing layer for two poorly described tools.
Eliminate by asking. Prefer the simplest mechanism that still guarantees the required outcome.
05Correct concept, wrong scenario
Why it tempts. An accurate description of one primitive offered for a question about a different primitive.
Eliminate by asking. Map the noun in the scenario to the primitive that owns it before comparing options.
06Vague criteria instead of checkable criteria
Why it tempts. Instructions like be careful or check validity feel reasonable but cannot be evaluated.
Eliminate by asking. Prefer machine-checkable criteria: schema, enum, regex, explicit checklist.
07Retries something unrecoverable
Why it tempts. Retry is the reflex for any failure, and the option usually adds a sensible-sounding backoff.
Eliminate by asking. Separate transient failure from permanent failure and from a valid empty result.
08Loads far more context than the task needs
Why it tempts. Providing everything feels safe and thorough.
Eliminate by asking. Load the minimum relevant context and place the decisive material where attention is strongest.
A six-step algorithm for unfamiliar questions
Roughly thirty seconds of deliberate reasoning per scenario.
  1. 1
    Find the actual requirement
    The binding constraint usually sits in the last sentence: cost, latency, reliability, safety, or maintainability. Note whether the stem uses an absolute or a frequency word.
  2. 2
    Decide guidance or enforcement
    Words like sometimes and inconsistent point at clearer instruction and examples. Words like must always and guarantee point at a hook, gate, or schema constraint. Confusing these is the single most common error.
  3. 3
    Identify the owning layer
    API parameter, system prompt, tool schema, application code, project configuration, or infrastructure. A correct idea placed in the wrong layer is still a wrong answer.
  4. 4
    Classify the failure
    Transient failures justify a bounded retry. Validation failures need corrected input. Permission and business failures need a different path. A valid empty result is an answer, not a failure.
  5. 5
    Find the disqualifying detail in each alternative
    Every distractor violates one stated constraint: wrong scope, wrong primitive, unverifiable criteria, self-review, an uncalibrated signal, or an overloaded toolkit.
  6. 6
    Choose the least machinery that still guarantees the outcome
    The exam rewards the simplest sufficient design, not the most elaborate one.
Still stuck between two options

Reread the final sentence of the stem. The correct option answers the stated constraint directly; the runner-up answers a secondary concern. Then check strength of language: an option promising a guarantee is mismatched to a stem describing occasional drift, and an option offering better guidance is mismatched to a stem demanding a guarantee.

What the domain weights mean for your time

Agentic architecture carries the largest share, and its concepts reappear inside the other domains: enforcement, delegation, decomposition, and session state all resurface in tool design, Claude Code, and reliability questions. Time spent there pays twice.

Claude Code and prompt engineering are next, and they are the most mechanically precise. Configuration precedence, memory scoping, command flags, schema behaviour, and validation loops either match the documented behaviour or they do not. These are the cheapest marks to secure with careful reading.

Tool design and context reliability reward diagnosis. The scenarios describe a failure and ask for the root cause, so the value is in distinguishing a wording problem from a structural one, and a transient failure from a permanent one.

Official sources
Every claim across these pages traces to Anthropic documentation, Anthropic engineering writing, or a lesson on this site. Verify version-specific flags, limits, and pricing against the live docs before relying on them in production.
Start with Agentic Architecture27 percent, the highest weightFind your weakest domainBased on your answered questionsTake a weighted mockScaled scoring, 720 to pass
Blueprint Exam strategy All lessons