One Day Before the Claude Certified Architect Exam

One Day Before the Claude Certified Architect Exam

The Last-Minute CCA-F Cheat Sheet

You have one day left.

This is not the day to learn Claude from scratch.

It is not the day to memorize another 300 pages of documentation.

And it is definitely not the day to convince yourself that you need to know every method, parameter, configuration option, or obscure feature in the Claude ecosystem.

The Claude Certified Architect – Foundations (CCA-F) exam is fundamentally an architecture and judgment exam.

The question behind most questions is:

Given this situation, what is the simplest, safest, most reliable architectural choice?

If you understand that, much of the exam starts collapsing into a relatively small set of patterns.

This is the cheat sheet to read the night before the exam, over breakfast, or sitting in the car before walking into the testing center.

First: Know the Battlefield

The CCA-F exam covers five domains:

Domain

Weight

Agentic Architecture & Orchestration

27%

Claude Code Configuration & Workflows

20%

Prompt Engineering & Structured Output

20%

Tool Design & MCP Integration

18%

Context Management & Reliability

15%

The exam contains approximately 60 questions in 120 minutes.

That gives you roughly:

2 minutes per question.

The passing score is 720 on a 100–1,000 scaled score.

The questions are heavily scenario-oriented.

That matters.

You aren’t merely being asked:

What is an MCP server?

You’re much more likely to face something conceptually like:

A development team needs Claude to retrieve information from Jira and update an external system. Which architecture provides the cleanest separation between Claude’s reasoning and the external system?

Now you’re making an architectural decision.

That’s the exam.

The Master Mental Model

Before remembering anything else, remember this:

Claude reasons.

Tools act.

Applications orchestrate.

Hooks enforce.

Skills teach reusable workflows.

MCP connects external capabilities.

CLAUDE.md governs repository behavior.

Subagents isolate specialized work.

External systems hold durable state.

If you can keep those boundaries straight, you can eliminate a surprising number of wrong answers.

The 15-Second Decision Tree

When stuck between two answers, ask:

Need deterministic enforcement?

Hook

Don’t ask the model to “remember” something that absolutely must happen.

If an action must always occur, enforce it deterministically.

Need reusable expertise or a workflow?

Skill

Think:

“Claude needs to know how our organization performs this kind of task.”

That’s a skill.

Need external data or an external capability?

MCP / Tool

Think Jira, databases, APIs, GitHub, ServiceNow, Salesforce, internal services, etc.

Claude shouldn’t magically know external state.

Give it a controlled interface.

Need focused investigation or context isolation?

Subagent

Give the specialized worker the context it needs instead of polluting the primary context.

Need repository-wide guidance?

CLAUDE.md

Coding standards.

Architecture rules.

Repository conventions.

Build/test commands.

Project-specific instructions.

Need to understand before modifying?

Plan Mode

Explore first.

Understand dependencies.

Develop the approach.

Then implement.

Is the context getting polluted?

Think:

/compact

or

/clear

But know the difference.

Compact preserves useful context in summarized form.

Clear starts fresh.

Need durable workflow state?

External state store

Not Claude’s context window.

Not “the agent will remember.”

Databases, workflow engines, durable stores, checkpoints, or equivalent infrastructure hold state.

Side effects + retries?

Think:

Idempotency

plus

bounded retries

plus

backoff

Retries without idempotency can create duplicate side effects.

Long-running distributed workflow?

Think:

checkpoint + state + Saga/compensation

Don’t pretend a distributed transaction across multiple services is one giant ACID transaction.

High-risk action?

Think:

deterministic controls + human approval

Claude can recommend.

Claude can reason.

Claude can prepare.

Some actions should still cross an explicit deterministic or human boundary.

DOMAIN 1 — Agentic Architecture & Orchestration

This is the largest domain.

Understand the agentic loop.

Conceptually:

Receive objective

↓

Reason

↓

Choose action/tool

↓

Execute tool

↓

Receive result

↓

Reason again

↓

Continue or stop

The important point:

Claude does not execute your external tools itself.

Claude requests a tool operation.

Your application executes it.

Your application returns the result.

Claude continues reasoning.

Think:

Claude → tool request → application → external system → tool result → Claude

Tool Use: Burn This Into Your Brain

Claude determines that it needs a tool.

The response contains a tool-use request.

Your application:

1. detects the request,

2. identifies the requested tool,

3. executes it,

4. captures the result,

5. returns the corresponding tool result,

6. calls Claude again.

Repeat until the model reaches the appropriate stopping condition.

Exam trap:

Don’t invent your own heuristic for determining when Claude is finished if the API provides an authoritative lifecycle signal.

Use the API’s control information, including the appropriate stop reason, rather than brittle assumptions about response contents.

Multiple Tool Calls

If multiple tools are requested, results must remain associated with the correct requests.

Remember:

Match tool results to their

tool_use_id

.

Never rely on:

“That was probably the second call.”

Correlation matters.

Multi-Agent Architecture

Don’t create multiple agents simply because “agentic AI” sounds sophisticated.

Use multiple agents when specialization or context isolation creates a real advantage.

Typical pattern:

Coordinator

↓

Specialized subagents

Examples:

• code-analysis agent

• security-review agent

• documentation agent

• test agent

The coordinator decomposes and synthesizes.

The specialists operate within focused context.

Exam trap:

More agents ≠ better architecture.

Every additional agent creates orchestration, latency, token, observability, and failure complexity.

Use the fewest agents necessary.

Subagents

Subagents are especially useful for:

Context isolation.

If one investigation requires reading thousands of lines of logs, don’t necessarily dump all of that into the primary conversation.

Let a specialized subagent investigate and return:

• findings,

• evidence,

• recommendation.

Think:

Delegate → isolate → summarize → return

Deterministic vs Agentic

This distinction is everywhere.

Use deterministic software when the rule is deterministic.

Example:

Every production deployment must run the security scanner.

Don’t prompt:

“Please remember to run the security scanner.”

Enforce it.

Model judgment is for ambiguity.

Code is for certainty.

Excellent architecture combines both.

Hooks

Hooks intercept lifecycle events and enforce behavior.

Think:

deterministic control points around agentic behavior.

Good candidates:

• validation

• policy enforcement

• tool-call interception

• logging

• normalization

• security controls

• required checks

A hook is powerful precisely because compliance does not depend on Claude remembering instructions.

DOMAIN 2 — Tool Design & MCP Integration

A tool should be:

focused

predictable

well-described

schema-driven

easy for the model to choose correctly

Bad tool:

doEverything(action, thing, mode, operation, configuration...)

Better tools express clear capabilities.

Tool descriptions matter because Claude uses them to determine when and why a tool should be invoked.

MCP Mental Model

MCP standardizes how AI applications interact with external capabilities and context.

Remember the major concepts:

Tools

Things the model/application can do.

Examples:

• create ticket

• query database

• update record

Resources

Things that provide context/data.

Prompts

Reusable prompt templates/workflows exposed through MCP.

Don’t confuse them.

A useful shortcut:

Tool = action

Resource = information

Prompt = reusable interaction template

MCP Architecture

Think:

Claude / Host

↓

MCP Client

↓

MCP Server

↓

External system

The MCP server provides the controlled boundary to the external capability.

That separation is important for:

• security

• governance

• reuse

• discoverability

• maintainability

Tool Errors

Tools fail.

Production architectures should expect it.

Return structured, actionable errors.

Bad:

Something broke.

Better conceptually:

RATE_LIMITED

with enough structured information for the application or model to determine the appropriate next step.

Distinguish:

Transient failure

Potential retry.

Permanent failure

Retry probably won’t help.

Validation failure

Correct the request.

Authorization failure

Escalate/fix permissions.

Do not endlessly retry every failure.

DOMAIN 3 — Claude Code Configuration & Workflows

Know CLAUDE.md.

This is persistent repository/project guidance for Claude Code.

Put things there such as:

• architecture conventions

• build commands

• test commands

• coding standards

• repository structure

• important constraints

Think:

“What should Claude understand whenever it works in this repository?”

CLAUDE.md is a strong candidate.

CLAUDE.md Is Not a Garbage Dump

Don’t put every piece of documentation into CLAUDE.md.

Large irrelevant instructions consume context and reduce signal.

Keep persistent instructions:

relevant

concise

actionable

stable

Plan Mode

When a change has architectural implications:

Explore before editing.

A strong workflow is:

Explore

↓

Understand

↓

Plan

↓

Implement

↓

Test

↓

Review

A classic exam distractor is essentially:

Immediately modify the obvious file.

Usually weaker than understanding the codebase and dependencies first.

Skills vs Commands vs Hooks

Keep these boundaries clear.

Skill

Reusable knowledge/workflow.

Command

User-invoked workflow entry point.

Hook

Deterministic lifecycle enforcement.

If the exam says:

Developers should be able to invoke a reusable workflow…

Think command/skill.

If it says:

This must happen every time regardless of developer behavior…

Think hook.

CI/CD

Claude can participate in CI/CD, but deterministic infrastructure should remain deterministic.

Think:

Claude assists with:

• analysis

• generation

• review

• diagnosis

CI/CD enforces:

• tests

• policies

• build requirements

• deployment gates

Don’t replace reliable automation with probabilistic prompting.

DOMAIN 4 — Prompt Engineering & Structured Output

Prompt engineering questions often contain unnecessarily complicated answers.

Start with the simplest thing that works.

Good prompts clearly establish:

objective

context

constraints

expected output

evaluation criteria

When output quality matters, tell Claude how success will be judged.

Few-Shot Examples

Use examples when showing Claude the desired behavior is easier than describing it.

Particularly useful for:

• classification

• transformations

• specialized formatting

• unusual business rules

• consistent output patterns

Don’t automatically add dozens of examples.

Examples consume context.

Use enough to establish the pattern.

Structured Output

If another machine consumes Claude’s response:

Prefer structured output.

Define the expected schema.

Then validate it.

Think:

Generate → validate → accept/retry/escalate

Do not assume:

Claude usually produces valid JSON.

“Usually” isn’t a production architecture.

Validation

Validation should occur at the boundary.

If you require:

customer_id

risk_level

recommendation

validate that those fields exist and conform to the expected types/values before downstream processing.

Never confuse:

model confidence

with

system validation.

Multi-Pass Review

For important outputs:

Generate

↓

Review

↓

Refine

can outperform attempting everything in one enormous prompt.

This is particularly useful for:

• code

• architecture

• documents

• complex reasoning

• quality-sensitive output

DOMAIN 5 — Context Management & Reliability

Context is a finite resource.

Treat it architecturally.

Don’t dump everything into the prompt because it might eventually become useful.

The better pattern is:

Retrieve what is relevant when it becomes relevant.

Retrieval vs Giant Context

Huge knowledge source.

Tiny portion required per task.

Use:

retrieval

rather than stuffing the entire corpus into every prompt.

This improves:

• relevance

• cost

• latency

• context utilization

Prompt Caching

Different problem.

Suppose you have a large mostly-static context that really is needed repeatedly.

Then:

Prompt caching may reduce repeated processing cost.

Remember the distinction:

Huge corpus, little needed → retrieval

Large repeated static prefix → caching

Different optimization problems.

Context Pollution

Long-running conversations accumulate irrelevant information.

This can reduce performance.

Strategies include:

• compaction

• fresh sessions

• subagents

• retrieval

• summarization

• external state

Don’t assume “more context” always means “better Claude.”

Relevant context beats maximum context.

State vs Context

This distinction is extremely important.

Context

What Claude currently knows for reasoning.

State

Durable information about the workflow/system.

If an order-processing workflow runs for three days, don’t depend upon the model conversation to remember:

Step four completed Tuesday.

Persist it.

Think:

database

workflow store

checkpoint

event log

Claude interprets state.

Claude should not be your database.

Reliability

Expect failures.

Good systems have:

• timeouts

• bounded retries

• exponential backoff where appropriate

• idempotency

• checkpoints

• observability

• structured errors

• escalation paths

Bad architecture:

Retry forever until it works.

Idempotency

Know this cold.

Suppose Claude requests:

chargeCustomer()

The network times out after the external service processed the payment.

Your application doesn’t know whether it succeeded.

Blind retry?

Customer might get charged twice.

Solution:

Idempotency key.

The external operation can recognize the repeated request as the same logical operation.

This is essential for side-effecting operations.

Saga / Compensation

For long-running workflows across multiple systems:

System A succeeds

↓

System B succeeds

↓

System C fails

You may need compensating actions.

For example:

reserve inventory

↓

charge payment

↓

create shipment FAILS

↓

refund payment

↓

release inventory

That’s the Saga idea.

Not every operation can literally be rolled back.

Sometimes you compensate.

Human-in-the-Loop

Use human approval when:

• consequences are significant,

• ambiguity remains high,

• policy requires approval,

• financial/legal/security impact is substantial,

• confidence is insufficient.

Don’t use human approval for everything.

That defeats automation.

Use it at risk boundaries.

The Claude API: Last-Minute Essentials

Understand the conceptual request:

model

messages

system instructions

max tokens

plus other appropriate configuration.

Claude returns content blocks and metadata describing why generation stopped.

Streaming

Use streaming when you want output incrementally rather than waiting for the entire response.

Benefits include:

• perceived responsiveness

• progressive rendering

• long-response UX

Streaming doesn’t magically make reasoning better.

It changes delivery behavior.

Multimodal Inputs

Claude can reason over supported non-text inputs such as images/documents depending on the API/model capabilities.

Architecturally:

input content can contain multiple content types.

Don’t build an unnecessary external OCR pipeline when the model can directly process the supported content and direct processing meets the requirement.

But preprocessing can still make sense for specialized extraction, compliance, or unsupported formats.

Token Management

Tokens affect:

• context capacity

• latency

• cost

Do not spend tokens without purpose.

Ask:

Does Claude actually need this information to make the next decision?

If not, don’t send it.

The Exam’s Favorite Wrong Answers

Watch for these patterns.

“Put everything in one giant prompt.”

Usually suspicious.

“Give Claude every document.”

Usually suspicious.

“Retry indefinitely.”

Wrong.

“Let Claude remember workflow state.”

Wrong for durable state.

“Use another agent.”

Maybe — but only if specialization/context isolation justifies it.

“Let Claude decide whether mandatory security controls should run.”

Wrong boundary.

“Create one enormous MCP tool.”

Usually poor tool design.

“Skip validation because structured output was requested.”

Wrong.

“Immediately modify the code.”

Often weaker than explore/plan/implement.

“Use the most sophisticated architecture.”

Architecture isn’t a sophistication contest.

Choose the simplest architecture that reliably satisfies the requirement.

The Architect’s Elimination Strategy

When two answers look correct, compare them on:

Reliability

Which survives failures?

Determinism

Which places deterministic requirements in deterministic mechanisms?

Separation of concerns

Which gives Claude reasoning and software execution appropriate responsibilities?

Context efficiency

Which gives Claude relevant information without unnecessary context?

Observability

Which architecture can actually be diagnosed?

Recoverability

What happens after failure?

Security

Where are permissions and dangerous operations controlled?

Simplicity

Which solution introduces the least unnecessary machinery?

This will often expose the better answer.

The “Claude Should…” Test

Whenever an answer says:

“Claude should remember…”

Be suspicious.

“Claude should always make sure…”

Ask whether a hook/code should enforce it.

“Claude should retry until…”

Look for bounded retries.

“Claude should store…”

Ask whether durable state belongs externally.

“Claude should read the entire…”

Ask whether retrieval would be better.

“Claude should directly access…”

Ask whether a controlled tool/MCP boundary is appropriate.

The Entire Exam on One Screen

If you remember nothing else, remember this:

Deterministic enforcement → Hook

Reusable expertise/workflow → Skill

External capability/data → MCP / Tool

Focused investigation → Subagent

Repository guidance → CLAUDE.md

Understand before changing → Plan Mode

Context polluted → Compact / clear / isolate

Durable state → External store

Side effects → Idempotency

Transient failure → Bounded retry + backoff

Distributed long-running transaction → Saga + compensation

High-risk action → Deterministic control / human approval

Claude requests tool → App executes → tool result → Claude continues

Multiple tool calls → correlate using tool_use_id

Machine-consumed output → Structured schema + validation

Huge corpus, little needed → Retrieval

Large repeated static context → Prompt caching

Complex problem → Decompose

Mandatory rule → Don’t rely solely on prompting

Ambiguity → Claude reasoning

Certainty → deterministic software

The Four Words to Remember

If your brain freezes during the exam, remember:

Reason. Act. Validate. Persist.

REASON

Claude.

ACT

Tools / application / MCP.

VALIDATE

Schemas, hooks, tests, policies, human approval.

PERSIST

External state.

That is a surprisingly good mental model for production Claude architecture.

Your Last 24 Hours

Don’t spend the final day attempting to learn another platform.

Review architectural boundaries.

Run a few scenario questions.

For every wrong answer, don’t memorize the answer.

Ask:

What architectural principle did I miss?

That’s the knowledge that transfers to another question.

Tonight, stop studying at a reasonable time.

Tomorrow, skim the one-screen mental model.

Then walk in thinking like an architect.

Not:

“Which Claude feature do they want me to remember?”

Instead ask:

“What problem is this scenario actually trying to solve?”

Then:

“Which component owns that responsibility?”

Then:

“Which answer solves it with the least unnecessary complexity while remaining reliable?”

That’s the game.

Final CCA-F Exam-Day Mantra

Understand before modifying.

Retrieve before stuffing context.

Validate before trusting output.

Persist state outside the model.

Use tools for actions.

Use hooks for guarantees.

Use skills for reusable expertise.

Use subagents for isolation.

Use humans at consequential boundaries.

Use the simplest architecture that works.

And when you’re stuck between two answers:

Pick the one that treats Claude as a reasoning engine inside a well-engineered system — not as the entire system.

That’s the mindset of a Claude Certified Architect.

Anthropic describes the credential as testing real-world implementation tradeoffs across Claude Code, the Claude Agent SDK/API, and MCP, which is why I weighted this toward decision rules rather than memorization.

Official exam/prep page: Claude Certified Architect – Foundations⁠