The Claude Architect Exam-Day Mental Model: 15 Signals That Point to the Right Answer

The Claude Architect Exam-Day Mental Model: 15 Signals That Point to the Right Answer

When you’re staring at two plausible answers on a Claude architecture question, don’t try to memorize another hundred facts.

Instead, identify the architectural signal hidden in the scenario.

Most questions are really asking:

What responsibility belongs to what mechanism?

Once you recognize that responsibility, the answer often becomes surprisingly obvious.

Here is a practical mental model for Claude architects, with examples, traps, and quick ways to recognize what the question is actually testing.

1. Need Deterministic Enforcement? → Hook

The signal

Look for phrases such as:

• “Every time…”

• “Must always…”

• “Automatically…”

• “Developers should not have to remember…”

• “Before/after a tool executes…”

• “Enforce…”

Those are strong signals that the answer may be a hook.

Example

Your organization requires a security scanner to execute every time Claude modifies source code.

Don’t merely tell Claude:

“Remember to run the security scanner.”

Make it deterministic.

Use a hook.

Why?

A prompt asks the model to behave a certain way.

A hook makes something happen as part of the execution lifecycle.

Exam trap

Skill vs. Hook

If the developer or Claude chooses when to invoke reusable functionality, think Skill.

If the organization requires something to happen automatically at a lifecycle point, think Hook.

Mental shortcut:

Must happen → Hook

Useful capability → Skill

2. Reusable Expertise or Workflow? → Skill

Skills package repeatable knowledge and procedures that Claude can use when appropriate.

Example

Your organization repeatedly creates REST APIs using the same:

• folder structure,

• logging conventions,

• error handling,

• testing standards,

• OpenAPI requirements,

• security rules.

That is a great candidate for a Skill.

Instead of rewriting those instructions into every feature request, package the expertise once and reuse it.

Exam signal

If the question says:

“We want Claude to reuse this process across many tasks…”

Think:

Skill.

3. External System or Data? → MCP / Tool

Claude should not magically know what is happening inside Jira, Salesforce, a database, GitHub, or an internal enterprise system.

It needs a capability to interact with it.

That usually means:

MCP or a tool.

Example

Claude needs the current acceptance criteria from Jira.

The architecture should look something like:

Claude → Jira tool/MCP → Jira → result → Claude

Good tool design

Prefer narrow operations such as:

get_customer(customer_id)

over something extremely broad such as:

execute_any_sql(sql)

The narrow tool provides:

• bounded authority,

• easier validation,

• clearer schemas,

• better security,

• more predictable behavior.

Exam shortcut

Claude needs something outside Claude → MCP/tool.

4. Focused Investigation or Context Isolation? → Subagent

Subagents are especially useful when a task requires substantial investigation that would otherwise pollute the main context.

Example

Claude is implementing a payment feature.

Before implementation, you want another agent to investigate:

• authentication,

• payment APIs,

• existing test patterns,

• database conventions.

Instead of dumping all of that exploration into the primary context, focused subagents can investigate specific areas and return concise findings.

Architecture

Coordinator

↓ delegates

Authentication subagent

Payments subagent

Testing subagent

↓ return findings

Coordinator synthesizes

Exam signal

Look for:

• isolated context,

• parallel research,

• specialized investigation,

• delegation,

• preventing context pollution.

Think:

Subagent.

5. Repository-Wide Guidance? →

CLAUDE.md

CLAUDE.md is where persistent project guidance belongs.

Examples include:

• architecture conventions,

• coding standards,

• build commands,

• test commands,

• repository structure,

• files Claude should avoid,

• team development practices.

What does NOT belong there?

Don’t treat CLAUDE.md as:

• a database,

• workflow state,

• conversation history,

• a secrets vault,

• a replacement for MCP.

Exam shortcut

How should Claude work in this repository? → CLAUDE.md

6. Understand Before Modifying? → Plan Mode

A common enterprise mistake is allowing an agent to start changing code before it understands the system.

For complex work:

Explore → Plan → Implement → Validate

Example

A feature touches:

• authentication,

• three APIs,

• a database migration,

• Kafka,

• integration tests.

The best first action probably isn’t:

Start coding.

It’s:

Understand the repository and develop the implementation plan.

That’s exactly the kind of situation where Plan Mode shines.

Exam signal

If the question emphasizes:

• complex change,

• unfamiliar repository,

• multiple systems,

• understand first,

• no modifications yet,

think:

Plan Mode.

7. Context Getting Polluted? →

/compact

or

/clear

Long sessions accumulate baggage.

Old logs.

Rejected designs.

Superseded requirements.

Debugging output.

Previous plans.

Eventually, irrelevant context can interfere with the current task.

Two important tools:

/compact

Compress the useful context and continue.

/clear

Start fresh when the previous context is no longer useful.

Mental shortcut

Still need the history? → /compact

History is now baggage? → /clear

And don’t solve context pollution by stuffing even more information into CLAUDE.md.

8. Durable Workflow State? → External Store, Not Claude

This one is fundamental to reliable agent architecture.

Claude reasons.

Your system owns durable state.

Example

Imagine a workflow:

Order → Salesforce → Billing → Provisioning → Notification

After provisioning, the process crashes.

How does the system know what already happened?

Not because Claude “remembers.”

The application should persist something like:

Order: 93842

Salesforce: COMPLETE

Billing: COMPLETE

Provisioning: COMPLETE

Notification: PENDING

Now execution can safely resume.

Exam shortcut

Need to survive failure/restart? → Persist state externally.

Never make model memory your transaction database.

9. Side Effects and Retries? → Idempotency + Bounded Retry/Backoff

Suppose Claude requests:

Create customer account.

The external API processes the request successfully — but the network connection dies before your application receives the response.

Did the account get created?

You don’t know.

Blindly retrying could create another customer.

Better design

Use:

• idempotency keys,

• bounded retries,

• exponential backoff,

• verification where appropriate.

The same logical request can then be retried safely.

Exam clue

Whenever you see:

• timeout,

• retry,

• duplicate,

• uncertain result,

• external side effect,

start thinking:

Idempotency.

10. Long-Running Multi-Step Transaction? → Checkpoint / Saga / Compensation

Distributed workflows rarely behave like one giant database transaction.

Imagine:

Salesforce → Billing → Provisioning → ServiceNow

Salesforce succeeds.

Billing succeeds.

Provisioning fails.

What now?

The system needs to know:

1. What succeeded?

2. What failed?

3. What can safely be retried?

4. What must be compensated?

5. Where should processing resume?

That’s the territory of:

Saga + checkpoints + compensation + durable state.

Exam shortcut

Multi-system workflow + partial failure → Think Saga.

11. High-Risk Action? → Deterministic Controls + Human Approval

Not every agent action deserves the same level of autonomy.

Reading a customer record isn’t the same as:

Refund $25,000.

High-impact actions require stronger controls.

Good architecture

Claude can:

Analyze → Recommend → Prepare

Then deterministic policy decides:

Execute automatically

or

Require approval

Exam trap

“Tell Claude to be careful.”

That’s not an authorization architecture.

Mental shortcut

Risk determines autonomy.

12. Claude Requests a Tool? → Application Executes It

One of the most important API concepts:

Claude does not magically execute your application tools.

The loop is:

User → Claude

Claude returns:

tool_use

Your application executes the operation.

Then:

Application → tool_result → Claude

Claude continues reasoning.

Remember this chain

Claude requests → App executes → Result returns → Claude continues.

If an exam answer implies Claude itself executed your custom application function simply because it emitted tool_use, be suspicious.

13. Multiple Tool Calls? → Match Results to

tool_use_id

Claude may request multiple tools during an interaction.

For example:

Claude

→ get_customer

→ get_orders

Your application executes both.

But their results must remain associated with the correct requests.

That’s what the corresponding tool_use_id enables.

Exam trap

Don’t combine unrelated tool outputs into one anonymous result and hope Claude figures it out.

Think:

Request identity must survive the round trip.

14. Machine-Consumed Response? → Structured Schema + Validation

If a human is reading Claude’s answer, flexible prose may be fine.

If another application is consuming the answer, structure matters.

Example

A downstream system expects:

{

  "approved": true,

  "riskScore": 12,

  "reason": "Low risk"

}

Don’t rely solely on:

“Please respond with valid JSON.”

Use a defined structured output/schema where appropriate and validate the returned data before downstream execution.

Exam shortcut

Human consumes it → prose may work.

Machine consumes it → schema + validation.

15. Huge Mostly-Static API Context? → Prompt Caching

Imagine your application repeatedly sends:

• 20,000 tokens of instructions,

• API documentation,

• examples,

• policies,

followed by a relatively small changing request.

Repeatedly processing the same stable material can waste time and money.

That’s where prompt caching becomes important.

Think:

Stable prefix + changing request

Exam signal

If the question emphasizes:

• repeated large instructions,

• mostly unchanged context,

• latency,

• repeated processing cost,

think:

Prompt caching.

16. Huge Knowledge Source, Tiny Relevant Portion? → Retrieval

This is related to caching, but it’s a different problem.

Suppose your company has a massive internal API manual.

Most questions require only three paragraphs from it.

Should every request include the entire manual?

No.

Retrieve what is relevant when it is relevant.

Better architecture

Question

↓

Retrieve relevant material

↓

Add small relevant context

↓

Claude reasons

Mental shortcut

Same large information needed repeatedly → consider caching.

Huge information source but only a little is relevant → retrieval.

This distinction can eliminate several attractive-but-wrong answers.

The Architecture Behind the Exam

These aren’t merely certification facts.

Together, they describe a clean enterprise agent architecture:

Intent

↓

Claude reasons and orchestrates

↓

Skills provide reusable expertise

↓

Subagents provide focused investigation

↓

MCP/tools connect external capabilities

↓

Hooks enforce deterministic lifecycle rules

↓

External state/checkpoints provide durability

↓

Schemas validate machine interfaces

↓

Tests and CI verify implementation

↓

Human approval protects high-risk boundaries

That separation of concerns is the important idea.

Claude shouldn’t be your database.

MCP shouldn’t become your workflow engine.

CLAUDE.md shouldn’t become your secrets vault.

Prompts shouldn’t replace deterministic security controls.

And agents shouldn’t be trusted to “remember” the state of distributed transactions.

Each component has a job.

The 60-Second Exam Cram

When you’re down to two answers, ask:

Is this about enforcement?

→ Hook

Reusable expertise?

→ Skill

External capability/data?

→ MCP/tool

Isolated investigation?

→ Subagent

Repository guidance?

→ CLAUDE.md

Understand before changing?

→ Plan Mode

Too much stale context?

→ /compact or /clear

State must survive failure?

→ External persistence

Retrying side effects?

→ Idempotency + bounded retries/backoff

Distributed partial failure?

→ Saga/checkpoint/compensation

High-risk action?

→ Deterministic controls + human approval

Claude asks for a tool?

→ Application executes it and returns tool_result

Several tool requests?

→ Match each result to its tool_use_id

Machine consuming Claude’s answer?

→ Structured schema + validation

Same giant context repeatedly?

→ Prompt caching

Giant knowledge base, tiny relevant portion?

→ Retrieval

Final Tip: Don’t Memorize Products — Recognize Responsibilities

The strongest architecture questions rarely depend on memorizing a command.

They test whether you understand separation of concerns.

Ask yourself:

Who should own this responsibility?

Should Claude reason about it?

Should a tool execute it?

Should a hook enforce it?

Should a skill teach it?

Should a subagent investigate it?

Should an external system persist it?

Should a human authorize it?

Once you identify the owner, the answer frequently reveals itself.

That’s the mental model worth carrying into the exam — and into production architecture after the exam.