DEV Community: Josh

CCDV-F vs CCAR-F: 53 items, 8 domains, same $125 fee

Josh — Sun, 30 Aug 2026 20:01:17 +0000

Anthropic's certification programme publishes more than one Foundations exam, and two of them are aimed at people who build things. CCDV-F is the Claude Certified Developer – Foundations exam. CCAR-F is the Claude Certified Architect – Foundations exam, the one you will also see written informally as CCA-F — we covered why that exam answers to two different codes separately. The third, CCAO-F, is the Associate exam, written for people who use Claude rather than build with it; we set the Associate exam against the Architect one in its own article.

Both cost $125. Both run 120 minutes. Both are pitched at technical practitioners rather than at general users. So the fee will not tell you which one you are preparing for, and neither will the clock. What separates them is the shape of the exam and the syllabus behind it — and here the two published guides diverge sharply. This article sets them side by side using only what those documents state.

The short answer

**
The Developer exam is weighted toward getting Claude into an application: the API, the SDKs, the surrounding software engineering, and the design of the app itself. The Architect exam is weighted toward agentic systems and the tooling around them: orchestration, subagents, MCP interfaces, and Claude Code configuration. Both guides describe candidates who write code. They disagree about what that code is mostly doing.

Where the two exams are identical

**
Set the two at-a-glance tables next to each other — Section 5 of the Developer guide, Section 3 of the Architect guide — and almost every row matches, several of them word for word.

CCDV-F vs CCAR-F

Items: 53 vs 60
Domains: 8 vs 5
Fee: $125 both
Pass: 720 of 100–1,000 both
Time: 120 minutes both
Structure: CCAR-F specifies 4 scenarios from a bank of 6; the CCDV-F guide has no such row

The item-format row is identical in both guides, down to the punctuation: “Multiple-choice and multiple-response items; each item states how many responses to select”. Neither guide says what proportion of items takes each form, for either exam. That is worth holding onto, because it is an easy thing to assume — we wrote about what multiple-response actually means for how you answer when the Architect guide's wording raised the same question.

The scaled score of 720 on a 100–1,000 range is common to both, and both describe a criterion-referenced assessment measured against a fixed standard rather than against other candidates, with the per-domain percentages on your score report explicitly not used to decide pass or fail. The $125 fee is the same figure in both, which is why it cannot be the deciding factor here.

The policies are not merely similar — the retake sections are word-for-word identical. Both set the same waiting periods after a failed attempt: fourteen days after the first, thirty after the second, ninety after the third, four attempts maximum in a rolling twelve-month period, and the fee payable on each one. Both note the limits apply per exam, so failing one does not stop you registering for the other. Registration for both runs through the Anthropic Partner Academy and Pearson VUE, and both credentials last twelve months and renew through a free, non-proctored assessment.

Where they genuinely differ

**
The blueprint, and how it is published
This is the substantive difference, and it starts before you read a single domain name.** The two guides do not publish their blueprints at the same resolution.**

The Architect guide (Section 4) gives five domains in whole percentage points. Its Section 6 lists thirty task statements underneath them, each with “Knowledge of” and “Skills in” bullets, but no weight of its own. You know a domain is worth 20%; you do not know how that 20% is split.

The Developer guide (Section 6) gives eight domains to one decimal place and weights every skill inside them as well — twenty-five skills, each with its own percentage, summing exactly to their domain weights. A candidate can budget study time against it directly.

The eight Developer domains, and roughly how many of the 53 items each is worth:

Applications and Integration — 33.1% · ~17.5 items
Model Selection and Optimization — 16.8% · ~8.9
Agents and Workflows — 14.7% · ~7.8
Prompt and Context Engineering — 11.0% · ~5.8
Tools and MCPs — 10.6% · ~5.6
Security and Safety — 8.1% · ~4.3
Claude Code — 3.1% · ~1.6
Eval, Testing, and Debugging — 2.6% · ~1.4

And the five Architect domains, for comparison:

Agentic Architecture & Orchestration — 27%
Claude Code Configuration & Workflows — 20%
Prompt Engineering & Structured Output — 20%
Tool Design & MCP Integration — 18%
Context Management & Reliability — 15%

We break down the five Architect domains and what each one weighs in a separate post.

One domain is a third of the Developer exam

**
Applications and Integration is 33.1% on its own — roughly 17.5 of the 53 items. Nothing on the Architect blueprint is that concentrated; its heaviest domain, Agentic Architecture & Orchestration, is 27%, or about 16 of its 60 questions.

The Developer guide breaks that domain into six weighted skills: Claude Application Design (8.6%), Software Engineering Foundations (7.4%), Claude API Mechanics (6.8%), Configuration Management (4.1%), Understanding Requirements (3.4%) and Systems Life Cycle (2.8%). Note what is in there — Software Engineering Foundations covers REST APIs, JSON, asynchronous programming, version control and refactoring. That is general engineering practice, not Claude-specific knowledge, and on this exam it alone outweighs two entire content domains.

Two domains round to almost nothing

**
Claude Code is 3.1% of the Developer exam and Eval, Testing, and Debugging is 2.6% — about 1.6 and 1.4 items. Each is a single undivided skill, and together they come to 5.7%, or roughly three questions. Four individual skills each outweigh the pair: Claude Application Design at 8.6%, Software Engineering Foundations at 7.4%, Claude API Mechanics at 6.8% and Technical Fundamentals at 6.1%.

The contrast with the Architect exam is sharpest on Claude Code: 3.1% of the Developer blueprint against 20% of the Architect one, where it is a domain in its own right covering CLAUDE.md hierarchy, custom slash commands, settings and plan mode. If Claude Code is the reason you are looking at certification at all, that number is the one to read carefully.

The exam's structure — and what the Developer guide does not say
The Architect guide specifies its structure twice: in the Section 3 table as four scenarios drawn from a bank of six, and again in Section 5, which gives all six scenarios a section of their own and names the primary domains each one draws on.

**The Developer guide describes no scenario structure at all. **Its at-a-glance table has no exam-structure row, and it has no section corresponding to the Architect guide's Section 5. That is a statement about the two documents: one specifies a structure and the other does not. It does not follow that the Developer exam is, or is not, organised into scenarios — the guide simply does not say, and guessing from a silence is how people end up preparing for an exam that does not exist.

The same asymmetry shows up elsewhere. The Architect guide runs to eighteen sections and carries two things the Developer guide has no equivalent of: preparation exercises (Section 8) and an appendix listing technologies and concepts that might appear (Section 17). It publishes twelve sample questions in Section 9. The Developer guide runs to sixteen sections and publishes three samples in Section 8, noting that they illustrate item style rather than coming from the operational pool.

If you cross-reference the two documents, be careful with section numbers: they do not line up, and the offset is not constant. Exam details are Section 5 in the Developer guide against Section 3 in the Architect one, and the blueprint Section 6 against Section 4 — but registration is Section 10 against Section 11, and the confidentiality agreement Section 13 against Section 14.

Who each exam is written for

**
The Developer guide's Section 3 is specific. It names AI and machine learning engineers, technical leads and senior software engineers, and expects one to five years of software engineering experience, at least six months hands-on with Claude, proficiency in Python and/or TypeScript, and fluency with REST APIs and command-line tools. It then says plainly who the exam is not for: non-technical or casual users, anyone without hands-on software development experience, and roles limited to prompt writing or other isolated tasks.

The Architect guide's Section 2 describes a solution architect who designs and implements production applications with Claude, with hands-on experience across the Agent SDK, Claude Code, MCP interfaces and context management, and typically six or more months of practical work against those technologies. Both profiles assume a working engineer; the Developer one is framed around shipping an application, the Architect one around designing the system's agentic structure. Our longer piece on which roles the Architect certification actually fits works through that side in more detail.

Neither guide requires anything. The Developer guide's Section 4 states there are no mandatory prerequisites or courses, and that the credential is awarded on exam performance alone.

How to choose

**
**What are you mostly building? **If it is an application that calls Claude — API integration, streaming, error handling, model and cost decisions — the Developer blueprint puts half its weight there. If it is an agentic system with subagents, orchestration and MCP tooling, the Architect blueprint is built around that.

How much does Claude Code matter to you? 20% of one exam, 3.1% of the other. This is the single largest divergence between the two blueprints.

**Do you want the syllabus at skill resolution? **The Developer guide gives you twenty-five weighted skills; the Architect guide gives thirty task statements with no weights attached. If you plan study time against percentages, that is practical rather than cosmetic.

Are you comparing on price? You cannot. Both are $125, with the same retake costs and waiting periods. The decision has to be made on content.
Nothing in either guide ranks one credential above the other, and neither is described as a prerequisite for the other. They are different scopes of work with different blueprints, and nothing stops you holding both.

Common MCP Server Design Mistakes and How to Avoid Them

Josh — Thu, 27 Aug 2026 08:35:01 +0000

Why MCP Server Design Matters for CCA Certification

**
The Model Context Protocol (MCP) represents a fundamental shift in how AI systems interact with external tools and data sources. For Claude Certified Architect candidates, understanding MCP server design isn't just about passing an exam—it's about building production-grade integrations that actually work. Yet even experienced developers consistently make the same design mistakes when implementing MCP servers, leading to brittle integrations, security vulnerabilities, and failed deployments.

After reviewing hundreds of MCP implementations and working with CCA exam candidates, we've identified seven critical design mistakes that appear repeatedly. These errors cause the majority of real-world integration failures. More importantly, they're entirely preventable once you understand the underlying patterns.

This guide examines each mistake in detail, explains why it matters for both certification and production use, and provides concrete patterns you can implement immediately. Whether you're preparing for the CCA Foundations exam or building actual MCP servers, these insights will save you significant debugging time and help you design more robust integrations.

Mistake 1: Treating MCP Like a Traditional REST API

**
The most pervasive mistake developers make is approaching MCP server design with a REST API mindset. This fundamental misunderstanding leads to poorly structured servers that fight against the protocol's design rather than leveraging it.

MCP operates on a client-server architecture where the client (typically Claude Desktop or another AI application) initiates all connections. Unlike REST APIs that respond to individual HTTP requests, MCP servers maintain stateful connections using JSON-RPC 2.0 over stdio transport. This connection model fundamentally changes how you should design your server.

What goes wrong: Developers create MCP servers with dozens of fine-grained tools that mirror REST endpoint patterns. For example, they'll implement separate tools for "getUserById", "getUserByEmail", "getUserByUsername", "listUsers", and "searchUsers". This approach creates cognitive overload for the AI model, increases token usage unnecessarily, and makes tool selection less reliable.

The correct approach: Design tools around user intent and capabilities rather than database operations. Instead of five separate user lookup tools, create a single "manage_users" tool with parameters that handle different query patterns. The tool description should clearly articulate what the tool accomplishes, not how it works internally. Your implementation can route to different backend services based on provided parameters, but the AI should see a coherent capability.

For the CCA exam, expect questions that test your understanding of appropriate tool granularity. The exam often presents scenarios where you must choose between multiple tool designs, and the correct answer consistently favours capability-oriented design over operation-oriented design. Remember that each tool you expose carries a token cost in the system prompt—good design minimises this overhead whilst maximising capability.

Mistake 2: Neglecting Resource Discovery Patterns

**
MCP's resource system provides a powerful mechanism for exposing readable content to AI applications, yet many implementations completely ignore this capability or use it incorrectly. Resources represent documents, data, or content that an AI might need to reference, distinct from tools which represent actions.

What goes wrong: Developers either skip implementing resources entirely, relying solely on tools to fetch data, or they implement resources without proper URI schemes and metadata. A common anti-pattern is creating a tool called "readDocument" instead of properly exposing documents as resources. This forces the AI to explicitly call a tool every time it needs content, increasing latency and complicating the interaction model.

Another frequent mistake is implementing static resource lists without supporting resource templates or subscriptions. When you have potentially thousands of accessible documents, files, or data objects, hardcoding them all in the resource list becomes unmanageable and defeats the purpose.

The correct approach: Implement resources for any content that the AI might need to read or reference. Use clear, hierarchical URI schemes that make sense to both humans and AI models. For example, "file:///project/docs/api-reference.md" is far superior to "resource://doc123". Support resource templates when dealing with large or dynamic content sets—this allows the AI to construct resource URIs based on patterns you define.

Include comprehensive metadata with your resources. The MIME type helps the AI understand how to interpret the content. The description should explain what the resource contains and when it might be relevant. If your resource content changes, implement the resources/updated notification so clients can refresh their understanding.

CCA exam questions frequently test whether candidates understand the resource versus tool distinction. You'll encounter scenarios asking you to design an MCP server for specific use cases—choosing between implementing something as a resource or a tool is a critical decision point that appears repeatedly.

Mistake 3: Poor Error Handling and Message Validation

**
MCP servers operate in an environment where failures are inevitable—network issues, rate limits, invalid parameters, missing permissions, and downstream service failures all occur regularly. Yet many implementations handle errors poorly or inconsistently, leading to confusing failures that are difficult to debug.

What goes wrong: Developers return generic error messages, fail to validate input parameters properly, or worse, let exceptions bubble up uncaught. Common patterns include returning "Error: something went wrong" without context, not validating required parameters before attempting operations, and mixing error reporting mechanisms (sometimes throwing exceptions, sometimes returning error objects).

Another critical mistake is not implementing proper timeout handling. When your MCP tool calls an external API that hangs, your entire server can become unresponsive, breaking the client connection and requiring a restart.

The correct approach: Implement comprehensive input validation for every tool and resource request. Check that required parameters are present, that types are correct, and that values fall within acceptable ranges before attempting any operations. Return JSON-RPC error objects with meaningful error codes and descriptive messages that help both developers and AI models understand what went wrong.

Structure your error messages to be actionable. Instead of "Invalid parameter", return "The 'start_date' parameter must be in ISO 8601 format (YYYY-MM-DD), but received '2024-13-45'". The AI model can use these detailed errors to correct its approach and retry successfully.

Implement timeouts for all external operations. If you're calling a database, API, or file system, wrap these operations in timeout logic. When timeouts occur, return clear errors indicating that the operation exceeded its time limit. Set reasonable timeout values based on your service's performance characteristics—typically 30-60 seconds for tool operations.

For CCA certification, you need to understand the JSON-RPC 2.0 error object structure and the standard error codes (-32700 to -32603). Exam questions often present error scenarios and ask you to identify the appropriate error response structure or troubleshoot why an error handling implementation is failing.

Mistake 4: Inadequate Security and Permission Models

**
Security considerations in MCP servers extend beyond basic authentication. Because MCP servers often act as bridges between AI systems and sensitive data or powerful capabilities, the security model must be thoughtfully designed from the ground up.

What goes wrong: The most dangerous mistake is implementing MCP tools that perform privileged operations without proper authorisation checks. Developers sometimes assume that because the MCP server is running locally or on a trusted network, security controls aren't necessary. This assumption creates severe vulnerabilities, especially when the AI model might be influenced by untrusted input.

Another common error is hardcoding credentials or API keys directly in the server code, exposing them in version control or making them difficult to rotate. Some implementations also fail to implement rate limiting or resource quotas, allowing a misbehaving or compromised client to exhaust system resources.

The correct approach: Implement proper authentication and authorisation for your MCP server. Even if your server runs locally, it should validate that requests come from authorised clients. Use environment variables or secure configuration management for credentials and secrets—never hardcode them.

Design your tools with the principle of least privilege. Each tool should only have access to the minimum resources and permissions necessary to accomplish its purpose. If a tool only needs read access to a database, don't grant it write permissions "just in case". Implement role-based access controls when different clients might have different permission levels.

Add rate limiting to prevent abuse. Even well-intentioned AI interactions can generate rapid sequences of tool calls. Implement per-client rate limits that prevent resource exhaustion whilst allowing normal operations. Return clear error messages when rate limits are exceeded, including information about when the client can retry.

Validate and sanitise all input parameters, especially those that will be used in database queries, file system operations, or command executions. Implement allowlists for file paths, database tables, or other resources that tools can access. Never construct SQL queries through string concatenation with user-provided values—use parameterised queries exclusively.

The CCA exam includes scenarios testing your understanding of security boundaries in MCP implementations. You'll need to identify security vulnerabilities in provided code samples and recommend appropriate mitigations. Understanding prompt injection risks—where malicious content in retrieved documents might influence the AI's behaviour—is particularly important.

Mistake 5: Ignoring Prompts and Sampling Capabilities

**
MCP servers can expose prompts—pre-configured message templates that clients can use—and implement sampling support, allowing the server to request AI completions. Many developers completely overlook these capabilities, missing opportunities to create more sophisticated integrations.

What goes wrong: Most MCP server implementations focus exclusively on tools and resources, treating prompts and sampling as advanced features they'll "add later". This approach misses the power of prompts for standardising common interaction patterns and sampling for implementing agentic behaviours within the server itself.

When developers do implement prompts, they often create overly specific ones that don't accept dynamic arguments, making them less reusable. Or they create prompts that are too vague, failing to provide the structure and context that makes them useful.

The correct approach: Identify common interaction patterns in your domain and create prompts that encapsulate them. For example, if your MCP server provides access to a project management system, you might create prompts like "analyse_project_status" or "generate_sprint_report" that structure how the AI should approach these tasks using your tools and resources.

Design prompts to accept arguments that parameterise the interaction. A prompt for analysing project status should accept the project identifier as an argument, making it reusable across different projects. Include clear descriptions of what each prompt does and what arguments it expects.

Consider implementing sampling support if your server needs to make autonomous decisions or generate content. Sampling allows your MCP server to request AI completions, enabling sophisticated behaviours like automated content generation, intelligent routing, or adaptive responses. This is particularly powerful for servers that act as agents rather than simple tool providers.

CCA exam content increasingly covers the full MCP specification, including prompts and sampling. While these features receive less emphasis than tools and resources, expect at least one question testing your understanding of when and how to use them appropriately.

Mistake 6: Insufficient Logging and Observability

**
When MCP integrations fail in production, troubleshooting becomes nearly impossible without proper logging and observability. Yet many implementations treat logging as an afterthought, making debugging a frustrating experience of guesswork and trial-and-error.

What goes wrong: Developers implement minimal logging, often just printing errors to stderr. They don't log tool invocations, parameter values, response times, or resource access patterns. When issues occur, they lack the visibility needed to understand what the AI requested, how the server processed it, and where failures occurred.

Another mistake is logging too verbosely in production, creating noise that obscures important events. Or worse, logging sensitive data like user credentials, API keys, or personally identifiable information, creating security and compliance issues.

The correct approach: Implement structured logging from the start. Log every tool invocation with the tool name, parameters (sanitised to remove sensitive data), execution time, and result status. Log resource access patterns, showing which resources were requested and whether they were found. Include request identifiers that allow you to trace a complete interaction flow across multiple operations.

Use appropriate log levels. Debug logs should include detailed information useful for troubleshooting but disabled in production. Info logs should record normal operations like tool invocations and resource access. Warning logs should highlight unusual but handled conditions. Error logs should capture failures with sufficient context to diagnose and fix issues.

Implement metrics collection for operational visibility. Track tool invocation rates, average execution times, error rates, and resource usage. These metrics help you understand usage patterns, identify performance bottlenecks, and detect anomalies that might indicate problems.

Consider implementing request tracing for complex operations that involve multiple tool calls or external service dependencies. Distributed tracing helps you understand the complete flow of a request and identify where time is being spent or where failures occur.

Sanitise logs to prevent leaking sensitive information. Implement allowlists of parameters that can be logged safely, and redact or hash sensitive values. Never log full API keys, passwords, or tokens—log only non-sensitive identifiers.

For the CCA exam, understanding observability best practices is essential. Questions often present troubleshooting scenarios where you must identify what information would be needed to diagnose an issue, and the correct answer invariably involves having implemented appropriate logging and metrics.

Mistake 7: Inadequate Testing and Validation Strategies

**
Testing MCP servers presents unique challenges because the client is an AI model whose behaviour isn't deterministic. Many developers struggle to implement effective testing strategies, leading to fragile implementations that break in production.

What goes wrong: Developers test their MCP servers manually by running them with Claude Desktop and trying a few interactions. They don't implement automated tests, don't validate the JSON-RPC protocol compliance, and don't test error conditions systematically. When they do write tests, they often test internal implementation details rather than the MCP protocol surface.

Another common mistake is not testing with realistic AI interaction patterns. The AI might invoke tools in unexpected orders, provide parameters in different combinations than you anticipated, or interpret your tool descriptions in creative ways. Without testing these scenarios, you won't discover issues until production use.

The correct approach: Implement multiple layers of testing. Start with unit tests for your internal business logic, validating that your core functionality works correctly independent of the MCP protocol. Then implement integration tests that validate your MCP protocol implementation—that tools are exposed correctly, resources are accessible, and the JSON-RPC messages are properly formatted.

Use MCP protocol testing tools to validate compliance. The MCP specification defines exact message formats and behaviours—your server should conform to these precisely. Test that your server correctly handles the initialisation handshake, properly formats tool and resource lists, and returns correctly structured responses and errors.

Create test scenarios that simulate realistic AI interactions. Build test cases that call tools in various orders, provide different parameter combinations, and test edge cases like very long strings, special characters, or boundary values. Test what happens when external dependencies are unavailable, slow, or returning errors.

Implement property-based testing for complex tool parameters. Rather than manually writing test cases for every possible input combination, use property-based testing frameworks to generate diverse inputs and validate that your parameter validation and error handling work correctly.

Test your server's performance characteristics under load. AI applications can generate bursts of rapid tool calls. Validate that your server handles concurrent requests properly, that it doesn't leak resources, and that performance remains acceptable under realistic load patterns.

Document test cases that validate your tool descriptions match their behaviour. The AI relies on your descriptions to understand when and how to use tools. If your description says a tool requires a parameter that's actually optional, or claims it returns data in a format different from reality, the AI will use it incorrectly. Your tests should validate this alignment.

CCA exam questions often present MCP server implementations and ask you to identify issues or suggest improvements. A solid understanding of testing strategies helps you recognise implementations that lack adequate validation and recommend appropriate testing approaches.

Building Production-Ready MCP Servers: A Checklist

**
As you prepare for the CCA Foundations exam or build real MCP implementations, use this checklist to ensure you're avoiding the common mistakes covered in this guide:

Tool Design: Tools represent capabilities, not database operations. Each tool has a clear purpose and comprehensive description. Parameter schemas are well-defined with appropriate types and descriptions.

Resource Implementation: Resources use clear URI schemes. Metadata includes MIME types and descriptions. Resource templates handle dynamic content. Updates are properly signalled when content changes.

Error Handling: All inputs are validated before processing. Errors return proper JSON-RPC error objects with meaningful codes and messages. Timeouts are implemented for all external operations. Error messages are actionable and specific.

Security: Authentication and authorisation are properly implemented. Credentials are stored securely, never hardcoded. Input is validated and sanitised. Rate limiting prevents abuse. Principle of least privilege is applied to all operations.

Prompts and Sampling: Common interaction patterns are encapsulated as prompts. Prompts accept appropriate arguments for reusability. Sampling is implemented where autonomous behaviour is needed.

Observability: Structured logging captures all important events. Sensitive data is sanitised from logs. Metrics track usage patterns and performance. Request tracing enables debugging of complex flows.

Testing: Protocol compliance is validated automatically. Unit tests cover business logic. Integration tests validate MCP behaviour. Edge cases and error conditions are tested systematically. Performance under load is validated.

Preparing for Success on the CCA Foundations Exam

**
Understanding these common MCP server design mistakes and their solutions provides essential knowledge for the Claude Certified Architect Foundations exam. The exam tests not just theoretical understanding but practical application of MCP concepts in realistic scenarios.

Expect questions that present MCP server implementations with subtle issues and ask you to identify problems or recommend improvements. You'll encounter scenarios requiring you to choose between different design approaches, and the correct answers consistently align with the patterns described in this guide. Questions often test your understanding of the trade-offs between different implementation strategies and your ability to recognise when an approach violates MCP best practices.

The exam also includes questions about troubleshooting failed MCP integrations. Your ability to identify missing logging, inadequate error handling, or security vulnerabilities in provided code samples directly impacts your score. Understanding the complete MCP lifecycle—from initialisation through tool invocation to error handling and connection termination—is essential.

Beyond the exam, these patterns represent proven approaches for building MCP servers that work reliably in production. The mistakes covered here account for the majority of real-world MCP integration failures. By understanding them deeply, you're not just preparing for certification—you're developing skills that will serve you throughout your career working with AI systems.

How to Write an Effective CLAUDE.md File: A Practical Guide for AI Architects

Josh — Wed, 26 Aug 2026 09:44:44 +0000

Understanding the CLAUDE.md File and Its Purpose

**
A CLAUDE.md file serves as a critical communication bridge between human developers and AI agents like Claude. Think of it as an instruction manual that sits at the root of your project directory, telling Claude exactly what your project does, how it's structured, and what coding standards to follow. For those preparing for the Claude Certified Architect (CCA) Foundations exam, mastering the art of writing effective CLAUDE.md files is essential—it demonstrates your ability to design systems that leverage AI assistance whilst maintaining code quality and project coherence.

The fundamental purpose of a CLAUDE.md file is to provide persistent context that Claude can reference throughout your development session. Without this file, you'd need to repeatedly explain your project's architecture, conventions, and requirements every time you start a new conversation. This becomes particularly problematic when working on larger codebases where context matters significantly. A well-crafted CLAUDE.md file reduces friction, minimises errors, and ensures Claude's suggestions align with your project's specific needs and constraints.

For CCA candidates, understanding CLAUDE.md files isn't merely about passing an exam—it's about demonstrating competency in one of the most practical aspects of working with AI agents. The exam tests your ability to structure information effectively, communicate technical requirements clearly, and anticipate the needs of both human collaborators and AI assistants. These skills translate directly into real-world scenarios where Claude becomes an integral part of your development workflow.

Essential Components of a CLAUDE.md File

**
Every effective CLAUDE.md file should contain several core sections that work together to provide comprehensive project context. Let's examine each component in detail and understand why it matters.

Project Overview and Purpose
Begin your CLAUDE.md file with a clear, concise description of what your project does. This section should answer fundamental questions: What problem does this project solve? Who are the intended users? What are the key features? Avoid marketing language or vague descriptions. Instead, focus on technical accuracy and specificity.

For example, rather than writing "A revolutionary data processing system," write: "A Python-based ETL pipeline that extracts customer data from PostgreSQL, transforms it according to GDPR requirements, and loads it into BigQuery for analytics. Processes approximately 500,000 records daily with a target latency under 2 hours."

This level of detail helps Claude understand not just what your system does, but also its scale, technology stack, and performance requirements. These contextual clues inform every suggestion Claude makes, from optimisation recommendations to error handling strategies.

Architecture and Structure
Describe your project's architecture in a way that helps Claude navigate your codebase mentally. Include information about the directory structure, key modules or packages, and how different components interact. You don't need to list every file, but highlight the important patterns and organisational principles.

Consider including a simple directory tree for clarity:

src/ - Main application code organised by feature
src/api/ - RESTful API endpoints using Flask
src/services/ - Business logic layer
src/models/ - SQLAlchemy ORM models
tests/ - Pytest unit and integration tests
config/ - Environment-specific configuration files
scripts/ - Utility scripts for deployment and maintenance

When Claude understands your project structure, it can suggest where new code should live, identify potential architectural issues, and maintain consistency across your codebase. This becomes particularly valuable when refactoring or adding new features.

Coding Standards and Conventions
This section is where you establish the rules Claude should follow when generating code. Be explicit about style guides, naming conventions, error handling patterns, and any project-specific standards. The more specific you are, the more consistent Claude's output will be.

Specify your preferred style guide (PEP 8 for Python, Airbnb for JavaScript, etc.) and any deviations from it. For instance: "Follow PEP 8 with the following exceptions: maximum line length is 100 characters (not 79), and we use double quotes for strings unless avoiding escape characters."

Include naming conventions: "Use snake_case for functions and variables, PascalCase for classes, SCREAMING_SNAKE_CASE for constants. Prefix private methods with underscore. Boolean variables should start with 'is_', 'has_', or 'should_'."

Document error handling expectations: "Use specific exception types rather than bare 'except' clauses. Always log exceptions with full stack traces. For API endpoints, return JSON error responses with appropriate HTTP status codes (400 for validation errors, 500 for server errors)."

Technology Stack and Dependencies
List the key technologies, frameworks, libraries, and tools your project uses. Include version numbers when specific versions matter. This prevents Claude from suggesting incompatible libraries or deprecated APIs.

Be comprehensive: "Python 3.11, Flask 2.3.x, SQLAlchemy 2.0, PostgreSQL 14, Redis 7.0 for caching, Celery for background tasks, Docker for containerisation, pytest for testing, black for code formatting, mypy for type checking."

If certain libraries should be avoided, state this explicitly: "Do not use pandas for data processing—we use Polars instead for better performance. Avoid the requests library; we standardise on httpx for both synchronous and asynchronous HTTP calls."

Development Workflow and Commands
Include the essential commands developers (and Claude) need to work with your project. This helps Claude provide accurate instructions when discussing setup, testing, or deployment procedures.

Document setup commands: "Run 'poetry install' to install dependencies. Copy .env.example to .env and configure database credentials. Run 'docker-compose up -d' to start local PostgreSQL and Redis containers."

List testing commands: "Run 'pytest' for all tests. Use 'pytest -m integration' for integration tests only. Run 'pytest --cov' for coverage reports. Target is 80% coverage minimum."

Include quality checks: "Run 'black .' to format code. Use 'mypy src/' for type checking. Run 'flake8 src/' for linting. All checks must pass before committing."

Writing Practices That Improve AI Performance

**
Be Explicit Rather Than Implicit
Claude cannot read your mind or infer unwritten conventions. If your team has specific preferences or requirements, state them clearly. Don't assume Claude will "figure it out" from examining existing code. Whilst Claude is capable of learning from context, explicit instructions in CLAUDE.md take precedence and ensure consistency.

For example, instead of hoping Claude will notice your preference for async/await patterns, write: "Prefer async/await for all I/O operations. Use asyncio for concurrent tasks. Avoid threading except when interfacing with synchronous third-party libraries."

Provide Examples for Complex Patterns
When describing coding patterns that might be unfamiliar or project-specific, include brief examples. This is particularly valuable for architectural patterns, testing strategies, or domain-specific code structures.

For instance, if your project uses a specific service layer pattern, show it: "All database operations must go through service classes. Example: 'UserService.create_user(email, password)' rather than directly instantiating User models. Services handle validation, business logic, and database transactions."

Update Your CLAUDE.md File Regularly
A CLAUDE.md file is a living document. As your project evolves, your CLAUDE.md file should evolve with it. When you make architectural changes, adopt new libraries, or establish new conventions, update the file immediately. An outdated CLAUDE.md file is worse than none at all—it actively misleads Claude and can result in suggestions that conflict with your current setup.

Consider adding a "Last Updated" date at the top of your CLAUDE.md file and treating updates as part of your standard development workflow. When you review pull requests, check whether the CLAUDE.md file needs updating based on the changes introduced.

Use Clear Headings and Organisation
Structure your CLAUDE.md file with clear markdown headings. This helps both humans and Claude quickly locate relevant information. A well-organised file might follow this structure: Project Overview, Architecture, Technology Stack, Coding Standards, Testing Strategy, Development Workflow, Deployment Process, Common Pitfalls, and Additional Resources.

Within each section, use subsections, bullet points, and numbered lists to break information into digestible chunks. Avoid long paragraphs of dense text—they're harder for Claude to parse efficiently and for humans to scan quickly.

Common Mistakes and How to Avoid Them

**
Being Too Generic
The most common mistake is writing a CLAUDE.md file that could apply to any project. Generic instructions like "Write clean code" or "Follow best practices" provide no actionable value. Claude already knows general best practices—what it needs from you is specific guidance about your project's unique requirements and constraints.

Transform generic statements into specific instructions. Instead of "Use appropriate error handling," write: "Wrap all external API calls in try-except blocks. Retry failed requests up to 3 times with exponential backoff. Log all retry attempts at INFO level. After 3 failures, log at ERROR level and raise a custom 'ServiceUnavailableError' exception."

Including Too Much Detail
Whilst specificity is valuable, there's a point of diminishing returns. Don't document every function or describe every edge case. Focus on information that Claude can't easily infer from reading your code. Document the why and the what, not the how of every implementation detail.

For instance, don't list every API endpoint in your CLAUDE.md file—Claude can discover those by examining your route definitions. Instead, document your API design principles: "API endpoints follow RESTful conventions. Use plural nouns for resources (/users, not /user). Nested resources should be limited to one level deep. Prefer query parameters for filtering and pagination."

Forgetting About Human Readers
Remember that whilst the primary audience is Claude, humans will read this file too—particularly new team members or collaborators. Strike a balance between providing machine-parseable information and maintaining human readability. Use natural language, include context where helpful, and consider adding links to relevant documentation or resources.

Neglecting Security and Sensitive Information
Never include credentials, API keys, or other sensitive information in your CLAUDE.md file. Instead, reference where this information should be stored (environment variables, secrets management systems) and provide guidance on how to configure them.

Write: "Database credentials are stored in environment variables: DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASSWORD. For local development, copy .env.example to .env. For production, credentials are managed through AWS Secrets Manager." This tells Claude how to reference credentials without exposing them.

Advanced Techniques for CCA Candidates

**
Context Hierarchies
For larger projects, consider creating a hierarchy of context files. Your main CLAUDE.md file provides project-wide context, whilst subdirectories might contain their own CLAUDE.md files with module-specific information. For example, your API directory might have its own CLAUDE.md describing endpoint patterns, authentication requirements, and response formats.

This approach prevents your main CLAUDE.md file from becoming unwieldy whilst ensuring Claude has access to detailed context when working in specific areas of your codebase.

Conditional Instructions
Some instructions might only apply in certain contexts. Make this clear: "When modifying API endpoints: always update the OpenAPI specification, add integration tests, and update the API documentation. When adding database models: create Alembic migrations, add model tests, and update the ER diagram."

This conditional guidance helps Claude understand when specific rules apply, reducing unnecessary work and maintaining appropriate context sensitivity.

Known Issues and Workarounds
If your project has known limitations, technical debt, or requires specific workarounds, document them. This prevents Claude from suggesting "ideal" solutions that don't work within your constraints: "Our PostgreSQL version doesn't support certain JSON operations—use JSONB casting instead. The legacy authentication system requires specific header formats—see auth_utils.py for the wrapper function."

Integration Patterns
Describe how your system integrates with external services or APIs. Include information about rate limits, authentication methods, and data formats: "GitHub API integration uses OAuth2. Rate limit is 5000 requests/hour. Always check 'X-RateLimit-Remaining' header. Cache repository metadata in Redis with 1-hour TTL."

Testing and Validating Your CLAUDE.md File

**
After writing your CLAUDE.md file, test it practically. Start a new conversation with Claude, ask it to perform a typical development task, and observe whether it follows your guidelines. Does it use the correct naming conventions? Does it import the right libraries? Does it structure code according to your patterns?

If Claude deviates from your expectations, review your CLAUDE.md file. The issue is usually ambiguity, contradiction, or missing information. Refine your instructions and test again. This iterative process helps you develop increasingly effective CLAUDE.md files.

Ask Claude to summarise its understanding of your project based on the CLAUDE.md file. This reveals whether key information is being understood correctly. If Claude's summary misses important points or misinterprets your instructions, revise those sections for clarity.

Sample CLAUDE.md Template
Here's a practical template you can adapt for your projects:

Project Name and Overview: Brief description of what the project does, its purpose, and key functionality.

Architecture: High-level architecture description, key components, and how they interact. Include directory structure for important folders.

Technology Stack: Programming languages, frameworks, libraries, databases, and tools used. Include versions where relevant.

Coding Standards: Style guide, naming conventions, code organisation patterns, comment requirements, and any project-specific conventions.

Testing Requirements: Testing framework, coverage expectations, test organisation, and quality gates.

Development Setup: Commands to install dependencies, configure environment, start development servers, and run tests.

Common Patterns: Frequently used patterns with brief examples—service layer structure, error handling, logging, API response formats.

Things to Avoid: Deprecated patterns, discouraged libraries, or anti-patterns specific to your project.

Additional Resources: Links to relevant documentation, architecture diagrams, or decision records.

CLAUDE.md Files in the CCA Foundations Exam Context

**
The CCA Foundations exam evaluates your understanding of how to effectively communicate with Claude in real-world scenarios. CLAUDE.md files represent a practical application of these principles. Exam questions might ask you to identify issues in a poorly written CLAUDE.md file, suggest improvements, or write sections for specific scenarios.

Key concepts the exam tests include: understanding context windows and token usage (concise but complete documentation), structuring information for machine parsing (clear hierarchies and formatting), anticipating Claude's needs (explicit rather than implicit instructions), and balancing specificity with maintainability.

When preparing for the exam, practise writing CLAUDE.md files for different types of projects: web applications, data pipelines, CLI tools, microservices. Each has unique documentation needs. Understanding these variations demonstrates broader competency.

Remember that effective CLAUDE.md files reflect deeper understanding of both software engineering principles and AI collaboration patterns. They're not mere documentation—they're interfaces that shape how humans and AI work together. This perspective is central to the CCA certification philosophy.

Taking Your Skills to the Next Level

**
Mastering CLAUDE.md files is just one aspect of becoming proficient with Claude. As you prepare for the CCA Foundations exam, focus on understanding the underlying principles: clear communication, appropriate context provision, and effective human-AI collaboration patterns. These skills extend far beyond a single file format.

Experiment with your CLAUDE.md files. Try different organisational approaches, varying levels of detail, and observe how these changes affect Claude's performance on real tasks. Build a personal library of patterns and templates based on what works well. Share your CLAUDE.md files with colleagues and gather feedback on clarity and completeness.

Consider documenting your learnings: which instructions worked particularly well, which created confusion, and how you resolved ambiguities. This reflective practice accelerates your development as a Claude architect and provides valuable study material for certification.

Six searches returned zero. Every one was broken.

Josh — Sun, 23 Aug 2026 08:11:23 +0000

I lost about forty minutes on Friday to a search that returned nothing.

The command was a repo-wide sweep for a string, the kind you run twenty times a day without thinking about it. It printed no matches. I read that as no matches. It exited 0, which is what a successful search with no results also does, so there was nothing to notice.

There were 218 matches.

The command was git ls-files -z | xargs -0 LC_ALL=C grep -n 'PATTERN'. If you have written that line before, look at it again. xargs takes the first token after it as the program to run. That token is LC_ALL=C. It is not a program. xargs tried to execute it, got nothing, produced no output, and returned success. The grep never ran. The locale variable ate the command.

The fix is xargs -0 env LC_ALL=C grep. One word. But the reason it cost forty minutes is not that the bug is subtle — it is that the failure is shaped exactly like a correct answer. Empty stdout, empty stderr, exit 0. Every signal I would have used to check it agreed that the search had worked and found nothing.

It was the fifth one that week
I had already been caught four times, which is the only reason I caught this one at all.

git grep returns silent false zeros for any pattern containing ="/. On Git Bash under Windows, MSYS path conversion rewrites an argument that looks like a Unix path into a Windows path before git.exe ever sees it. So git grep 'href="/blog/' searches for something else entirely and reports nothing. Plain grep is an MSYS binary and is unaffected — which is why the two disagree, and why the git grep zero looks like the authoritative one. MSYS_NO_PATHCONV=1 fixes it. Every link, nav, and internal-href search I had run on that repo was suspect.

grep -P with a non-ASCII character class dies on this locale. It prints "-P supports only unibyte and UTF-8 locales" to stderr and nothing to stdout. If you are reading stdout — and you are, because that is where matches appear — you see a clean zero.

grep -c $'\r$' miscounts line endings. cat -A strips CR and shows a CRLF file as LF. Both were being used to decide whether a file's line endings were about to be mangled, and both were answering a different question than the one asked.

Six tools, one week, all reporting nothing while the thing sat in front of them.

The same bug, one level up

**
What made me start checking is that I had already been burned by the abstract version of this.

A defect class in that project had been recorded as closed. The note said, in effect, no item in the bank now has this problem. It was written after a sweep, the sweep was real, and the sweep had found and fixed everything it looked at.

The sweep had been aimed at one particular string. The claim was about a whole class. Those are different statements, and the gap between them had been sitting there for four days with a live instance in it — an instance the same document mentioned in a different section, which nobody had read against the first one.

That is the same failure as the xargs line. A detector was pointed at one thing, returned zero for that thing, and the zero got promoted into a claim about something larger. The tool was working correctly. The inference was not.

And this is where it interacts badly with agents. I do a lot of this work with a coding agent, and an agent that runs a search and gets no output will tell you, accurately and confidently, that it found no occurrences. It is not wrong about what it observed. It is reporting a zero it has no way to distinguish from a broken detector — and it will report it in a clear declarative sentence that reads exactly like a finding.

This is not a quirk of one tool. Designing systems that can distinguish a real result from a failed instrument is a named competency — the CCAR-F exam's Context Management & Reliability domain covers it directly, down to building a taxonomy that separates transient failures worth retrying from permanent ones that need different handling.

I have written about this before, in a different form: your coding agent's summary of its own work is not evidence. This is the narrower case. A zero that an agent reports is not evidence of absence. It is evidence that a command produced no output, and those are only the same thing when the command ran.

The rule, which is one extra line

**
Before you trust a zero, prove the detector fires.

Run the same command against something you know is there. If you are sweeping for a flag that should have been removed, first search for a flag you know is still present and confirm you get hits. If that control comes back empty too, your detector is broken and the real search was never a search.

It costs one command. It would have caught all six.

In practice it looks like this. Say you are confirming a deprecated flag is gone:

grep -rn -- '--old-flag' . # the real search: expect 0
grep -rn -- '--flag-that-remains' . # the control: expect hits
If the second one is also empty, stop. You have not learned that the flag is gone; you have learned that your search does not work in this directory, with this shell, against these files. The control costs two seconds and it is the only thing standing between a zero and a belief.

The control has to be a string you have independently confirmed is present — ideally by opening the file and looking at it. A control you assume is there is just a second unproved search, and two unproved searches agreeing tells you nothing at all.

There is a second half, for when the zero is real but the claim is bigger than the search: **state the property you are claiming, then name the detector that tests that property. **If your detector only tests the specific instance that made you look, you have closed an instance. Say so. Do not write down that the class is closed, because in three weeks somebody — possibly you — will read that sentence and stop looking.

The same distinction matters one level up, in orchestrator and subagent designs: a subagent returning "no results" and a subagent that failed to run are different states, and every extra handoff is one more place that difference can be lost.

And a third, which caught me on a different question the same week: before attributing a change to a commit, check that the code actually differed. I had a metric that dropped in a particular week and a new event that appeared in the same week, and the fit was so tight that I built a whole explanation on it. The event was new. The behaviour was not — the file was byte-identical across both periods, and the event had simply started measuring something that had been there for a month. Two blob hashes would have killed it in five minutes. A new event is not a new behaviour.

What I actually changed

**
Not much, and that is the point. I keep a short list of tools that have lied to me on this setup, with the failure mode and the fix, and I read it before I trust a zero on anything that matters. There are six entries. I expect there to be more.

The list is worth more than any individual fix on it, because the entries are not really about xargs or git grep. They are about a category of result that looks identical whether it is true or whether the machinery failed — and that category is much larger than six commands. It includes every empty search, every clean test run that did not actually execute, every green check on a job that skipped, and every confident report from an agent that a thing does not exist.

A zero is a measurement. Measurements have instruments. Check the instrument.

CCAR-F vs CCA-F: which is the real Claude Certified Architect – Foundations exam code?

Josh — Thu, 20 Aug 2026 16:16:07 +0000

Anyone researching the Claude Certified Architect – Foundations certification runs into the same small confusion early: the exam appears under two different codes. Community study repos, forum threads and prep sites — including parts of this one until recently — call it CCA-F. The official Exam Guide calls it CCAR-F.

CCAR-F is the code in the published guide. Version 1.0, effective July 2026, lists it in the exam details table alongside the credential name. It is the string that appears on the official listing and on the booking.

CCA-F is informal shorthand for the same exam. It reads as a natural abbreviation of "Claude Certified Architect – Foundations", it circulated widely in community material, and a great deal of study content still uses it. It is not a different certification, an earlier version, or a lower tier. It is the same sixty-item exam under a name that was never on the paperwork.

There is also a Professional-level Architect exam, CCAR-P, with its own published guide and a separate blueprint. Foundations is the entry point of the two, and the shared "CCAR" stem is the clearest signal that the Architect codes were designed as a family.

Which code to use, and when
The distinction matters in three practical places.

Registering. Use CCAR-F. It is what appears when registering through the Anthropic Partner Academy, with scheduling handled by Pearson VUE. Searching a booking system for CCA-F may return nothing at all.

Searching for study material. Use both, separately. The two codes surface substantially different results, because most existing content was written under one or the other rather than both. A search under a single code returns perhaps half of what exists. Anyone who has downloaded the guide and read the code off it will naturally search CCAR-F — and will miss the large body of community material filed under CCA-F.

**Writing or citing. **Lead with CCAR-F and mention CCA-F alongside it. Both are true, one is official, and readers arrive with either.

A useful heuristic falls out of this: the code a resource uses is a rough proxy for whether it was written from the guide or from other people’s summaries of it. That is not a reliable rule — plenty of good material predates the v1.0 guide — but it is worth noticing when weighing an unfamiliar source.

What the published guide specifies
Everything below is from Exam Guide v1.0. The guide is the authoritative reference and this is a summary of it, not a substitute — it is worth reading in full before scheduling.

Credential Claude Certified Architect – Foundations
Exam code CCAR-F
Number of items 60
Item format Multiple-choice and multiple-response; each item states how many responses to select
Exam structure 4 scenarios drawn from a bank of 6
Time limit 120 minutes
Passing score Scaled score of 720 on a range of 100–1,000
Exam fee $125 USD
Validity 12 months from the date the credential is awarded
Delivery Proctored — online or at a Pearson VUE test centre

Three of those lines are worth expanding, because each one changes how a candidate should prepare.

Four scenarios appear out of six. All six are published in the guide: a customer support resolution agent, code generation with Claude Code, a multi-agent research system, developer productivity tooling, Claude Code in CI/CD, and structured data extraction. Because only four appear on any given form, core mechanisms recur across them — a candidate meets the same ideas from several angles rather than answering sixty scenario-based items on sixty separate topics. That has a direct consequence for study material: encountering a mechanism more than once is how the exam itself works, not a defect in the practice bank.

**Both item formats are used. **The guide specifies multiple-choice and multiple-response items, and states that each item tells the candidate how many responses to select. It does not say what share of the exam is multiple-response, so any source quoting a percentage has taken that number from somewhere other than the guide.

The pass mark is not a percentage. It is a scaled score of 720 on a range of 100 to 1,000, which is not the same as answering 72% of items correctly — scaled scoring exists to equate results across exam forms of slightly different difficulty. The $125 registration fee is charged per attempt, which matters more than it first appears.

The five domains and their weights
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%

Because the weights differ by nearly two to one between the largest and smallest, it is worth deciding deliberately how to allocate study time by domain weight rather than working through the blueprint evenly.

Agentic Architecture & Orchestration is the largest single block at more than a quarter of the exam, and it carries the most task statements — seven, covering agentic loops, coordinator and subagent patterns, context passing, enforcement and handoff, hooks, task decomposition, and session management.

The most commonly underestimated is Claude Code Configuration & Workflows. On paper it looks like the domain a working developer absorbs by using the tool. In practice it turns on distinctions nobody stumbles into — when a path-scoped rule beats a directory-level CLAUDE.md, what context: fork actually protects, why plan mode earns its cost on a migration and wastes it on a one-line fix. A fifth of the exam sits there.

The score report gives a pass or fail with a scaled score, plus percent-correct by domain. The domain percentages are informational only; the pass decision rests on the total scaled score alone.

The section most candidates never read
The guide names topics that will not appear on the exam, and several are exactly what an experienced engineer assumes an AI certification must test:

Fine-tuning or training custom models
Claude’s internal architecture, training process, or model weights
Constitutional AI, RLHF, and safety training methodology
Embedding models and vector database implementation
Computer use, browser automation, vision and image analysis
Streaming API implementation and server-sent events
Rate limiting, quotas, and API pricing calculations
OAuth, API key rotation, and authentication protocols
Deploying or hosting MCP servers — infrastructure, networking, containers
Specific cloud provider configuration
Token counting and tokenization specifics
Prompt caching implementation details, beyond knowing it exists
Time spent revising vector stores or working through fine-tuning tutorials buys nothing here. The blueprint tests architectural judgement in production — which mechanism to reach for, and what trade-off comes with it. Not whether a candidate can recall that PostToolUse exists, but whether they know when a hook is the right answer and when a prompt instruction is.

Scheduling, retakes and renewal
Candidates can cancel or reschedule up to twenty-four hours before the appointment; changes inside that window forfeit the fee.

The waiting periods after a failed attempt lengthen each time — fourteen days after the first, thirty after the second, ninety after the third — with a maximum of four attempts per rolling twelve months. The fee applies to each attempt, so a retake costs another $125. That arithmetic is worth doing before booking the first sitting.

The credential lasts twelve months. Renewing on time means reviewing what has changed and completing a free, non-proctored assessment on the Partner Academy, at no fee. A lapsed credential means retaking the full exam at full price. The guide also notes that if exam content changes significantly, holders may be required to retake rather than renew.

Preparing
The guide’s own preparation section is specific and hands-on rather than theoretical: build an agent with the Agent SDK and implement a complete loop with tool calling and session management; configure Claude Code for a real project with a CLAUDE.md hierarchy, path-specific rules and at least one MCP server; design MCP tools with structured error responses; build an extraction pipeline using tool use with JSON schemas; and practise escalation and human-in-the-loop patterns. Section 8 sets out four full exercises with steps.

Practice questions earn their place by surfacing the trade-off reasoning the exam actually tests, which is difficult to rehearse against documentation alone. A free diagnostic gives a rough read on where a candidate stands against the 720 mark, and the practice question bank covers all five domains at their published weights.

Claude Certified Architect Jobs: Who's Hiring and How to Land One

Josh — Tue, 18 Aug 2026 13:17:12 +0000

If you're chasing the roles built around Claude and agentic AI — not just curious about the certification, but actually job-hunting — the useful question isn't "how do I become a Claude Certified Architect." It's where the openings actually are, what those postings ask for, and how to put the CCA-F in front of the right hiring manager. This page is about the demand side: the job titles worth searching for, the kinds of employers building on Claude right now, and a realistic path from credential to interview.

A quick note on scope, since the CCA-F is a new credential: this is an independent, third-party exam-prep resource — not an official Anthropic hiring program — and the CCA Foundations exam only launched in March 2026. That means there isn't hard data yet on exactly how many postings name it as a requirement. What follows is grounded guidance on where the underlying skills are in demand and how to position yourself, not invented statistics.

Looking for the career path itself, rather than the job search? See how to become a Claude Certified Architect for the roles and route in. For what the work actually involves day to day, see what a Claude Certified Architect actually does. For pay expectations, see Claude Certified Architect salary and career outlook. This page picks up where those leave off — landing the role.

Job Titles Worth Searching For
Very few postings say "Claude Certified Architect" verbatim yet — the title is new, and most hiring managers are still using the job titles that predate the credential. Search and set alerts for these instead, ideally paired with "Claude" or "Anthropic" in the description:

AI/ML Engineer — where the description specifies Claude, Anthropic, or LLM-based systems specifically

Agentic Systems Engineer / Agent Engineer

AI Solutions Architect / AI Solutions Engineer

AI Platform Engineer

Applied AI Engineer

LLM Integration Engineer / Conversational AI Engineer

AI Product Engineer — at product companies embedding Claude into an existing product

Technical AI Product Manager — less common, but draws on the same architectural fluency

The common thread across all of these is agent design, tool use, and production LLM deployment — not the literal job title. Filter and search on the skills above rather than searching "Claude Certified Architect" as a title, and you'll surface far more of the roles actually built for this skill set.

Where the Demand Is Coming From
Naming specific employers here would go stale fast and wouldn't be a reliable guide — but the types of organisations doing this hiring right now are fairly consistent:

AI-native startups and scale-ups building their core product on Claude
Established software companies adding Claude-powered features to an existing product

Enterprise consulting and professional-services firms doing client-facing AI implementation work

Internal platform teams at larger companies standing up shared Claude or Claude Code infrastructure for other engineers

Independent agencies and boutique studios specialising in AI transformation projects

Each of these hires differently. Startups move fast and weight shipped work heavily. Consulting firms care about client-facing communication as much as technical depth. Internal platform teams look for DevOps or infrastructure background alongside the Claude-specific skills. Match your search — and how you frame your resume — to the employer type, not just the skill set.

What These Postings Actually Ask For
Even where "Claude Certified Architect" doesn't appear as a title, the postings in this space tend to converge on a consistent set of asks:

Production experience with an LLM API — Claude or otherwise — not tutorials or personal projects alone

Experience designing tool use, function calling, or multi-step agent workflows

Prompt engineering treated as a discipline, not just "writes good prompts"
Some exposure to context management at scale — token budgets, prompt caching, long-running conversations

For platform-leaning roles: developer tooling, CI/CD, or internal infrastructure experience

This is exactly the ground the CCA Foundations exam covers, which is the point of holding it: the credential is a compressed way of demonstrating you've studied this territory. It doesn't replace showing real work — but it gives whoever's screening resumes a faster reason to take yours seriously.

How to Put the CCA-F on Your Resume and LinkedIn

LinkedIn
Add it properly under "Licenses & Certifications," with Anthropic listed as the issuing organisation and the credential name exactly as issued.
Add "Claude," "Anthropic API," "Agentic AI," "Model Context Protocol (MCP)," and "Prompt Engineering" as skills — these are the terms recruiters filter search results on.

If you've shipped a Claude-powered project, feature it and tie the certification to it directly in the description, rather than letting the credential stand alone.

Only lead your headline with the credential if you also have production experience to back it. A headline claim without substance behind it invites exactly the scrutiny you don't want in a first screen.

Resume
Place it in a dedicated "Certifications" section near the top when applying to AI or Claude-specific roles — buried under a generic "Other" heading, it won't do its job.

Pair it with one bullet describing something concrete you built or shipped with Claude. The certification plus evidence is a materially stronger signal than either on its own.

If you're switching careers and don't have production Claude experience yet, say so honestly and lead with transferable architecture or engineering experience instead — see the career-switch prep guide for how to frame that gap.

A Realistic Hiring Pipeline for CCA-F Holders
The certification changes what happens at the top of the funnel — it doesn't change what happens after it. A realistic pipeline looks like this:

Resume or application screen: the CCA-F earns you a second look, especially where an AI-literate recruiter or keyword filter is doing first-pass screening. It improves your odds of getting past this stage — it doesn't guarantee it.
Recruiter or hiring-manager call: you'll be asked what you've actually built, not to describe the exam. Have a specific project ready to walk through.

Technical screen: expect scenario-based questions similar in spirit to the exam itself — architectural trade-offs, not trivia. This is where studying the material, not just passing the exam, pays off.

System design or take-home: the stage where the judgment the CCA-F verifies actually gets tested directly, usually through an exercise involving agent orchestration, tool design, or context management.

Final or culture round: standard for the role level, largely unrelated to the credential itself.

Because the CCA-F only launched in March 2026, most hiring pipelines haven't formalised around it yet the way they have for older, established certifications. Treat that as an opportunity, not a gap: holding it now positions you ahead of the market catching up to it, not behind a requirement everyone else already has.

CCA-F Certification vs an AI Bootcamp: Which Is Worth Your Time and Money?

Josh — Fri, 14 Aug 2026 15:50:22 +0000

If you're trying to break into AI/Claude architecture work, you've probably looked at two very different price tags: a bootcamp running into the thousands of dollars over several months, or a $125 exam plus a self-paced practice bank. That's not a question of which one is objectively "better" — it's a question of which container actually fits where you're starting from, how you learn, and what's missing between now and a job. This page is a head-to-head on that specific fork, not a broader argument for either path.

For the ROI case on the certification itself, see is the Claude Certified Architect certification worth it. If you've already decided the certification path is right for you and want a study plan built around switching careers, see how to prepare for the CCA-F when you're switching careers. This post picks up before either of those — deciding whether a bootcamp or the certification path is the right starting point at all.

What an AI Bootcamp Actually Gives You
Be honest about this: a good bootcamp offers real things a certification exam and a question bank cannot.

A structured curriculum sequenced by someone who has already figured out the right order to learn things in, instead of you assembling that order yourself from scattered resources.

Live mentorship — instructors and TAs who can catch a conceptual gap in real time, something a static resource can't do.
A cohort — peers moving through the same material on the same timeline, which normalizes the struggle and creates accountability that's hard to manufacture alone.
Career services — resume workshops, interview prep, and sometimes direct employer relationships or placement partnerships.
Forced momentum — a fixed schedule and sunk cost that keeps people moving who would otherwise stall out studying alone.

If you're coming from a genuinely non-technical background with no engineering foundation to build on, or you've tried to self-teach before and stalled without external structure, that container is a legitimate reason to pay for a bootcamp. No certification replaces it.

What a Bootcamp Typically Costs — Time and Money
Pricing and length vary widely by provider, format, and whether the program is full-time or part-time, so treat any number here as a general pattern, not a quote — confirm current pricing directly with whichever program you're considering. That said, full-time, instructor-led AI or software bootcamps typically run into the thousands of dollars and often into the five-figure range, with part-time or self-paced tracks usually priced lower. Program length commonly spans several weeks of full-time study up to a few months. Financing plans, income-share agreements, and employer sponsorship are common ways people offset the cost, but the upfront commitment — in both money and time away from other things — is real.

The Case for the Certification + Self-Study Path
The CCA-F path looks completely different if you already have a functioning technical foundation — existing software engineering experience, a cloud or solutions architecture background, ML/data engineering work, or a technical product management role. In that case, you're not trying to learn to build software from zero. You're formalizing architectural judgment on top of skills you already have, and a bootcamp's core value — teaching you to code, or teaching the fundamentals of software engineering — is largely redundant for you.

The certification itself is a fixed, known cost: a $125 exam fee, 60 scenario-based questions across five weighted domains, 120 minutes, scored on a 100–1000 scale with a pass mark of 720, delivered through Pearson VUE, valid for 12 months. Items are multiple-choice and multiple-response — each item states how many responses to select. If you want structured practice beforehand, our own $49 question bank is modeled on the exam's format and difficulty (not the actual exam questions), and the free diagnostic gives you a quick read on where you stand before you spend anything.

Set against even the cheaper end of a bootcamp, that's a small fraction of the cost, and the time commitment is measured in weeks of self-paced study around a job rather than months away from one. What it doesn't give you: no mentorship, no cohort, no career-services team. You supply the accountability, and you need to already have (or separately build) the underlying technical skill — the exam certifies judgment, it doesn't teach the fundamentals.

Who Should Actually Choose a Bootcamp
You're starting from little or no technical background and need the fundamentals taught, not just certified. You learn best with external structure, deadlines, and accountability rather than self-directed study. You want built-in mentorship or a peer cohort going through the same material at the same time. You want a career-services pipeline — resume help, interview prep, employer connections — bundled into the program rather than assembled yourself. You can afford the time and money commitment a structured program requires.

Who the Certification Path Fits Better
You already have relevant technical experience — software engineering, cloud/solutions architecture, ML/data engineering, or a technical product role — and need to formalize or prove it, not acquire it from scratch.
You're a self-directed learner who doesn't need external structure to stay on track. You're constrained on time or money and can't take months off or pay bootcamp tuition. You want a fast, low-cost way to signal architectural competence to employers while you keep working.

Can You Do Both?
They're not mutually exclusive, and for some people the right sequence is both, not either/or. If you're starting from genuinely no technical background, a bootcamp can build the foundation, and the CCA-F afterward becomes the credentialing step that proves what the bootcamp taught. Treat them as sequential rather than competing in that case — neither one substitutes for the other's role in your specific situation.

Not sure which situation actually describes you? Take the free 10-question readiness diagnostic. If you clear it comfortably, you likely already have the technical foundation the certification path assumes. If it's a real struggle, that's a signal you may need more structured groundwork first — whether that's a bootcamp or another foundational path — before the certification makes sense. If you decide the certification path is right for you, build exam-ready judgment with the 400-question practice bank, modeled on the exam's format and difficulty.

The workflow you turned off is still a load-bearing part of your system

Josh — Wed, 12 Aug 2026 11:20:27 +0000

A month ago I disabled a GitHub Actions workflow. It was the right call and I made it in about ninety seconds.

The workflow pre-rendered static HTML for a site I run — read the JSON sources, generate the pages, commit the output back to the repo. It had started corrupting content. I reverted the damaged files by hand, went into the Actions tab, and switched it off. Then I got on with the day.

Last week I went looking for why it was off.

Not because anything broke. Because I wanted to publish an article, and publishing turned out to require that workflow, and I could not remember what was wrong with it.

What the record actually said
Here is everything the repository knew about that decision:

The last run: successful, on July 9th.
The workflow's state: disabled_manually, timestamped about twenty minutes after that successful run finished.
Commits touching .github/workflows/: none since June.
That is the complete record. A workflow that had never failed, switched off with no commit, no issue, and no note. From the outside — and from my own perspective a month later — it looked like somebody had flipped a toggle for no reason.

It took a working session to reconstruct the actual story, and I only got there because a commit message three weeks earlier happened to say revert: undo prerender-bot re-poisoning. Sixteen files restored by hand. The word re-poisoning implying it had happened before. That commit was the only surviving evidence of why the automation was untrustworthy.

The fix was in git. The reason was in my head. One of those two things persists.

The part I had not costed
Here is what makes this more than a documentation lapse.

The site's blog posts live as JSON. The pages a visitor loads are generated from that JSON by the build. So the build was not a convenience — it was the only path from source to published page.

When I disabled the workflow, I did not think of myself as disabling publishing. I thought of myself as stopping a bot from corrupting files. Both were true. Only one was intentional.

For a month, the practical state of that system was: content can be written but not shipped. Nobody noticed, because in that month I mostly wasn't publishing. The constraint and the lull lined up, and a real blocker sat invisible behind an ordinary quiet patch.

Disabling a component does not remove it from your architecture. It changes what your architecture does. The dependency graph didn't shrink when I flipped the switch; one node just started returning nothing, silently, to every caller that had never been written to expect that.

Why this is an agent problem too
I have been describing a CI workflow, but the shape generalises, and it is the same shape that shows up in every production agent system I have worked on.

A component that fails loudly teaches you its dependencies. A component that is quietly absent teaches you nothing.

When a tool call errors, everything downstream learns something: the model sees a failure, a retry can fire, a human can be paged. When a tool is silently removed — deregistered, permission-revoked, quietly returning an empty result — the calling agent frequently proceeds as though nothing happened. It has no signal to react to. Absence is not an error, and most systems only handle errors.

This is precisely why structured error responses matter more than they look like they should. An MCP tool that returns a proper error object — isError, a category, a retryable flag — is telling the model something it can act on. A tool that returns an empty list because its backing service is switched off is telling the model that there are zero results, which is a different claim, and a false one.

The failure mode is identical to mine. Something was turned off deliberately, for good reasons, and the system it belonged to kept operating as though the change had not happened — because nothing in the design forced the change to be visible.

Three things I would tell my past self
Record the reason at the moment of the decision, not the fix. I reverted the corrupted files properly. Sixteen files, clean commit, good message. What I did not do was write down why the automation could not be trusted, because at that moment it was so obvious to me that it did not feel like information. A month later it was the only thing I needed and the only thing missing.

A disabled component needs an owner and a re-entry condition. "Off until we work out what went wrong" is a plan. "Off" is a state. Mine had no condition attached, so there was nothing to satisfy and nothing to check — it simply stayed off, and the question of whether it should be back on never surfaced.

Ask what the component was load-bearing for, not just what it did. I could have described what the workflow did in one sentence. I could not, at the moment of disabling it, have listed what depended on it. Those are different questions and only the second one predicts what breaks.

The thing that actually made this recoverable
One detail saved me a much worse week.

When I finally sat down to work out whether the build was safe to run at all, the decisive question was whether it had ever written back to the source JSON — because if the corruption had reached source, the damage would have been unbounded and a month old.

It had not. The build only ever read from source and wrote to output. Six write targets, all generated files, no path back upstream.

That was not luck, though I would like to claim it. It is the standard property that makes generated-artifact pipelines recoverable: the generator never mutates its input. Because that held, the corruption could only ever affect files that were reproducible from a source that was still intact, which is why sixteen files could be reverted by hand and the problem stayed contained.

The same property is what makes an agent system debuggable. If your agent writes back into the context it reads from, or a tool mutates the record it was asked to summarise, you lose the ability to reason about what went wrong — because the evidence has been overwritten by the thing you are investigating. Read paths and write paths that stay separate are what let you answer the question "what actually happened" a month later.

Where this connects to the exam
The Claude Certified Architect – Foundations blueprint spends a lot of its weight on this distinction, and it took me a while to understand why. Structured error responses, deterministic guarantees over probabilistic compliance, human-in-the-loop checkpoints, minimal footprint — they can read like a list of best practices to memorise.

They are all the same idea from different angles: the system should make its own state legible to whatever comes next, including you, later, with no memory of what you were thinking.

I disabled a workflow for an excellent reason and left no way for anyone — including me — to discover that reason. Every principle in that blueprint is a defence against some version of that.

(Written from a real week on a small production site. The workflow is still off. It now carries a comment explaining why it was disabled, and three conditions that have to be met before anyone turns it back on.)

Your coding agent's summary of its own work is not evidence

Josh — Sun, 09 Aug 2026 16:53:17 +0000

I spent three days last week doing real work on a production codebase with an agentic coding tool. Small site, live customers, money moving through it. The kind of place where a bad commit costs something.

The work went well. Three commits shipped, all verified, all live. But a pattern showed up on day one and repeated often enough that I now build my sessions around it:

The agent's summary of what it did was wrong often enough that I stopped reading summaries.

Not wrong in a dramatic way. Wrong in the quiet way that passes a skim.

Four times it happened

It told me nothing was staged. It had already committed.

I asked for a diff, got one, and got a closing line: "Nothing staged." Two turns later I asked it to stage and commit. It replied that the commit already existed — same hash, same message — and correctly refused to commit unrelated files under a message that didn't describe them.

Good refusal. But the earlier report had been wrong, and I'd built a step on top of it.

It silently dropped half a request.

I asked for two checks in one message: a repo-wide grep, and a CSS dump. It returned the CSS in detail, said nothing about the grep, and signed off with "Nothing was edited or staged" — which reads like a complete report. The missing half was the half that would have told me whether the thing I was about to edit was generated by a build script or hand-written markup.

That's the check that decides whether your edit survives the next build.

It added a table up by eye and got the wrong number.

It reported "21 links changed across 8 files" and said this matched an earlier count. It didn't. When I asked it to grep and count properly, the real number was 20 — and its own per-file table, printed two messages earlier, had summed to 20 all along.

Worth noting: I'd independently eyeballed the same table and got 18. Both of us added up a list without counting it. Neither of us caught it until a grep -o settled it.

It asserted byte-identity where it meant functional equivalence.

A refactor moved a chunk of HTML into a shared function. The agent said the output was "byte-identical, not just equivalent." It wasn't — the new version built the same tag through a different string-escaping route, so the emitted attribute delimiters differed. The browser doesn't care. The claim was still false, stated with more confidence than the situation supported.

Why this isn't a complaint about a tool

Every one of these is a model reporting on its own recent work, which is the one thing it's structurally worst at.

A model that just generated something carries the reasoning that produced it. When it then reviews that work, it isn't approaching the artifact fresh — it's approaching its own intention, which is always cleaner than the output. That's why "check your work" produces so little, and why a second, independent pass catches things the first one can't.

Same reason code review works better when someone else does it.

The practical upshot is that the agent's report and the agent's output are two different artifacts with different reliability. The output was almost always fine. The report was the thing that drifted.

What I do now

These are session rules, not prompts. I paste them at the top of every session.

Print it, don't summarise it. "Print the complete unified diff, every hunk, in full. Do not summarise what you changed." The difference in outcome is large. A summary is the model's model of the change. A diff is the change.

Staging is not a verification step. The agent had staged past a verification checkpoint four times in three days. Now the rule is explicit: print, then I read, then stage, then commit, then push — and push only on a separate instruction.

Locate fresh from disk every time. Line numbers in your notes go stale the moment anything is edited. Any prompt that says "the function at line 1640" is a prompt that will eventually edit the wrong thing. Say "find it by searching for this literal string" instead.

Ask for the check that would falsify you. Not "confirm the tests pass" but "print the output of the test run." Not "is this still there?" but "grep for it and print every match with file and line." One of these can be answered from memory. The other can't.

Grep fragments, not sentences. After removing a phrase, searching for the whole sentence tells you the sentence is gone. It doesn't tell you a fragment survived somewhere else. Search the shortest distinctive substring.

Count with a tool, not with your eyes. Both the agent and I got the link count wrong from the same table. grep -c doesn't have that failure mode.

Verify on the artifact, not the diff. For a web change, that means loading the live page in a fresh private window. A clean diff and a green build still leave room for a broken deploy, a stale cache, or a file that never regenerated.

The part that generalises

If you're building agentic systems rather than just using them, this maps onto something specific: the distinction between what a model reports and what actually happened is an architectural concern, not a prompting one.

You don't fix it by asking nicer. You fix it by designing the loop so that verification comes from somewhere the model can't narrate — a tool result, a test exit code, a diff, a fresh instance without the generating context. If your agent's only evidence that a step succeeded is the agent saying so, you have a system that degrades silently.

That principle shows up all over production agent design: independent review passes rather than self-review instructions, programmatic prerequisites rather than prompt-based ordering, structured tool errors rather than a model's account of what went wrong. It's also, not coincidentally, a large chunk of what the Claude Certified Architect – Foundations exam tests — the difference between deterministic guarantees and probabilistic compliance is a recurring theme, and it's recurring because it keeps mattering.

What I'd tell someone starting

Agentic coding is genuinely good. Three commits across those days, on a live codebase, each properly scoped, each verified, none reverted. That's a real gain and I'm not going back.

But the failure mode isn't the one people warn about. It isn't hallucinated APIs or confidently wrong code — those are loud and you catch them immediately.

It's the quiet report that reads complete and isn't. It costs you nothing at the time and one debugging session later.

Make it print.

Claude Certified Architect Exam: How to Know If You're Ready Before Test Day

Josh — Fri, 12 Jun 2026 15:35:30 +0000

The Claude Certified Architect Exam is becoming one of the most sought-after certifications for professionals building AI-powered applications with Claude. As organizations increasingly deploy AI into production environments, they need architects who understand far more than prompting—they need professionals who can design reliable, scalable, and effective AI systems.

But one question stops almost every candidate:

"Am I actually ready for the exam?"

Why the Claude Certified Architect Exam Is Challenging

The exam tests practical architectural knowledge across multiple domains. Candidates are expected to understand:

Agentic Architecture & Orchestration
Tool Design & MCP Integration
Claude Code Configuration & Workflows
Prompt Engineering & Structured Output
Context Management & Reliability

Many questions require applying concepts to real-world scenarios rather than simply recalling facts.

The Problem with Most Study Plans

Most candidates begin by reading documentation, watching videos, and experimenting with projects.

Weeks later, they still don't know:

Which topics they're strongest in
Which areas need the most improvement
Whether they're actually ready for the exam

Without a baseline assessment, preparation becomes guesswork.

Start with a Free Readiness Diagnostic

Before spending dozens of hours studying, take a free diagnostic assessment at:

https://www.claudecertifiedarchitects.com/

The diagnostic evaluates your knowledge across all five exam domains and helps identify the areas where additional study will have the biggest impact.

Coverage Across All Five Domains
Agentic Architecture & Orchestration

Understand your readiness for questions involving workflow design, agent coordination, task decomposition, and orchestration patterns.

Tool Design & MCP Integration

Evaluate your knowledge of tool calling, integration strategies, MCP concepts, and architectural decision-making.

Claude Code Configuration & Workflows

Assess your familiarity with project setup, workflows, configuration patterns, and development best practices.

Prompt Engineering & Structured Output

Measure your understanding of prompt design, output reliability, validation strategies, and structured generation.

Context Management & Reliability

Identify strengths and weaknesses related to context handling, reliability engineering, memory management, and failure recovery.

Why a Diagnostic Matters

A focused study plan consistently outperforms a broad study plan.

When you know your weakest domains, you can prioritize your preparation and avoid wasting time reviewing concepts you've already mastered.

Take the Free Claude Certified Architect Diagnostic

If you're preparing for the Claude Certified Architect Exam, start by understanding where you stand today.

Take the free diagnostic now:

https://www.claudecertifiedarchitects.com/

Your future exam score may depend less on how much you study and more on whether you're studying the right things.

# Cracking the Claude Certified Architect Exam: Production-Grade AI is a Different Beast

Josh — Thu, 11 Jun 2026 15:44:11 +0000

If you’ve been building LLM applications for a while, you know that the gap between a cool local demo and a robust, enterprise-grade production system is massive. Local scripts don’t have to handle multi-agent race conditions, cascading tool failures, or prompt dilution across thousands of tokens.

Anthropic explicitly targeted this gap when they launched the Claude Certified Architect – Foundations (CCA) exam.

Unlike entry-level cloud certifications that test your ability to memorize product names or parameter limits, the Claude Certified Architect exam is a purely scenario-based, architecture-level challenge. It doesn't care if you've memorized the documentation; it cares if you know how to build systems that don’t break when real-world data hits them.

If you are thinking about sitting for the proctored exam, here is exactly what you need to know about its architecture, the core anti-patterns Anthropic will use to trick you, and how to prepare.

What the Exam Actually Tests (The 5 Domains)

The exam structures its 60 multiple-choice questions across 5 core technical domains. The weighting leans heavily into orchestration and tool execution:

Agentic Architecture & Orchestration (~27%): Designing deterministic agentic loops, subagent spawning, and state management.
Tool Design & MCP Integration (~18%): Writing robust Model Context Protocol (MCP) tool schemas and descriptions that prevent routing confusion.
Claude Code Configuration (~20%): Mastering CLAUDE.md hierarchy, plan mode vs. direct execution, and CI/CD automation.
Prompt Engineering & Structured Output (~20%): Enforcing JSON schemas through tool selection rather than raw text prompting.
Context Management & Reliability (~15%): Preventing context window degradation, managing progressive summarization, and building fallback/human-in-the-loop loops.

Instead of generic questions, the test pulls from 4 out of 6 hidden production scenarios (ranging from a multi-agent automated research engine to a code generation pipeline running in CI/CD). Every single question drops you into one of these environments and forces you to make a high-stakes architectural decision.

3 Core Anti-Patterns to Memorize Before the Test

Anthropic designs its distractor choices brilliantly. They will offer you answers that sound like totally reasonable "prompt engineering" fixes, but are actually architectural brittle points. Look out for these three traps:

1. Parsing Natural Language for Loop Termination

When building autonomous agent loops, a classic mistake is instructing Claude to write "STOP" or "FINISHED" in the text when it is done, and having your Python/TypeScript app regex-parse the output.

The Architect Way: You must track the underlying stop_reason field via the Messages API. The loop should cleanly continue while stop_reason == "tool_use" and terminate only when it shifts to "end_turn".

2. Overloading Single Agents with Tools

Giving a single customer support agent 18 different tools degrades its reasoning quality and leads to misrouting (e.g., calling get_customer_data instead of lookup_order because the text descriptions overlap).

The Architect Way: Adhere to the strict rule of keeping 4–5 tools per agent. If you have more requirements, implement a Hub-and-Spoke architecture where a main coordinator agent decomposes the query and dispatches it to isolated, specialized subagents.

3. Prompt-Based Compliance vs. Programmatic Hooks

The exam will present scenarios where sensitive corporate policies must be enforced (e.g., never process a refund greater than $500 without manager approval). A distractor answer will suggest adding this rule to the system prompt.

The Architect Way: Prompts have a non-zero failure rate. Critical business logic must be programmatically enforced using PreToolCall or PostToolUse hooks in the Claude Agent SDK to physically intercept and block unauthorized actions outside the model’s discretion.

How to Practice and Diagnose Your Knowledge

Because this test evaluates your engineering instincts rather than rote memorization, traditional flashcards won't cut it. You need to simulate the cognitive friction of diagnosing real architectural problems.

To help the developer community bridge this gap, I built a completely free diagnostic tool that mimics the style, depth, and scenario-driven nature of the actual Anthropic exam:

🛠️ Test your readiness instantly: claudeCertifiedArchitects.com

A Recommended Study Strategy

If you want to clear the 720/1000 passing score threshold on your first try, structure your prep like this:

Read the Community Guide: Clone the community-driven study resources on GitHub to understand the primitives of the Model Context Protocol (MCP) and the Agent SDK lifecycle hooks.
Take the Diagnostic: Go to claudeCertifiedArchitects.com to uncover your hidden blind spots. Do you actually know how context passing changes when spawning subagents via the Task tool? The diagnostic will tell you.
Build a Tool Failure Loop: Don't just read about error handling. Write a small script where an MCP tool deliberately returns an error, and practice structuring the response metadata (isRetryable, errorCategory) so a coordinator agent can intercept it gracefully without crashing your loop.

Building systems with Claude is incredibly rewarding, but enterprise applications demand deterministic guardrails. Earning your certification proves you know exactly where to draw the line between software engineering logic and model intelligence. Good luck!

The 5 things the Claude Certified Architect exam actually tests (and the gotchas)

Josh — Mon, 08 Jun 2026 07:26:32 +0000

Anthropic's Claude Certified Architect – Foundations exam is scenario-based: 60 questions, 120 minutes, 720/1,000 to pass. It's not an "AI literacy" badge — it tests production judgment. Here's the domain breakdown and the specific traps in each.

Agentic Architecture & Orchestration — 27%
The biggest domain. The agentic loop is simple in principle: stop_reason: "tool_use" means execute the tools and loop back; stop_reason: "end_turn" means stop. The trap is anything else — checking for "done" in the assistant's text, or capping at N iterations as your primary control. A hard cap is a safety net, not the signal.
Claude Code Configuration & Workflows — 20%
Lots of CLAUDE.md and CI/CD. A favorite gotcha: a Claude Code job in CI hangs forever because it was launched without -p. Without the print flag it starts an interactive session and waits on stdin that never comes. -p runs headless: process, print to stdout, exit.
Prompt Engineering & Structured Output — 20%
Few-shot patterns, JSON schemas, output validation. The exam assumes you can prompt; it tests whether you can make output reliable.
Tool Design & MCP Integration — 18%
Tool descriptions, MCP servers, error handling. Key principle: when a tool fails, return a structured error the model can read and recover from — don't throw and kill the loop, and don't return an empty string it'll silently misread.
Context Management & Reliability — 15%
Long sessions, escalation, provenance, and a subtle one: the same Claude instance that generated code will rationalize its own decisions when asked to review them — an independent instance catches more.

How to prep: figure out your weak domain first. I put together a free, no-signup diagnostic that scores you across all five in ~10 minutes: https://www.claudecertifiedarchitects.com/

Independent study resource — not affiliated with or endorsed by Anthropic. Verify current exam details against the official guide before you sit it.