01-projects / phdata

anthropic certification study guide

Tue Apr 07 2026 20:00:00 GMT-0400 (Eastern Daylight Time) ·study-guide ·status: in-progress
anthropiccertificationclaudestudy

Anthropic/Claude Certification Study Guide

A structured study plan for the Claude Certified Architect exam domains. Written for someone already running Claude Code 24/7 with MCP servers, skills, and an always-on agent — the goal is to formalize existing knowledge and close the gaps.

Source material: 06-reference/2026-03-15-claude-architect-course (hooeem’s exam breakdown).

Current Model Specs (as of April 2026)

ModelInputOutputContextOutput WindowExtended ThinkingAdaptive Thinking
Claude Opus 4.6$5/MTok$25/MTok1M tokens128K tokensYesYes
Claude Sonnet 4.6$3/MTok$15/MTok1M tokens64K tokensYesYes
Claude Haiku 4.5$1/MTok$5/MTok200K tokens64K tokensYesNo

Decision framework for model selection:

Domain 1: Agentic Architecture & Orchestration (27%)

Exam weight: highest. Study first.

What RDCO Already Has

What Needs Studying

Stop reason handling. The exam tests whether you handle stop_reason correctly:

Never use natural language parsing or iteration caps as the primary termination mechanism.

Subagent context isolation. Subagents spawned via the Task tool or Agent SDK do NOT inherit coordinator memory. Every fact the subagent needs must be passed explicitly in its prompt. This is counterintuitive if you think of subagents as threads — treat them as independent stateless processes instead.

Programmatic hook enforcement. For financial or security-critical paths, prompt instructions are not enough. Use:

Fork session pattern. fork_session in the Agent SDK creates a copy of the current session state for parallel exploration without polluting the main context. Understand when this is appropriate vs. spawning a fresh subagent.

Key Resources

Practice Exercises

  1. Stop reason audit. Review the channels agent restart script — does it handle max_tokens explicitly, or just loop? Add explicit handling for each stop_reason.
  2. Subagent isolation test. Build a two-agent coordinator/subagent where the coordinator passes a data object, the subagent transforms it, and the coordinator uses the result. Verify the subagent has no implicit access to coordinator history.
  3. Hook implementation. Add a PostToolUse hook to a skill that normalizes output formats (e.g., coerces all date strings to ISO 8601).
  4. Policy gate. Implement a PreToolCall hook that blocks a write tool from executing unless a read tool has already been called in the same session.

Domain 2: Claude Code Configuration & Workflows (23% per study guide; 20% per exam)

What RDCO Already Has

What Needs Studying

Path-specific rules via .claude/rules/. This is the exam’s “sleeper concept.” A .claude/rules/ directory with YAML frontmatter can apply glob patterns like **/*.test.tsx — rules apply anywhere in the codebase matching the pattern. Directory-level CLAUDE.md cannot do this because it’s geographically scoped, not pattern-scoped.

The team-sharing trap. User-level CLAUDE.md is never checked into the repo. If critical instructions live there, other developers and CI environments don’t see them. Move shared conventions to project-level CLAUDE.md.

Plan mode selection criteria. Know when to use each:

Independent review sessions. Running a second Claude Code instance as a reviewer (rather than asking the same session to review its own output) catches significantly more issues. The exam tests awareness of this.

Slash commands vs. skills. Know the difference: slash commands are session-scoped shortcuts, skills are durable files loaded on demand.

Key Resources

Practice Exercises

  1. Rules directory setup. Create .claude/rules/ in a project with two glob-pattern rules. Verify they apply correctly to matching files and not to non-matching files.
  2. Configuration audit. Identify any instructions currently in ~/.claude/CLAUDE.md that should be in a project-level file for team shareability.
  3. Plan vs. execute drill. Pick a two-file refactor. Do it in plan mode first, noting the difference in output format. Then do a one-liner bug fix in direct execution. Document the decision criteria you used.
  4. Independent review. After completing a skill, open a fresh Claude Code session and have it review the skill without the context of how it was built. Compare findings to self-review.

Domain 3: API & SDK Integration (20%)

What RDCO Already Has

What Needs Studying

Message Batches API. Key properties: 50% cost savings, up to 24-hour processing, no latency SLA, no multi-turn tool calling. Use for overnight batch jobs (bulk vault embeddings, nightly report generation). Do not use for blocking pre-merge checks or interactive flows.

tool_choice options. Must know all three modes:

Streaming vs. batch tradeoffs. Know when streaming is necessary (user-facing, interactive) and when batch is appropriate (background processing, cost optimization).

Extended thinking integration. Extended thinking (Opus 4.6, Sonnet 4.6) exposes reasoning before the final answer. Useful for complex decisions but costs more tokens — budget thinking tokens separately.

Adaptive thinking. Available on Opus and Sonnet but not Haiku. Automatically scales thinking depth based on task complexity. Use when you want the model to self-regulate reasoning depth.

Key Resources

Practice Exercises

  1. Batch API test. Run a 10-item batch through the Message Batches API. Handle failures by custom_id. Compare cost and latency to synchronous calls.
  2. tool_choice drill. Build a minimal agent with three tools. Test all three tool_choice modes. Observe model behavior in each.
  3. Extended thinking experiment. Call Opus 4.6 with extended thinking on a complex reasoning task. Observe token usage in the thinking block vs. the response. Build intuition for when the cost is worth it.
  4. Streaming pipeline. Build a simple streaming response handler that yields partial output to the terminal as it arrives. Practice handling message_start, content_block_delta, and message_stop events.

Domain 4: MCP Implementation (18%)

What RDCO Already Has

What Needs Studying

Tool description quality. This is the most undertested area relative to experience. Tool descriptions are the primary mechanism Claude uses for tool selection — vague or overlapping descriptions cause misrouting even with correct implementations.

Exercise: write two tools with intentionally overlapping descriptions. Observe misrouting. Then fix the descriptions. The experience is more instructive than any reading.

Per-subagent scoping. The exam tests the principle that each subagent should have 4–5 tools scoped to its role, not a shared pool of 18+. More tools = degraded selection reliability.

MCP transport types. Understand stdio (subprocess, same machine) vs. HTTP+SSE (remote, networked) and when each is appropriate. Most local development uses stdio; production agents serving multiple clients use HTTP.

Error responses from MCP tools. Structured error responses (failure type, context, alternatives) are better than throwing exceptions. The model can incorporate structured errors into its reasoning; unstructured exceptions cannot be reasoned about.

Key Resources

Practice Exercises

  1. Description quality audit. Review tool descriptions on all running MCP servers. Identify any that are vague or could overlap. Rewrite them with precise, non-overlapping language.
  2. Misrouting experiment. Create two tools with identical descriptions. Run 10 test prompts. Log which tool gets selected and when. Then fix descriptions and repeat.
  3. Custom MCP server. Build one custom MCP server from scratch (e.g., a tool that wraps a local CLI or API we don’t have a community server for). Implement structured error responses.
  4. Transport comparison. Run the same tool as both stdio and HTTP. Note the configuration differences and latency characteristics.

Domain 5: Production Deployment (12%)

What RDCO Already Has

What Needs Studying

System prompt caching. Static content above the cache boundary (base instructions, tool definitions, stable CLAUDE.md) gets cached by Anthropic infrastructure. Dynamic content below flows fresh each request. This is why SOUL.md stability matters — churn in the instruction layer has real cost. Rohit estimated ~80% cache hit rates in the Claude Code architecture — 06-reference/2026-04-07-claude-code-architecture-teardown.

Escalation design. Three valid triggers: user requests human, policy gap, cannot progress. The exam specifically tests that sentiment analysis and self-reported confidence scores are NOT reliable escalation triggers.

Context management at scale. Persistent “case facts” blocks for transactional data (amounts, dates, IDs) that are never summarized. Key summaries at the beginning of context (not the middle — “lost in the middle” effect). Compaction strategy at 60% context utilization.

Cost modeling. For production billing, understand:

Non-interactive CI/CD. The -p flag for headless Claude Code runs. Structured output for machine-readable results. Managing permissions in CI contexts (no interactive prompts).

Key Resources

Practice Exercises

  1. Cache boundary audit. Identify what content in our current system prompts and CLAUDE.md files is static vs. dynamic. Restructure to maximize static content above the cache boundary.
  2. Escalation logic review. Review the channels agent’s behavior when it hits policy gaps. Does it have explicit escalation triggers? Add structured escalation with the three valid trigger types.
  3. Cost model. Build a simple spreadsheet estimating monthly token costs for the channels agent at current usage. Factor in caching hit rates and model tier selection.
  4. CI/CD pipeline. Set up a Claude Code -p run in a GitHub Actions workflow (or local equivalent) that produces structured JSON output. Handle permission prompts without interactive input.

Study Schedule

Week 1 — Foundation

Week 2 — Configuration & Output

Week 3 — API & Production

Week 4 — Synthesis

Quick Reference: Anti-patterns to Reject on Sight

DomainAnti-patternCorrect approach
AgenticNatural language parsing for loop terminationCheck stop_reason explicitly
AgenticIteration cap as primary stopping mechanismTool results or explicit completion signals
AgenticChecking assistant text to infer completionStructured stop_reason + tool result patterns
AgenticAssuming subagents share memoryPass all context explicitly in the prompt
Tool DesignVague/overlapping tool descriptionsPrecise, non-overlapping descriptions
Tool Design18 tools per agent4–5 tools per scoped subagent
Prompt Eng”Be conservative” for precisionDefine exactly which cases to include vs. skip
ContextProgressive summarization of transactional dataPersistent verbatim “case facts” block
ContextSentinel analysis for escalationExplicit trigger conditions: request, policy gap, no progress
ContextSilently suppressing errorsStructured error context with failure type + alternatives