DEV Community: Josh

CCAR-F in a Job Interview: Turning Exam Prep Into Answers

Josh — Wed, 28 Oct 2026 06:11:32 +0000

A credential gets your resume a second look. The interview is where you show what it stands for. For the Claude Certified Architect Foundations exam (CCAR-F), that is good news: Section 1 of the exam guide (CCAR-F) says the exam validates that you can make informed decisions about tradeoffs when implementing real-world solutions with Claude. That is close to what a technical interview for a role building with Claude sets out to test. The preparation you did for one can carry you through the other, if you turn it into answers you can say out loud.

Know where the line is first

Before you talk about the exam at all, know what you can share. Section 14 of the guide (CCAR-F) is a confidentiality agreement: everything on the exam, including questions, answer options and scenarios, is confidential, and you agree not to disclose any of it. Section 13 adds that disclosing exam content can lead to revocation of your credential.

What you can discuss freely is everything the guide publishes: the five domains and their weights, the task statements in Section 6, and the format. That is plenty. Our guide to listing the credential covers what to say when an interviewer asks what was on the exam, and the short version is to talk about the kind of decisions it tested, then move straight to one you made in your own work.

Expect judgment questions, not trivia

An interviewer can look up any configuration flag. What they cannot look up is how you choose between two reasonable designs. That is also how the exam is built: Section 1 describes questions grounded in realistic scenarios that require practical judgment about architecture, configuration and tradeoffs in production deployments. In a realistic hiring pipeline, the technical screen and the system design round are where that judgment gets tested.

So prepare answers that follow one shape: the situation, the options you weighed, the one you chose, and what you gave up. A choice with no alternative named sounds like a guess. A choice with a cost named sounds like experience.

Turn each domain into one story

Section 4 of the guide (CCAR-F) splits the exam into five weighted domains. Prepare one story for each, drawn from something you have built. Here is a prompt to practice against for each domain, and what a strong answer shows.

Agentic Architecture and Orchestration (27%)

Practice prompt: "Walk me through an agent you built. What did the model decide, and what did your code enforce?"

A strong answer separates the two clearly. Section 6 lists the distinction between programmatic enforcement, such as hooks and prerequisite gates, and prompt-based guidance, and it notes that prompt instructions alone have a non-zero failure rate. If you can explain why one rule in your system had to be a hard check while another could live in the prompt, you are showing exactly the judgment this domain tests. Our breakdown of the guarantee or accuracy question type gives you a clean way to frame that choice.

Tool Design and MCP Integration (18%)

Practice prompt: "How do you design a tool so an agent uses it correctly?"

Talk about descriptions and errors. Section 6 treats tool descriptions as the primary mechanism a model uses to choose between tools, and it lists structured error responses that tell the agent whether a failure is worth retrying. An answer that covers both, with an example of a description you rewrote or an error you made machine-readable, stands out. The case for tool errors written for the model makes a good talking point.

Claude Code Configuration and Workflows (20%)

Practice prompt: "How would you set up Claude Code for a team of ten developers?"

The strong answer is about scope: what belongs in shared, version-controlled configuration, what stays personal, and how conventions reach the right files. Section 6 covers the CLAUDE.md hierarchy, path-specific rules, project-scoped commands and skills, and when to use plan mode instead of direct execution. Mention one problem you solved with that structure, such as a convention that was not reaching a teammate, and you have a story.

Prompt Engineering and Structured Output (20%)

Practice prompt: "An automated review is flagging too many false positives. What do you change?"

Interviewers want to hear that you would replace vague instructions with explicit criteria, not ask the model to be more careful. Section 6 says general instructions like "be conservative" fail to improve precision compared with specific categorical criteria, and it adds few-shot examples and schema-validated output through tool use. If you have ever tightened a prompt and measured the result, lead with the measurement.

Context Management and Reliability (15%)

Practice prompt: "How do you keep a long-running agent from losing important details?"

A strong answer names a concrete technique. Section 6 lists keeping transactional facts in a persistent block outside summarized history, trimming verbose tool output before it fills the context, and using scratchpad files across long sessions. Pair one of those with the failure it prevented in your own work.

Practice the system design round out loud

Section 5 of the guide (CCAR-F) publishes six production contexts the exam draws on, including a customer support agent, a multi-agent research system, Claude Code in a CI/CD pipeline and a structured data extraction system. Those published descriptions make good practice prompts for a design interview, as long as you work from the guide's own summaries and nothing you saw on exam day.

Pick one, set a timer for 30 minutes, and design it out loud: the components, where the model makes decisions, where code enforces rules, how errors flow, and when a person gets involved. Record yourself once. Most people discover they skip the "what I gave up" part, and that is the part interviewers remember.

Bring the evidence

Every story above lands harder with something to show. Section 2 of the guide (CCAR-F) describes the typical candidate as having 6+ months of practical experience building with the Claude APIs, Agent SDK, Claude Code and MCP, and an interviewer will want to see that experience. A small, finished repository you can open on screen does more than any description. If you have one, follow the steps for turning your prep into a portfolio project so it is ready to walk through. If you are coming from a developer background, it helps to know what your existing experience already covers so you can connect old work to new skills.

If you have not passed yet

You can still bring it up. Say that you are preparing for the CCAR-F and when your exam is scheduled. Never say "certified" before you are. Then use the domain stories above anyway: an interviewer cares more about how you think than about the badge.

Sharpen your answers with timed practice

The exam gives you 120 minutes for 60 items, two minutes each, which forces you to commit to an answer with a reason. That is the same habit an interview rewards. Start with the free diagnostic, which breaks your results down by domain, and build your first story around your weakest one. Then, before your interview loop, take a full 60-question mock exam under the 120-minute limit. After each wrong answer, say out loud why the right option beats the one you picked. That is interview practice in disguise.

I built a CCDV-F practice bank: 3 free questions inside

Josh — Fri, 23 Oct 2026 15:57:02 +0000

The Claude Certified Developer, Foundations exam (CCDV-F) is Anthropic's certification for people who build, integrate and ship applications with Claude. Section 5 of the exam guide sets the shape: 53 items in 120 minutes, a mix of multiple-choice and multiple-response, and a scaled passing score of 720 out of 1,000. Section 6 spreads those items across eight domains and 25 weighted skills.

I run an independent practice site for Anthropic's certification exams, and this month I built a 500-question bank for the CCDV-F. Below are three questions from its free sample, each with the full explanation, so you can judge the style before you spend anything. They are written from the published exam guide. They are not copies of exam content, and the site is not affiliated with Anthropic.

Question 1: Model Selection and Optimization (16.8%)

A team wants token-by-token output from the Messages API and starts writing a WebSocket client for the API host, reasoning that streaming needs a persistent two-way socket. Before investing further, the lead checks how the API actually streams a response. What does the streaming documentation describe?

A. Streaming is delivered on the HTTP response as server-sent events, each carrying a named event type and JSON data.
B. Streaming is negotiated by upgrading the HTTP connection to a WebSocket, after which events arrive as binary frames.
C. Streaming is delivered by repeated HTTP polling of a message resource, with each poll returning the text generated so far.
D. Streaming is available through the SDKs alone, which hold a private channel to the API that raw HTTP clients cannot use.

Show the answer

Correct answer: A. The streaming page says each server-sent event includes a named event type and associated JSON data, that each event uses an SSE event name such as message_stop and includes the matching event type in its data, and that the SDK's stream call keeps the HTTP connection alive with server-sent events; the versioning page records the current format as named server-sent events.

Why a WebSocket upgrade is wrong: the page describes server-sent events on the HTTP response, and MDN describes WebSockets as a separate API for two-way sessions.
Why polling is wrong: the page describes events arriving on one kept-alive HTTP connection.
Why SDK-only is wrong: the page describes the SDK helper as keeping the same HTTP connection alive with server-sent events, the mechanism any HTTP client receives.

Question 2: Agents and Workflows (14.7%)

A lead research agent spawns subagents for every query. For a simple fact lookup it has spawned dozens of subagents and burned a large budget, while complex comparisons sometimes get a single under-resourced subagent. The team asks what Anthropic's write-up of its multi-agent research system did about this. What did it do?

A. Fixed the subagent count at three for every query, since the write-up found a constant fan-out the one workable way to bound spend.
B. Removed the subagents and ran every query through a single agent, since the write-up found that parallel agents rarely pay off.
C. Let the subagents negotiate the fan-out among themselves, since the write-up found that a lead agent cannot judge complexity.
D. Embedded effort-scaling rules in the prompt: one agent with a few calls for simple facts, many subagents for complex research.

Show the answer

Correct answer: D. Anthropic's write-up of its multi-agent research system says early agents made errors like spawning 50 subagents for simple queries, that agents struggle to judge appropriate effort for different tasks so the team embedded scaling rules in the prompts, with simple fact-finding requiring one agent with 3 to 10 tool calls, direct comparisons 2 to 4 subagents with 10 to 15 calls each, and complex research more than 10 subagents with clearly divided responsibilities, and that these explicit guidelines help the lead agent allocate resources and prevent overinvestment in simple queries.

Why a fixed count is wrong: the write-up scales the count to query complexity.
Why dropping subagents is wrong: the write-up reports the multi-agent system outperforming a single agent on its research evaluation.
Why self-negotiation is wrong: the write-up has the lead agent allocate resources using rules embedded in its prompt.

Question 3: Prompt and Context Engineering (11.0%), multiple response

An architect reviews an agent whose designers load every document that might be relevant into the context at the start of each task, on the grounds that the model has a million-token window. Results get worse as tasks grow longer. Which two statements reflect Anthropic's guidance on context engineering? (Select 2.)

A. Good context engineering means finding the smallest set of high-signal tokens that makes the desired outcome most likely.
B. A larger window removes the need to curate, since recall stays constant across the whole window on current models.
C. Context should be loaded in full at the start of a task, since retrieving data during the task interrupts the model's reasoning.
D. As the number of tokens in the context grows, the model's ability to recall information from that context accurately drops.
E. Sub-agents should be avoided for long tasks, since splitting work across context windows loses the shared state.

Show the answer

Correct answers: A, D. Anthropic's engineering article on effective context engineering says that because LLMs are constrained by a finite attention budget, good context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome, that needle-in-a-haystack benchmarking has uncovered context rot, where the model's ability to accurately recall information decreases as the number of tokens in the context window increases, so context must be treated as a finite resource with diminishing returns, that just-in-time strategies keep lightweight identifiers and load data dynamically rather than pre-processing everything up front, and that sub-agent architectures let specialized sub-agents handle focused tasks with clean context windows.

Why constant recall is wrong: the article describes context rot across all models.
Why loading everything up front is wrong: the article describes just-in-time retrieval as the agentic approach.
Why avoiding sub-agents is wrong: the article presents sub-agent architectures as a way around context limitations.

Three things worth knowing from the exam guide

Applications and Integration is a third of the exam. At 33.1%, it is the largest of the eight domains, and a good part of it is general software engineering: REST APIs, JSON, asynchronous programming, version control and code review. Working developers start ahead here.

Claude Code's 3.1% is misleading. CLAUDE.md and settings.json also appear under Configuration Management inside Applications and Integration, so skipping Claude Code costs more than the weight suggests.

Multiple-response items need a different habit. Each item states how many responses to select, and the guide does not describe partial credit. Judge every option as true or false for the situation, and pick exactly the number asked for.

Try more

The free Quick Sprint gives you 10 questions from the free sample, with no account needed. The full CCDV-F practice bank has 500 questions across all eight domains, every one explaining the correct answer and why each other option is wrong, plus a full 53-question mock exam in 120 minutes. It's a one-time $69, with a 10-day money-back guarantee.

If you're still deciding between the developer and architect exams, here's how the CCDV-F compares with the CCAR-F.

Which of the eight domains are you least sure about?

How to Prepare for the CCDV-F: A Domain-by-Domain Study Plan

Josh — Thu, 22 Oct 2026 09:06:05 +0000

Most exam guides tell you which domains matter. The Claude Certified Developer Foundations guide (CCDV-F) goes further: Section 6 assigns a weight to each of 25 individual skills. That turns the blueprint into something more useful than a list of topics. It tells you where the points are, which skills you probably already have, and how to split your study time. This guide turns those weights into a four-week plan. If you are still deciding between exams, start with how the CCDV-F compares with the Architect exam.

Start with the format

Section 5 of the exam guide (CCDV-F) sets out the basics:

53 items in 120 minutes, which works out to about 2 minutes 15 seconds per item.
Multiple-choice and multiple-response items. Each item states how many responses to select.
A scaled passing score of 720 on a scale of 100 to 1,000.
Proctored delivery, online or at a test center.

The multiple-response format deserves attention early. An item that asks for two answers rewards reading each option on its own merits rather than picking the single best one, and that habit takes practice to build.

Where the points are

Section 6 of the guide (CCDV-F) gives each domain an approximate share of the scored items:

Applications and Integration: 33.1%
Model Selection and Optimization: 16.8%
Agents and Workflows: 14.7%
Prompt and Context Engineering: 11.0%
Tools and MCPs: 10.6%
Security and Safety: 8.1%
Claude Code: 3.1%
Eval, Testing, and Debugging: 2.6%

The top three domains add up to 64.6%, nearly two-thirds of the exam. The bottom two add up to 5.7%. As a rough guide, 33.1% of 53 items is about 17 or 18 questions, while 2.6% is one or two. The guide describes its weights as approximate shares of scored items and does not say how many of the 53 are scored, so treat those counts as estimates, not a promise.

One trap is worth flagging. Claude Code carries only 3.1% as a domain, but Claude Code topics also appear elsewhere. The Configuration Management skill under Applications and Integration covers CLAUDE.md files, settings.json, model version pinning and plugin dependencies. Low domain weight does not mean you can skip the tool.

About a fifth of the exam is general engineering

Four of the 25 skills describe software engineering that is not specific to Claude:

Software Engineering Foundations (7.4%): REST APIs, JSON, asynchronous programming, version control, code review and refactoring.
Technical Fundamentals (6.1%): basic engineering practices such as integrating with SDKs that wrap REST APIs, and websockets.
Understanding Requirements (3.4%): functional and infrastructure requirements based on business requirements and solution architecture.
Systems Life Cycle (2.8%): the frameworks used to develop, run and maintain IT systems.

Together that is 19.7% of the exam. For working developers, this is a head start: these are skills you use every week. For career changers, it is a warning. Section 4 of the guide (CCDV-F) recommends one to five years of software engineering experience, proficiency in Python or TypeScript, and fluency with REST APIs and command line tools. None of that is a formal prerequisite, but a fifth of the exam assumes it.

The six skills that matter most

Sorted by weight, the six largest skills account for 39.4% of the exam on their own:

Claude Application Design (8.6%): how Claude interprets instructions across Claude Code, Desktop, claude.ai, the API and SDKs, plus content boundaries, schema design, session hygiene and plugin management.
Software Engineering Foundations (7.4%).
Claude API Mechanics (6.8%): messages, tools, streaming, vision, thinking, caching, batch use, and choosing between realtime and batch requests.
Technical Fundamentals (6.1%).
Agent Construction with Claude (5.3%): the Claude Agent SDK, custom agent loops and harnesses, self-hosted versus Anthropic-hosted deployment, and hooks for deterministic actions.
LLM Fundamentals (5.2%): tokens, context windows, sampling, non-determinism, model options such as extended thinking and effort levels, and zero-shot to multi-shot prompting.

If your time is short, these six come first.

A four-week plan

This plan assumes the background Section 4 recommends, including at least six months of hands-on work with Claude or a comparable LLM system. Each week groups related skills and carries roughly a quarter of the exam's weight.

Week 1: Building on the API (19.5%)

Claude API Mechanics, Claude Application Design and Configuration Management. Work directly against the Messages API: streaming, tool use, vision input and prompt caching. Decide when a job belongs in the batch API rather than realtime calls. Set up a CLAUDE.md file and settings.json for a real repository, and pin a model version so you can explain why that matters.

Week 2: Models, tokens and context (27.8%)

All of Model Selection and Optimization (16.8%) and Prompt and Context Engineering (11.0%). Compare model tiers on the same task for quality, latency and cost. Track token usage and model the cost of a workload, with and without caching. Then practice the prompt side: clear instructions, few-shot examples, system versus user placement, and managing a growing context window through pruning and compaction. Finish with output handling: validate structured output and parse defensively instead of trusting a confident answer.

Week 3: Agents and tools (25.3%)

Agents and Workflows (14.7%) and Tools and MCPs (10.6%). Learn when a fixed workflow beats an agent, and how supervisor hierarchies and subagents divide a task. Build a custom tool with a precise description and real error handling; the case for tool error messages written for the model applies directly here. Write a small MCP server and review the common MCP server design mistakes before you do. The Agentic Customization skill (4.1%) asks you to choose between built-in tools, custom tools, Skills and MCP servers, so practice explaining that choice for a given use case.

Week 4: Security, the small domains, and a full mock (27.4%)

Security and Safety (8.1%), Claude Code (3.1%), debugging (2.6%), and the general engineering skills under Applications and Integration (13.6%). On security, work through the AI Application Security skill as Section 6 describes it: prompt injection awareness and mitigation, jailbreak defense, untrusted input handling, data leakage prevention and PII handling. Then cover the Claude Hooks skill, which the guide frames as using hooks for guardrails that prevent destructive actions, and review how you manage secrets and API keys across development and production. For debugging, practice telling an integration-layer failure apart from a model-output failure by reading traces. Then take a full timed mock and review every miss by skill, not just by domain.

Build one thing that covers the blueprint

Section 7 of the guide (CCDV-F) recommends building and operating at least one Claude application that exercises the API, integrates one or more tools, applies basic prompt and context engineering, and includes simple security and evaluation practices. The four weeks above map onto that build: the API layer in week 1, model and prompt decisions in week 2, tools and an agent loop in week 3, guardrails and tests in week 4.

Building also gives you something to show. A finished, well-documented repository is evidence for an employer in a way a score report is not, and the steps for turning a study build into a portfolio project apply to either exam.

Practice the format, not just the content

Section 7 also points to the guide's sample questions in Section 8 for item style. Those are few, and they are illustrative rather than drawn from the live bank. For volume, our CCDV-F practice questions cover all eight domains, including a full 53-question mock under the 120-minute limit, and each explanation covers why every other option is wrong. Use them in two ways: short domain drills during the four weeks, and the timed mock at the end. When a timed mock goes badly, look at which skills the misses cluster in before rereading anything.

Before and after exam day

Eligibility and cost: registration currently runs through organizations in the Claude Partner Network, and our guide to getting your employer to pay explains who can register and how partner discounts work.
Scheduling: under Section 10 of the guide (CCDV-F), you register through Anthropic Partner Academy and schedule with Pearson VUE. You can cancel or reschedule up to 24 hours before your appointment.
On the day: the ID, workspace and conduct rules in Sections 11 and 12 match the Architect exam's, so our walkthrough of exam-day logistics, from ID checks to online proctoring applies.
If you don't pass: Section 11 sets waiting periods of 14, 30 and 90 days after the first three failed attempts, and up to four attempts in a rolling 12 months. See how retakes and waiting periods work.
After you pass: under Section 14, the credential is valid for 12 months and on-time renewal is a free, non-proctored assessment. Our guide to how the free renewal works covers the same process for the Architect credential.

Where to start

Read Section 6 of the guide once, end to end, and mark each of the 25 skills as strong, partial or new. Put the new and partial skills from the top six into week 1 or 2, whatever the plan above says. The weights tell you where the points are; your own gaps tell you where the work is.

FAQ

How many questions are on the CCDV-F exam?
Section 5 of the exam guide (CCDV-F) lists 53 items in 120 minutes, a mix of multiple-choice and multiple-response items. Each item states how many responses to select. The passing score is a scaled 720 on a scale of 100 to 1,000.

Which CCDV-F domains carry the most weight?
Under Section 6 of the guide (CCDV-F), Applications and Integration carries 33.1%, Model Selection and Optimization 16.8%, and Agents and Workflows 14.7%. Together those three domains are 64.6% of the exam.

How much of the CCDV-F is about Claude Code?
The Claude Code domain is weighted at 3.1% in Section 6 of the guide (CCDV-F). Claude Code topics also appear under Configuration Management, which covers CLAUDE.md files, settings.json and plugin dependencies, so the tool matters more than the domain weight suggests.

Do I need experience before taking the CCDV-F?
There are no mandatory prerequisites. Section 4 of the guide (CCDV-F) recommends one to five years of software engineering experience, at least six months of hands-on work with Claude or a comparable LLM system, proficiency in Python or TypeScript, and fluency with REST APIs and command line tools.

CCAO-F vs CCAR-F: which Claude certification should you take?

Josh — Mon, 19 Oct 2026 12:04:30 +0000

Anthropic's certification program publishes more than one Foundations exam, and the codes sit one character apart. CCAO-F is the Claude Certified Associate – 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.

They are not two tiers of one test. They are aimed at different people doing different work, and the published exam guides say so directly. This article sets the two side by side using only what those guides state, so you can work out which one you are actually preparing for.

The short answer

If you use Claude as a productivity tool (drafting, analysis, research, process work), the Associate exam is the one written for you. If you build with Claude (agentic systems, tool integrations, production pipelines), the Architect exam is. Both guides draw that line, and they draw it in the same place.

What each credential says it validates

The Claude Certified Associate – Foundations guide opens (Section 1) by describing a credential that validates applying Claude to complete business and productivity tasks with minimal guidance: using built-in platform features and tools to streamline workflows, identifying opportunities to improve processes, selecting approaches that balance quality against efficiency and cost, and recognizing limitations well enough to escalate more complex or technical work.

The Claude Certified Architect – Foundations guide describes something different in its own Section 1: foundational knowledge across Claude Code, the Claude Agent SDK, the Claude API and the Model Context Protocol, with questions grounded in production contexts such as customer-support agents, multi-agent research pipelines and CI/CD integrations. Its Section 2 sets out an ideal candidate who is a solution architect, typically with six or more months of practical experience building against those technologies.

The audience distinction is the whole story

Section 3 of the Associate guide is unusually direct about who the exam is not for. It names software developers who build against APIs or design agentic systems, alongside specialists in machine learning, software engineering and advanced AI system design, and states that candidates are not expected to design enterprise-scale AI architectures or integrations. Then it says where that work belongs: "that scope belongs to the Claude Architect and Claude Developer credentials", to which Associates escalate more complex work.

That is the clearest signal either document gives, and it comes from the Associate guide itself rather than from us. The Associate exam is written for professionals in operations, marketing, project management, education, communications and general knowledge work: both internal staff who maintain AI-enabled workflows and external consultants who support implementation and process redesign. Section 3 places them between casual prompt users and technical AI practitioners, expecting limited to moderate technical expertise.

So if you are writing the integration rather than using it, the Associate guide is pointing you at the Architect exam. Our longer piece on which roles the Architect certification actually fits works through that question from the other direction.

Where the two exams are identical

This is the part that surprises people. Almost every mechanical detail matches.

Detail	CCAO-F (Associate)	CCAR-F (Architect)
Number of items	60	60
Time limit	120 minutes	120 minutes
Item format	Multiple-choice and multiple-response; each item states how many responses to select	Multiple-choice and multiple-response; each item states how many responses to select
Passing score	Scaled score of 720 on a scale of 100–1,000	Scaled score of 720 on a scale of 100–1,000
Delivery	Proctored: online and/or test center	Proctored: online and/or test center
Validity	12 months from the date awarded	12 months from the date awarded
Content domains	7	5
Exam fee	$99 USD	$125 USD

Sixty items, two hours, and the same scaled score of 720 on a 100–1,000 range. Both guides state the item format in identical words, and neither guide says what proportion of items takes each form, a point worth holding onto, because it is easy to assume otherwise. We wrote about what multiple-response actually means for how you answer when the Architect guide's wording raised the same question.

Both exams also report results the same way: a pass or fail with a scaled score, plus percent-correct by content domain, with the section-level percentages explicitly not used to determine the outcome. Both are criterion-referenced assessments, so you are measured against a fixed performance standard rather than against other candidates.

The policies match as well. Registration and scheduling for both run through the Anthropic Partner Academy and Pearson VUE. Both credentials renew through a free, non-proctored assessment on the Partner Academy, and a lapsed credential means retaking the full exam at the full fee. Both set the same waiting periods after a failed attempt: fourteen days after the first, thirty after the second, ninety after the third. There is a maximum of four attempts in a rolling twelve-month period, with the fee payable on each one. Both guides add that these limits apply per exam, so not passing one does not stop you registering for the other.

Where they genuinely differ

The fee

The Associate exam is $99 USD, from Section 5 of its guide. The Architect exam is $125 USD, from Section 3 of its own. That is the only figure in the two at-a-glance tables that differs.

The blueprint

The Associate exam draws from seven content domains; the Architect exam from five. The subject matter barely overlaps, which is the audience distinction expressed as a syllabus.

The Associate blueprint (Section 6) weights its seven domains like this:

CCAO-F content domain	Weight
Prompting and Task Execution	14%
Output Evaluation and Validation	21%
Product and Model Selection	12%
Workflow Integration and Solution Design	16%
Configuration and Knowledge Management	12%
Governance, Risk, and Responsible Use	15%
Troubleshooting and Optimization	10%

The heaviest single domain is Output Evaluation and Validation at 21%: judging whether what Claude produced is accurate and complete, identifying hallucinations and bias, and determining when human review is required. Add Governance, Risk, and Responsible Use at 15% and more than a third of the Associate exam turns on judgment about output and appropriate use rather than on construction.

The Architect blueprint (Section 4) is five domains, and they are engineering subjects:

CCAR-F content domain	Weight
Agentic Architecture & Orchestration	27%
Tool Design & MCP Integration	18%
Claude Code Configuration & Workflows	20%
Prompt Engineering & Structured Output	20%
Context Management & Reliability	15%

Agentic Architecture & Orchestration alone is 27%, covering agentic loops, coordinator-subagent patterns and subagent context passing. No Associate domain corresponds to it. We break down the five Architect domains and what each one weighs in a separate post.

Prompting appears on both blueprints, and it is the one place they touch. Even there the framing differs: the Associate guide's Domain 1 is about creating effective prompts, decomposing tasks and iterating to improve output quality, while the Architect guide's Prompt Engineering & Structured Output domain runs to JSON schemas, structured output via tool use, and extraction patterns.

Exam structure

The Architect guide specifies its structure in Section 3 and expands on it in Section 5: four scenarios drawn from a bank of six, presented at random, each framing a set of questions around a production context such as a customer-support resolution agent or a CI/CD integration. The Associate guide's at-a-glance table carries no equivalent exam-structure row.

How to choose

A few questions that follow directly from the guides:

Do you write code that calls Claude? If yes, the Architect exam is the one aimed at you. If no, the Associate guide has explicitly told you its exam is not.
Is your day mostly building or mostly using? Configuring a Claude Project with instructions and knowledge sources is Associate territory. Designing a coordinator-subagent system is Architect territory.
Do you have hands-on time with the Agent SDK, Claude Code or MCP? The Architect guide's Section 2 assumes roughly six months or more of it. The Associate guide's Section 4 states there are no mandatory prerequisites or required courses, and that no software-development or API experience is needed.
Are you weighing cost against effort? The fee gap is $26, which is small next to the preparation each demands. Our assessment of whether the Architect certification is worth taking covers that trade-off, and how demanding the Architect exam actually is covers the preparation side.

Nothing in either guide ranks one credential above the other, and neither describes one as a prerequisite for the other. They describe different scopes of work. The Associate guide's own escalation language, in which Associates hand more complex or technical work to Architects and Developers, describes a division of labor rather than a ladder.

How to Get Your Employer to Pay for the CCAR-F

Josh — Sat, 10 Oct 2026 12:57:40 +0000

The Claude Certified Architect Foundations exam (CCAR-F) costs $125 per attempt. For candidates at partner companies, that fee doesn't have to come out of their own pocket. The certification is built around employers, and the employers who can register you have a concrete reason to want you certified. This guide covers who can ask, what the exam really costs a company, and how to make the request.

First, check that your employer can register you

Anthropic's certification FAQ is clear about who can take the exam: certification is currently available only to people at organizations in the Claude Partner Network, and registration requires a work email on a company domain Anthropic recognizes. A personal address such as Gmail will not work.

That rule shapes everything that follows. If your company is in the network, it can register you, and it has its own reasons to pay. If it isn't, nobody can register you yet, so the conversation starts somewhere else (covered at the end of this guide). For the registration steps themselves, see our page on how to register for the exam.

Why your employer has a reason to say yes

According to the FAQ, certification counts toward a firm's standing in the Claude Partner Network. Not every Claude exam does: the Developer Foundations, Architect Foundations and Architect Professional exams count toward partner eligibility, while the Associate exam does not. The CCAR-F is one of the three that count.

The FAQ also says certification signals to customers that a team has invested in a real Claude practice, and that the Partner Portal shows each organization its total number of certifications, updated weekly. In other words, your certificate is visible to the people who manage the partnership. That is the core of your case: you aren't asking for a personal perk, you're offering to add to something the company is already measured on.

What it actually costs them

Section 3 of the exam guide (CCAR-F) lists the exam fee as $125. But companies often pay less. The FAQ sets discounts by partner tier:

Registered tier: full price, $125.
Select, Preferred and Global Premier tiers: 50% off, applied automatically at checkout, so $62.50.
Global Premier, through December 31, 2026: a 100% discount on all certification exams. After that date, the standard 50% applies.

So depending on your company's tier, your exam may cost it $125, $62.50, or nothing at all this year. Section 11 of the guide (CCAR-F) confirms that the fee shown at checkout reflects any discount for your partner tier. Find out your tier before you ask; it changes the conversation. Our breakdown of the full cost of the CCA exam covers the rest of the numbers.

Two more costs belong in your request. A retake is charged at the full exam fee, though the FAQ says the partner discount applies to retakes too, and Section 12 of the guide (CCAR-F) sets a 14-day wait after a first failed attempt. And the credential lasts 12 months: under Section 15 of the guide (CCAR-F), on-time renewal is free, but a lapsed credential means retaking the full exam at the full fee.

How to make the ask

Start by finding the right person. In most partner companies, someone owns the Anthropic relationship: a partner or alliances manager, a practice lead, or the person who handles training budgets. They will know your tier and whether certifications are already being tracked.

Then keep the request short and specific. A good request covers five things:

What you want to take: the Claude Certified Architect Foundations exam, CCAR-F.
Why it helps the company: it counts toward the firm's Claude Partner Network standing.
What it costs: the fee at your tier, plus your plan if a retake is needed.
When: a target date, so the request has a deadline.
How you'll prepare: a short study plan, so they know the money isn't spent on a guess.

Here is a template you can adapt:

Hi [name],

I'd like to take the Claude Certified Architect Foundations exam (CCAR-F). Because we're in the Claude Partner Network, the certification counts toward our standing in the network, and it shows up in our certification count on the Partner Portal.

The fee is $125, or [$62.50 / nothing] at our partner tier. I'm planning to take it by [date], and I have a study plan covering the five exam domains. Could the company cover the exam fee? I'd also like to ask about [study time / a prep budget].

Thanks,

[your name]

Ask for the whole package, not just the fee

The fee is the smallest part of passing. While you have the conversation open, ask about three other things.

Time on real work. Section 2 of the guide (CCAR-F) describes the typical candidate as having 6+ months of practical experience building with the Claude APIs, Agent SDK, Claude Code and MCP. If you're short on that, the most valuable thing your employer can give you is time on a project that uses them.

A retake agreement. Agree in advance who pays if the first attempt doesn't pass. It's an easier conversation before the exam than after it. Our guide to the retake policy, cost and wait times has the details.

Practice materials. The FAQ notes that the practice exam on Anthropic's previous platform was retired in the move to Pearson, and that the exam guide's sample questions show the format. Partner Academy also offers prep courses, which vary by certification. If you want full-length practice under exam conditions, include a practice question bank in your request; it costs less than a full-price retake.

Before you register: the practical details

Payment: the FAQ says the exam is paid by credit card through Anthropic Partner Academy. Bulk vouchers for teams are in progress but not available yet, so plan on a company card or an expense claim, and check your expense policy first.
Your email domain: if registration doesn't accept your work email, your domain may not be on the company's partner record. The FAQ says to email partner-support@anthropic.com, and that adding a domain takes 7 to 10 days, so ask well before your exam date.
Keeping your badge: certificates are issued through Credly. The FAQ recommends adding a personal email to your Credly profile so you keep access to your badge if you change jobs.
Renewal: put the 12-month date in your calendar now. Our guide to renewing the CCAR-F credential explains how the free renewal works.

If your employer isn't in the network

The FAQ states that certification is currently available only to organizations in the Claude Partner Network, so an individual can't register on their own. If your company works with Claude but isn't a partner, the person to talk to is whoever owns that relationship, since organizations, not individuals, join the network. Until then, you can still build the skills the exam covers.

Where to start

Find out whether your company is a partner and at which tier, then send a short, specific request with a date and a plan. And when you've passed, make it count: our guide to adding the CCAR-F to your resume and LinkedIn covers how to show it.

Turn Your CCAR-F Prep Into a Portfolio Project

Josh — Sun, 04 Oct 2026 17:47:23 +0000

If you're working toward the Claude Certified Architect Foundations credential (CCAR-F) as a step into AI work, you'll eventually face two questions. The exam asks whether you can make sound architecture decisions with Claude. People you want to work with ask a simpler one: what have you built?

A credential tells people you passed an exam. A project shows them how you think. The good news is that you don't have to choose between preparing for one and building the other.

Why build while you study

Section 1 of the exam guide (CCAR-F) says the exam tests informed decisions about tradeoffs, grounded in realistic production scenarios. Section 2 (CCAR-F) describes the typical candidate as having six or more months of practical experience building with the Claude APIs, the Agent SDK, Claude Code and MCP.

A project is how you get that experience, and it leaves you with evidence. The guide also recommends hands-on preparation exercises in Section 8 (CCAR-F), and it's worth working through them in your own copy. This article is about going one step further: a project of your own design, built in public.

Choose a project from your own world

The strongest portfolio project solves a problem you understand. If you've spent years in a field, build for it. Here are three shapes that work well, each touching several exam domains:

An assistant that uses tools for a workflow you know. For example, one that reads meeting notes, pulls out the action items and creates tasks in a tracker, asking a person when an owner or deadline is unclear. This exercises Agentic Architecture & Orchestration and Tool Design & MCP Integration.
A pipeline that turns messy documents into structured data, using a document type from your own field: job postings, invoices, lab results or support tickets. This exercises Prompt Engineering & Structured Output and Context Management & Reliability.
A real repository set up so a team can work with Claude Code, with shared instructions, reusable commands, rules for different parts of the codebase, and a step in the CI pipeline. This exercises Claude Code Configuration & Workflows. Our guide to writing an effective CLAUDE.md file is a good place to start.

Then check the choice against your gaps. Take the free diagnostic to see which domains need the most work, and pick the project that exercises them. If you're unsure, favor the first shape: Agentic Architecture & Orchestration is the largest domain on the exam at 27%, and our agentic architecture domain guide covers what it tests.

Making it portfolio-grade

A few habits turn a working demo into something worth showing.

Keep the scope real but small. One workflow, done properly, beats five features done halfway. Pick something a real person could use, and finish it: a finished small project says more than an ambitious one that stalled.

Define "working" with tests. Write down what correct behavior looks like and turn it into tests in the repository, so anyone can see what the project promises and whether it keeps the promise.

Show how it fails. Section 6 (CCAR-F) includes a task statement on structured error responses: a caller needs to know what went wrong and whether trying again makes sense. Design for that, and show it. Our write-up of an agent that retried the same error 11 times shows what happens when you don't.

Measure something. Accuracy on a small test set, cost per run, or time per document. Put the numbers in your README.

Explain your decisions. Since the exam is about tradeoffs, your README should be too: why this tool boundary, why this check runs in code instead of in the prompt, why this field is allowed to be empty. A short "decisions" section often says more than the code.

Keep secrets out. No API keys in the repository, ever. Read credentials from the environment.

Commit as you go. A history of small, clearly described commits shows how you worked, not just where you ended up.

A worked outline: the meeting-notes assistant

Here's how the first shape could look as a finished repository:

The scenario. The assistant reads a meeting transcript, extracts action items, and creates tasks in a tracker. When an owner or a due date is unclear, it asks a person instead of guessing.
Two or three tools, such as creating a task and looking up a team member, each with a description clear enough that the model picks the right one.
Structured output. Every action item comes back as JSON matching a schema, with fields left empty when the transcript doesn't say, so the assistant never invents a deadline.
A rule enforced in code. Tasks can only be assigned to people who were in the meeting, and a hook blocks anything else. Our article on one question type the exam uses explains why enforcing a rule in code differs from asking for it in the prompt.
Errors it can act on. The tracker being briefly unavailable is handled differently from a request the tracker rejects.
A small test set of realistic transcripts, with how many action items the assistant got right.
A README with the scenario, a diagram, the decisions section and the results.

That one project touches four of the five exam domains, and it gives you a concrete answer when someone asks what you've built with Claude.

What it does for your exam prep

Building forces the decisions the exam asks about. Reading that tool descriptions shape which tool a model chooses is one thing. Watching your assistant pick the wrong tool because two descriptions overlap is another, and you won't forget it.

Then check your understanding against exam-style questions. Our 400 practice questions cover all five domains, with an explanation for every answer, so you can see whether what you learned while building transfers to scenarios you haven't seen.

The project also shows you what you haven't practiced. If your build never needed a hook, a schema or a careful tool description, that's the part of the exam to study next.

Showing it off

Pin the repository on your GitHub profile. Add it to the Featured section of your LinkedIn profile, next to the credential once you've passed. On your resume, one bullet describing what you built and one decision you made is enough. Our guide to listing the CCAR-F on your resume and LinkedIn covers the rest.

Then be ready to talk about it. Know the one decision you'd defend and the one thing you'd change with more time. Those two answers turn a link into a conversation.

One rule: keep the project your own. Don't publish the exam guide's sample questions or exercises, and never anything from the exam itself. Anthropic's exam policy treats disclosing exam questions or answers as misconduct, and a portfolio is the last place to risk your credential.

Where to start

If you're a developer, our breakdown of what transfers from software development to the exam will help you spot the domains that will stretch you most. Then pick a workflow you know, write down what "working" means, and build. By exam day you'll have practiced the decisions the project required, and you'll have something to show for it.

FAQ

Do I need a portfolio project to pass the CCAR-F?

No. But the exam tests decisions about tradeoffs in realistic scenarios, according to Section 1 of the exam guide, and building something real is one of the most effective ways to practice making them.

What should my first project be?

Something from a workflow you already know, small enough to finish, that touches two or three exam domains. A tool-using assistant is a good default, since Agentic Architecture & Orchestration is the largest domain at 27%.

Can I publish my project publicly?

Yes, as long as it's your own work. Keep API keys and credentials out of the repository, and don't publish the exam guide's sample questions or exercises, or anything from the exam itself.

Should I also do the exercises in the exam guide?

Yes. Section 8 of the guide recommends hands-on preparation exercises. Work through them in your own copy as practice, then build your own project for your portfolio.

Already a Developer? What Transfers to the CCAR-F Exam

Josh — Wed, 30 Sep 2026 07:27:31 +0000

If you write software for a living and you're looking at a move into AI work, the Claude Certified Architect Foundations exam (CCAR-F) can look like a whole new field to learn. It isn't. A large share of what the exam tests is software engineering applied to a new kind of component: a model that reads your tool descriptions, follows your configuration, and makes decisions inside your system.

This guide walks through the exam's five domains and shows which ones build directly on experience you already have, and which ones will need the most study. Everything here comes from Anthropic's published exam guide, so you can check each point for yourself.

What the exam is looking for

Section 1 of the exam guide (CCAR-F) says the certification validates that practitioners can make informed decisions about tradeoffs when implementing real-world solutions with Claude. Questions are grounded in realistic production scenarios, and candidates need practical judgment about architecture, configuration and tradeoffs, not just conceptual knowledge.

Section 5 (CCAR-F) lists the six scenarios the exam draws from. Each sitting presents four of them at random:

a customer support resolution agent
code generation with Claude Code
a multi-agent research system
developer productivity tools
Claude Code in a CI/CD pipeline
structured data extraction

If you have shipped production software, most of that list will look familiar. Four of the six are the kind of system developers already build, maintain or use every day.

Tool Design & MCP Integration (18%): your API experience, pointed at a new reader

This is the domain where developer experience transfers most directly. Section 6 (CCAR-F) includes task statements on designing tool interfaces with clear descriptions and boundaries, and on implementing structured error responses for MCP tools.

If you have designed an API, you already think in contracts, inputs, boundaries and error codes. The guide makes the same argument you would make in a code review: a uniform "Operation failed" response prevents recovery, and a caller needs to know whether an error is retryable or not.

What changes is who reads your interface. Here the caller is a model. The guide's sample question explanations in Section 9 (CCAR-F) say tool descriptions are the primary mechanism a model uses to choose between tools, so a vague description causes wrong tool selection the way a vague API spec causes integration bugs. Our write-up of an agent that retried the same error 11 times shows what happens when an error message is written for a human instead of a model. The tool design domain guide goes deeper into the domain.

Claude Code Configuration & Workflows (20%): developer tooling you'll recognize

This domain is about setting up Claude Code for a team, and it reads like a developer tooling checklist. Section 6 (CCAR-F) covers CLAUDE.md files with a hierarchy and scoping, custom slash commands and skills, path-specific rules, when to use plan mode instead of direct execution, and integrating Claude Code into CI/CD pipelines.

If you have configured linters, maintained repo conventions or built a CI pipeline, the shape of this work is familiar: shared configuration in version control, rules that apply to some files and not others, automation that runs on every pull request. What you need to learn are the specific mechanisms, such as where each configuration file lives and which one wins when they overlap. The guide's sample questions test exactly that level of detail. Our guide to writing an effective CLAUDE.md file is a practical place to start, and our Claude Code domain guide goes further into the domain.

Agentic Architecture & Orchestration (27%): orchestration you know, with a new decision-maker

This is the largest domain on the exam. Its task statements in Section 6 (CCAR-F) include designing agentic loops, orchestrating multi-agent systems with coordinator and subagent patterns, implementing multi-step workflows with enforcement and handoffs, using hooks to intercept tool calls, and managing session state, resumption and forking.

Developers who have worked on job orchestration, state machines, middleware or distributed services will find the structure familiar. A hook that intercepts a tool call is recognizably an interceptor. Session resumption is recognizably state management.

The new part is that the component making decisions is a model, and a lot of the domain is about deciding what you leave to the model and what you enforce in code. The guide's preparation exercises in Section 8 (CCAR-F) start with building an agentic loop that checks the model's stop reason to decide whether to run another tool call or return a final answer. Our article on one question type the exam uses looks at that line between an instruction and a hook, gate or schema, and the agentic architecture domain guide goes deeper.

Prompt Engineering & Structured Output (20%): the least familiar ground

This is the domain with the least direct precedent in traditional development, so plan to spend real time on it. Section 6 (CCAR-F) covers designing prompts with explicit criteria to reduce false positives, few-shot prompting for consistent output, enforcing structured output through tool use and JSON schemas, validation and retry loops, batch processing, and multi-pass review architectures.

Parts of it will feel familiar. Schema validation and retry logic are ordinary engineering. But writing review criteria precise enough that a model stops flagging false positives, or choosing the two to four examples that teach it how to handle an ambiguous case, are skills most developers haven't needed before. Our prompt engineering domain guide is the place to start.

Context Management & Reliability (15%): half familiar, half new

Section 6 (CCAR-F) covers preserving critical information across long interactions, escalation and ambiguity resolution, error propagation across multi-agent systems, context management during large codebase exploration, human review workflows with confidence calibration, and preserving the source of information when combining findings.

Error propagation and observability will feel like home. Treating the model's context window as a limited resource will not. The guide notes, for example, that models reliably process the beginning and end of long inputs but may miss findings in the middle. Deciding when an agent should hand a case to a human, instead of retrying, is also a new kind of design judgment. Our context management domain guide covers the context side of this domain.

The honest gap: hands-on time with Claude

Your development background is a foundation, not a substitute. Section 2 (CCAR-F) describes the typical candidate as having six or more months of practical experience building with the Claude APIs, the Agent SDK, Claude Code and MCP.

The good news is that the guide tells you how to close that gap. Section 8 (CCAR-F) lists hands-on preparation exercises, including building a multi-tool agent with escalation logic, building a structured data extraction pipeline, and configuring Claude Code for a team development workflow. For a developer, these are the kind of builds you can start this week, and each one covers more than one domain.

Where to start

Start by finding out which of your skills are already exam-ready. The free diagnostic on our site samples all five domains and shows where you stand. Then build: pick one of the Section 8 exercises closest to your gaps and work through it with Claude. When you're ready for full practice, our 400 practice questions cover all five domains with an explanation for every answer.

You're not starting over. You're adding Claude to a set of skills you've already spent years building.

Quick answers

Do I need to be a developer to pass the CCAR-F?
No, but it helps. Section 2 of the exam guide describes the ideal candidate as a solution architect who designs and implements production applications with Claude. Much of the exam draws on software engineering judgment, so developers start with an advantage in several domains.

Which exam domain should developers study first?
Agentic Architecture & Orchestration carries the most weight at 27%. Prompt Engineering & Structured Output has the least direct precedent in traditional development, so it's worth scheduling real study time for it early.

How much Claude experience does the exam expect?
The exam guide describes the typical candidate as having six or more months of practical experience building with the Claude APIs, the Agent SDK, Claude Code and MCP.

Is there a Claude certification aimed at developers?
Anthropic also offers a developer exam, CCDV-F. Our comparison of CCDV-F and CCAR-F sets out how the two differ.

Originally published at claudecertifiedarchitects.com, an independent exam-prep site. Not affiliated with or endorsed by Anthropic.

CCAR-F Renewal: How to Keep Your Claude Certification Active

Josh — Fri, 25 Sep 2026 08:41:41 +0000

Passing the Claude Certified Architect Foundations exam (CCAR-F) is a real achievement, and it comes with a detail that is easy to miss on exam day: the credential does not last forever. It is valid for 12 months, and keeping it active is up to you.

The good news is that renewal is designed to be easy for anyone who stays on schedule. On-time renewal is free and is not proctored. The only expensive outcome is letting the deadline pass. This guide covers what Anthropic has published about renewal, what it has not published yet, and the simple steps that keep your credential active.

The 12-month rule

Section 15 of the exam guide (CCAR-F) states that the credential is valid for 12 months from the date it is awarded. The guide gives the reason directly: the underlying technology changes quickly, so the credential is time-limited to keep holders current.

That is worth seeing as a strength, not a catch. A certification that has to be renewed tells an employer something a permanent one cannot: that your knowledge was checked recently. Cloud and security certifications have worked this way for years. An active CCAR-F badge says you know how Claude works today, not how it worked when you first passed.

When your clock started

Your 12 months run from the date you earned the credential. Anthropic's certification FAQ on the Partner Academy uses exactly that wording.

If you certified early, there is one more detail. The program originally used a 6-month validity period. According to the same FAQ, every certification earned before June 30, 2026 was extended automatically to 12 months from its original earned date. You do not need to do anything to receive the extension.

Here is how that works in practice. A candidate who passed on April 20, 2026 originally held a credential due to expire in October 2026. Under the extension, it now runs to April 20, 2027. A candidate who passes on October 5, 2026 holds a credential valid until October 5, 2027, and the same pattern applies to everyone who certifies after that. The program launched in March 2026, so the earliest holders will reach their renewal date in early 2027.

To find your date, look at your badge. Anthropic issues the credential as a digital badge through Credly, and the badge records when it was issued.

What renewal involves

Section 15 (CCAR-F) describes the process in two steps. First, you review what has changed since you certified. Second, you complete a free, non-proctored assessment on the Anthropic Partner Academy. There is no fee for renewing on time.

This is a much lighter process than the original exam. The exam itself is proctored and closed book, with a 120-minute time limit. The renewal assessment is not proctored at all. Anthropic is not asking you to prove everything again. It is asking you to show you have kept up.

Two rules still apply. Section 15 (CCAR-F) notes that holders remain bound by the rules of conduct in Section 13, and the renewal assessment is your own work in the same way the exam was. The Anthropic Certification Exam Policy also lists using unauthorized published exam questions or answers as misconduct, so the same reasoning that rules out exam dumps for the exam applies here.

What has not been published yet

Anthropic has not yet published every detail of the renewal process. At the time of writing, the official documents do not say:

how early before your expiry date the renewal assessment becomes available
how long the assessment is or what format it takes
how holders will be notified that renewal is due

The certification FAQ says full details will be shared before the first certifications come up for renewal. Until then, treat any specific claim about the renewal window or the assessment format with caution, including claims from third-party sites. This article will be updated when Anthropic publishes more.

The deadline, and what happens if you miss it

This is the one part of renewal to take seriously. The Anthropic Certification Exam Policy (section 6) says you must renew before your certification term ends. Once the credential has expired, you can no longer renew it. You have to earn it again.

Section 15 (CCAR-F) spells out what that means: a lapsed credential requires retaking the full exam at the full fee. The exam fee is currently $125, according to Anthropic's certification FAQ, and the full exam comes with everything that applies to a first attempt, including a proctored session and the retake policy in Section 12 (CCAR-F) if the attempt does not go well.

In other words, renewing on time costs nothing, and missing the date costs a full exam. There is no published grace period, so plan to renew well before the last day.

When Anthropic may ask for more

There is one situation where on-time renewal may not be enough. Section 15 (CCAR-F) says that if exam content changes significantly, Anthropic may require holders to retake the full exam to recertify rather than complete the renewal assessment. The Certification Terms and Conditions (section 2) add that Anthropic may require recertification before your term expires if there are material updates to the exams.

Neither has happened so far. It is still worth knowing, because it means the best way to prepare for renewal is to stay current with Claude throughout the year rather than cramming in the final month.

Letting your employer know

Your renewal date matters to your employer as well as to you. Certification is open to people at Claude Partner Network organizations, and Anthropic's certification FAQ says each certification counts toward the firm's standing in the network. The Partner Portal shows each organization its total number of certifications, updated weekly. Under the Certification Terms and Conditions (section 6), Anthropic may also share your certification status with your employer, including whether it is active or expired.

So a quick message to your manager or partner lead a couple of months before your date is worth sending. Tell them when your credential comes up for renewal and that you plan to renew on time. It shows you are on top of it, it lets them plan around their certification count, and it is a natural moment to ask for a little time to review what has changed since you certified. If your organization tracks certifications centrally, it may already have a renewal process you can follow.

Keeping your resume and LinkedIn accurate

The Certification Terms and Conditions (section 2) also cover how you describe your credential. After it expires, you may not present yourself as currently certified. If you list the certification, you need to show its certification period clearly.

In practice, that means adding the issue date and expiry date wherever you list it. LinkedIn's Licenses and Certifications section has fields for both, and a Credly badge displays its own dates. If you are listing the credential on your resume and LinkedIn for the first time, include both dates from the start. Renewing on time means the dates move forward each year.

Five steps to keep your credential active

Write down your earned date. Check your Credly badge and note the date in your calendar.
Set a reminder at month 10. That leaves two months to complete the renewal assessment and deal with anything unexpected. It is also a good time to let your employer know your date.
Add a personal email to your Credly profile. Anthropic's certification FAQ recommends this so you keep access to your badge if you change jobs or email addresses.
Stay current as you go. The renewal review covers what has changed since you certified, so following Claude's releases through the year makes that step short.
Watch for Anthropic's renewal details. The full process is due to be published before the first renewals fall due.

Quick answers

How long is the Claude Certified Architect credential valid?
Twelve months from the date it is awarded, according to Section 15 of the CCAR-F exam guide. Certifications earned before June 30, 2026 under the earlier 6-month validity were extended automatically to 12 months from their original date.

How much does it cost to renew?
Nothing, if you renew on time. Renewal is a free, non-proctored assessment on the Anthropic Partner Academy. If the credential lapses, you must retake the full exam at the full fee.

Can I renew after my certification expires?
No. Anthropic's Certification Exam Policy says renewal must happen before the certification term ends. After that, you need to pass the exam again.

When will Anthropic publish the renewal details?
Anthropic's certification FAQ says full details will be shared before the first certifications come up for renewal.

Originally published at claudecertifiedarchitects.com, an independent exam-prep site. Not affiliated with or endorsed by Anthropic.

How to List the CCAR-F (CCA-F) on a Resume and LinkedIn

Josh — Mon, 21 Sep 2026 11:56:05 +0000

You passed. Here is the short version of how to show it:

Claude Certified Architect – Foundations (CCAR-F), Anthropic. Earned September 2026, expires September 2027.

That line goes in a Certifications section on your resume and in Licenses & certifications on LinkedIn, with your own month in place of September. The rest of this article explains each part of it, how to make the credential do real work on your profile, and how to handle the expiry date the credential carries.

The exact wording

The exam guide names the credential "Claude Certified Architect – Foundations" and gives its exam code as CCAR-F (Section 3). You will also see it written CCA-F, and there is more on why the exam has two codes if a recruiter asks.

Anthropic itself writes the name two ways: the exam guide uses a dash, and Anthropic's announcement of its role-based certifications uses a colon, "Claude Certified Architect: Foundations". Either is recognizable. The rule that settles it is simple: match your badge. Anthropic's announcement says that people who pass receive a digital badge through Credly by Pearson, and its Academy FAQ says the credential is issued through Credly. Whatever your badge shows is the version to copy, character for character, everywhere you list it.

On a resume

A Certifications section is the standard home. Put the full name first, then the issuer, then the dates:

Claude Certified Architect – Foundations (CCAR-F) | Anthropic | Sep 2026 to Sep 2027

Whether it also belongs in your summary line at the top is a judgment call, and here is the test we would use. Section 2 of the guide describes the candidate the exam is built for: "a solution architect who designs and implements production applications with Claude". If that sentence describes work you actually do, the credential earns a place in your summary, because it confirms the claim your summary is already making. If you are earlier in your career, keep it in Certifications and let your experience section carry the story. That is our advice, not the guide's, and it rests on one idea: a credential is strongest when it confirms something the rest of the page already shows.

It also helps to know who the certification is built for, since the same description tells you which of your experiences to put next to it.

On LinkedIn

Add it under Licenses & certifications. The form asks for a name, an issuing organization, dates, and optionally a credential ID and URL.

Name: exactly as your Credly badge shows it.
Issuing organization: Anthropic.
Issue date: the month you were awarded the credential.
Expiration date: twelve months later (see the next section).
Credential ID and URL: fill these in only from your Credly badge. Neither Anthropic's announcement nor its Academy FAQ describes a separate ID or verification link for the exam credential, so copy whatever the badge provides and nothing else.

Your headline and About section follow the same test as a resume summary. If you design and build production systems with Claude, "Claude Certified Architect – Foundations" in the headline tells a reader what kind of work you do before they open your profile. If you are moving into that work, put the credential in your About section next to what you are building.

The expiry date

Section 15 is clear that this credential does not last forever: it "is valid for 12 months from the date it is awarded." The guide gives the reason directly: "Because the underlying technology evolves rapidly, the credential is time-limited so that holders maintain current knowledge."

List the expiry date. It is accurate, and it tells a reader the credential is current, which is the point of holding one. (There is more on how long the credential lasts in our FAQ.)

Renewal is straightforward. The guide says: "To renew on time, you review what has changed since you certified and complete a free, non-proctored assessment on the Anthropic Partner Academy. There is no fee for on-time renewal." When you renew, update the expiry date on your resume and on LinkedIn. It is also worth knowing how renewal compares with the Associate certification if you plan to hold more than one.

If a credential lapses, the guide says "you must retake the full exam at the full fee to regain certified status." On your profile, a lapsed credential keeps its real dates, with the end date in the past. Never leave it open-ended. An honest date range still shows the work you did to earn it.

Turning the domains into resume lines

The credential tells a reader you were examined on something. Your experience section tells them what you did with it. The guide's own structure is a good map for connecting the two: Section 4 lists five domains, and Section 2 lists the hands-on experience the exam assumes. You can see the five domains and their weights laid out on our exam guide page.

The patterns below are for describing your own work. Fill the brackets with what you actually built and what actually happened. Do not copy them as claims.

Agentic Architecture & Orchestration (27%): "Designed [a multi-agent or agentic workflow] using the Claude Agent SDK to [what it did], [a result you can point to]."
Claude Code Configuration & Workflows (20%): "Configured Claude Code for [team or project] with [CLAUDE.md files, Agent Skills, MCP integrations], [what changed for the team]."
Prompt Engineering & Structured Output (20%): "Built [an extraction or generation pipeline] producing structured output against [a JSON schema or format], [a reliability result you measured]."
Tool Design & MCP Integration (18%): "Designed MCP tools and resources connecting Claude to [backend system], [what it enabled]."
Context Management & Reliability (15%): "Handled [long documents, long conversations or agent handoffs] with [the approach you used], [what it fixed or prevented]."

One line per domain you have genuinely worked in is plenty. Two strong lines are worth more than five vague ones.

If you are still preparing

You can mention an exam you have not passed yet, as long as the wording is exact. If your exam is booked, "Claude Certified Architect – Foundations (CCAR-F): exam scheduled, [month]" is accurate. If it is not booked yet, leave it off and let your project work speak for itself. Never write "certified" before you are, and never use the badge name for a credential you do not hold.

If you are working toward the exam now, a good place to start is a free ten-question diagnostic that scores you by domain. When you are ready to book, the registration steps through the Partner Academy and Pearson VUE are laid out step by step.

In interviews

A credential on a resume invites the question "what was on it?" Here is how to answer well.

Talk about how the exam is designed, because that says something about what you can do. Section 1 says candidates must demonstrate "practical judgment about architecture, configuration, and tradeoffs in production deployments." Section 5 explains that the exam presents four scenarios, picked at random from six, each one "a realistic production context that frames a set of questions." So you can say, truthfully, that you were tested on making design decisions in production scenarios, then move straight to a decision you made in your own work.

Do not describe specific questions. Section 14 is the confidentiality agreement every candidate accepts, and Section 13 lists "revocation of your credential" among the consequences for disclosing exam content. The design of the exam is public; its content is not. The best interview answer uses the first and moves on to your own work.

What this article does not claim

The CCAR-F exam guide says nothing about salaries, hiring rates, or whether employers require or prefer the credential, and neither does this article. What the credential gives you is a precise statement that you were examined on production Claude architecture, with a Credly badge to show it and a date to show it is current. Listed exactly and paired with real work, that statement does its job.

FAQ

What is the exact name to put on a resume?

The exam guide calls it "Claude Certified Architect – Foundations", exam code CCAR-F. Anthropic also writes it with a colon. Copy the name exactly as it appears on your Credly badge.

Who is the issuing organization on LinkedIn?

Anthropic. Anthropic says people who pass receive a digital badge through Credly by Pearson, and that the credential is issued through Credly, so take any credential ID or URL from your Credly badge.

Should I list an expiration date?

Yes. Section 15 of the guide says the credential is valid for 12 months from the date it is awarded. Update the date when you renew.

Can I list the exam before I pass?

Only as what it is. "Exam scheduled" with a month is accurate if the exam is booked. Never write "certified" before you are.

Originally published at claudecertifiedarchitects.com. Section numbers refer to the CCAR-F exam guide, version 1.0 (July 2026).

CCAR-F (CCA-F) exam dumps: do they exist, and would they help?

Josh — Thu, 17 Sep 2026 05:41:52 +0000

If you searched for CCAR-F dumps, here is the short answer. Everyone who has taken the Claude Certified Architect Foundations exam (CCAR-F, also written CCA-F) had to accept a confidentiality agreement before the first question appeared, promising not to disclose, reproduce or distribute any part of it. On our reading, that means a genuine dump could only exist because somebody broke that agreement. This article does not guess whether any real one exists, and it does not point to anywhere that claims to sell one.

The more useful answer is that even a genuine dump is a poor bet for this particular exam, for reasons that follow directly from how the published exam guide describes it. The rest of this article walks through those reasons, then covers what prepares you instead, most of it free. (If you are unsure which code is the official one, the guide's details table lists the exam code as CCAR-F.)

What a dump would have to contain

Section 3 of the CCAR-F guide sets out the shape of the exam: 60 items, a 120-minute time limit, and an exam structure described as "4 scenarios drawn from a bank of 6".

Section 5 explains what a scenario is: "Each scenario presents a realistic production context that frames a set of questions. During the exam, 4 scenarios are presented and picked at random from the full set of the 6 scenarios below."

Two things follow from that. First, you cannot know in advance which four scenarios you will get. A set of questions remembered from someone else's exam reflects the four they drew, not the four you will draw. Second, the questions are not free-standing facts. Each one sits inside a production context, and the context is part of the question.

Section 10 adds one more detail: "Scaled scoring models help equate scores across multiple exam forms that might have slightly different difficulty levels." So the guide says more than one form exists. It does not say how many, how they differ, or what changes between them, and this article will not fill that gap with a guess.

None of this makes the scenarios secret. You can read the six scenarios the guide publishes, and knowing them well is legitimate preparation. What nobody can tell you is which four you will face.

What the questions actually test

Section 1 of the guide is direct about the level: "Candidates must demonstrate not only conceptual knowledge but practical judgment about architecture, configuration, and tradeoffs in production deployments."

The format supports that. Section 3 lists the item format as "Multiple-choice and multiple-response items; each item states how many responses to select". In a multiple-response item, you pick that stated number of correct options from several plausible ones, which is where a remembered letter is least help. There is more on how each item states how many responses to select and what that means for how you read a question.

This is why the exam is hard in the way engineering judgment is hard. The right option depends on the constraints the scenario sets: what the system must guarantee, what it can afford, what has already failed. Change those constraints and a different option becomes correct. An answer key with no reasoning teaches you a letter for one set of constraints. It does not teach you to notice when the constraints have moved, and memorizing a rule can produce the wrong answer when they have.

The guide also shows you what real items look like. Section 9 says its sample questions "illustrate the format and difficulty level of the exam" and that they "are drawn from the practice test". So the guide's own samples come from a practice test, and the guide publishes them with explanations. Read those in the guide itself.

The agreement, and what the rules attach consequences to

Section 14 is short enough to quote in full:

Before the exam begins you must accept a confidentiality and non-disclosure agreement. By accepting, you agree that all exam content, including questions, answer options, and scenarios, is the confidential and proprietary property of Anthropic, and that you will not disclose, reproduce, or distribute any portion of it. If you do not accept the agreement, the exam session ends and no refund is issued.

Section 13 sets the rules for the session itself. Among them, candidates must "Not capture, copy, photograph, or reproduce any exam content in any form". Its consequences clause reads:

Cheating, attempting to access prohibited resources, or disclosing exam content may result in invalidation of your result, revocation of your credential, and a ban from future exams.

Section 15 adds that the obligation does not end at the exam room door: "Holders remain subject to the rules of conduct described in Section 13."

It is worth being precise about what these sections say. They attach consequences to cheating, to attempting to access prohibited resources, and to disclosing exam content. They say nothing about studying from leaked material, and this article does not claim they do. What they do make clear is that anyone who shares exam content is putting their own result and credential at risk to do it.

Twelve months, then a renewal

Section 15 opens: "The Claude Certified Architect – Foundations credential is valid for 12 months from the date it is awarded. Because the underlying technology evolves rapidly, the credential is time-limited so that holders maintain current knowledge."

Renewal is not a formality either. The guide says: "To renew on time, you review what has changed since you certified and complete a free, non-proctored assessment on the Anthropic Partner Academy." And: "If exam content changes significantly, Anthropic may require holders to retake the full exam to recertify rather than complete the renewal assessment."

The conclusion here is ours, not the guide's. The credential is built around keeping up with a technology that changes, and renewal means reviewing what has changed. Understanding can be updated. A list of remembered answers cannot: there is nothing in it to review, only something to replace.

What a failed attempt costs

If you were looking for a shortcut because time or money is tight, this is the part worth weighing.

Section 3 lists the exam fee as $125 USD, and Section 11 notes that the fee shown at checkout reflects any discount for your partner tier. Section 12 sets the retake policy: after a failed attempt you wait 14 days, then 30 days after a second, then 90 days after a third, and you may take the exam up to four times in a rolling twelve-month period. The same section is explicit that the fee applies to each attempt.

Two more rules can cost the fee without a result. Section 11 says changes made within 24 hours of your appointment forfeit it, and Section 12 says a no-show or late arrival forfeits it too.

The pass mark is 720 on a scale of 100 to 1,000, and it is a scaled score: Section 10 says the per-domain percentages on your score report are not used to decide a pass or fail. Walking in with answers that belong to a different draw of scenarios is a costly way to find out where you stand.

What works instead, free first

The guide itself is the best free starting point.

Section 7, "How to Prepare", lists concrete things to build: a complete agentic loop with the Claude Agent SDK, a real project configured in Claude Code, MCP tools with clearly differentiated descriptions and structured errors, a structured data extraction pipeline, and practice with prompt engineering, context management and escalation patterns. Section 8 turns several of these into step-by-step hands-on exercises. Section 9 gives you the sample questions with explanations. All three are in the guide, free, and written by the people who wrote the exam.

After that, test yourself against questions in the same format:

Start with a free ten-question diagnostic that needs no account. It scores you by domain, so you know where to spend your time.
Work through ten free questions with detailed explanations, and read the explanations for the options you got right as well as the ones you missed.

The point of any practice question is the reasoning behind it, not its letter. That is what carries over to the four scenarios you actually draw.

The short version

A genuine CCAR-F dump could only come from someone breaking the agreement every candidate accepts. Even then, it would reflect someone else's four scenarios out of six, it would teach answers rather than the judgment the exam is built to test, and it would age as the credential is designed to. The guide's own preparation list, exercises and sample questions are free, and practice that explains its reasoning is the preparation that transfers.

FAQ

Are there real CCAR-F exam dumps?

The CCAR-F exam guide requires every candidate to accept a confidentiality and non-disclosure agreement before the exam begins, covering all questions, answer options and scenarios. Any genuine dump would therefore come from a breach of that agreement. This article does not assess or point to any source that claims to offer one.

Can using an exam dump get me banned?

Section 13 of the CCAR-F guide says cheating, attempting to access prohibited resources, or disclosing exam content may result in invalidation of your result, revocation of your credential and a ban from future exams. It does not mention studying from leaked material. Anyone who shares exam content does put their own result and credential at risk.

Would a dump help me pass CCAR-F?

The guide describes 60 items built around 4 scenarios picked at random from a bank of 6, testing practical judgment about architecture, configuration and tradeoffs. A remembered answer set reflects someone else's draw and teaches answers rather than reasoning. Practice questions that explain why each option is right or wrong are a better use of limited time.

What is the best free preparation for CCAR-F?

Start with the official exam guide: Section 7 lists what to build, Section 8 gives hands-on exercises, and Section 9 has sample questions with explanations. Then a free ten-question diagnostic shows which domains need the most work.

Originally published at claudecertifiedarchitects.com. Section numbers refer to the CCAR-F exam guide, version 1.0 (July 2026).

Guarantee or accuracy: a CCAR-F question type

Josh — Thu, 10 Sep 2026 10:04:07 +0000

There is a family of questions in this exam's published objectives that splits candidates two ways, and the advice most preparation material gives you, including ours, only covers one of them.

The scenario gives you a system that must never do something. A classifier that can only return categories from a fixed list. An agent that must not run destructive SQL. A step that must not start before an earlier one has completed. Then it asks which option satisfies the requirement.

One option adds a clear, well written instruction. Another adds a hook, a gate, a scope restriction or a validation step.

The standard advice is that infrastructure enforces and prompts only guide, so pick the infrastructure. Our own anti-patterns post says exactly that, and it is right about half the time.

Where these questions actually sit

Most people file this under Prompt Engineering and Structured Output. That is where the schema discussion belongs, and it is where the vocabulary of validation gets taught.

In our own bank, the questions where a code-level answer is keyed over a prompt-level distractor cluster in Agentic Architecture and Orchestration: twelve items there against five in Prompt Engineering. Hooks, prerequisite gates, subagent isolation, tool scoping.

But the reverse runs the other way. Of the items where the prompt-level answer is correct and the code-level option is marked wrong, two thirds are in Prompt Engineering.

So if you revise this topic by reading about structured output, you will meet the cases where wording is right and miss most of the cases where it is not. And if you revise it by memorising "always enforce in code", you will do the opposite.

The guide's own phrasing is conditional

This is the part worth taking from the published guide directly.

Each time the guide sets a deterministic mechanism against a prompt instruction, the condition sits beside it. Hooks and gates appear "when deterministic compliance is required" and "when business rules require guaranteed compliance". Even the strongest statement about structured output, that it is the most reliable approach for guaranteed schema-compliant output, carries "guaranteed" inside it.

The guide never says enforcement is generally better. It says it is what you reach for when a guarantee is what the requirement demands.

Beside those, the same guide names prompt-level answers elsewhere. Normalisation rules belong in the prompt alongside a schema. Few-shot examples are named as the most effective technique for format consistency. Tool descriptions are named as the primary mechanism for tool selection, not a routing layer.

The test that works

Does the requirement need a guarantee, or does it need accuracy?

If something must never happen or must always hold, and a violation is a business or safety failure rather than a quality one, the requirement needs enforcement outside the model.

If something needs to be done well, consistently, or in a particular format, that is a prompting problem, and adding infrastructure is the wrong answer.

The reliable way to tell them apart is not the wording of the requirement. It is asking whether the consequence lands outside the conversation. Downstream code branches on the category. A deletion touches production. A step commits something irreversible. When the failure escapes the conversation and lands somewhere else, you need a guarantee.

When it does not, when the cost of a bad output is that the output is bad, you need accuracy.

Why the obvious shortcut fails

The tempting version of this test is to scan the stem for "never", "always" or "must".

That does not work, and it is worth knowing why before you rely on it. In our bank, guarantee words appear in at most half the items where a code-level answer is correct. The rest state the requirement without them. Meanwhile at least one item where the prompt-level answer is correct contains "always" inside a quoted system prompt line, which is precisely the trap: the word is in the scenario because someone wrote it into an instruction, and the instruction is the thing being examined.

Read the consequence, not the adjectives.

Three shapes worth recognising in the wrong options

From hand-classifying the distractors in our own items in this family:

Prompt wording offered as the guarantee. The most common by some distance. An instruction that names the constraint clearly and emphatically, sitting where a mechanism should be.

A real mechanism at the wrong scope. The option names something that genuinely enforces things, applied where it does not cover the failure. A hook on an event that fires after the damage. A tool withdrawn from the subagent that actually needs it. A forced tool choice that cannot sequence a second call.

A false claim about how a real mechanism behaves. Harder to spot, because the mechanism is right and the described behaviour is not. Hooks that retry. Hooks configured somewhere they do not live. A strict schema that fills missing fields from the source document.

There is also a smaller group worth naming separately, because it catches experienced people: temperature zero, or a change of model, offered as a substitute for a guarantee. Neither converts a probability into a certainty. Temperature zero is genuinely the right answer to some consistency questions, which is what makes it effective as a distractor everywhere else.

How to use this while revising

Take questions you have already answered in this family and, before looking at the options, write down where the consequence of a failure lands. Inside the conversation, or outside it.

If you can classify that correctly, the right option usually becomes obvious. If you cannot, the wrong answer will keep looking reasonable no matter how many times you review it.

Then check which direction your errors run. Reaching for infrastructure on an accuracy question and reaching for wording on a guarantee question are different mistakes with different fixes. The first means you have over-corrected, probably from advice like ours. The second means you have not yet internalised that an instruction is a request.

A worked example of this family, with the full explanation, is in our free questions post.

The one sentence version

An instruction changes what the model is likely to do. A hook, a gate or a validation step changes what the system is able to do. Read where the failure lands, decide which one the requirement needs, and the option that mixes them up will stand out.

For the structured output side of this, including where a schema stops helping, see the prompt engineering and structured output guide. For the orchestration patterns these questions sit inside, the agentic architecture guide covers the wider domain.

Zero Is the Worst Return Value

Josh — Mon, 07 Sep 2026 08:00:18 +0000

I once wrote a working capability out of a system's study material because a search returned nothing.

The question was whether a particular hook could rewrite a tool's output before the model saw it. I searched the codebase and the vendor documentation for the field name I remembered, updatedOutput. Zero hits, both places. I concluded the capability didn't exist, appended that conclusion as a "correction" in four places, and moved on.

The field is called updatedToolOutput. The capability exists, is documented, and does exactly what I'd wanted. My search was correct, my regex was correct, and the answer I took away was the opposite of the truth.

That's the shape this article is about. A search that finds nothing and a search that ran wrong return the same thing. Zero is a legitimate answer to a well-formed question, which means there is no signal in it — a true negative and a broken query are byte-identical at the call site.

I started keeping a list the first week this cost me something. It had six entries then and has fifteen now. What follows is the part of it I could reproduce on the machine I'm writing this on, each command quoted as it behaved here, the mechanism behind each, and the discipline I now use instead of trusting a zero. It ends with the one that happened while this piece was being fact-checked.

The shell cases

**
These cost the most, because the shell tells you nothing went wrong. Everything below is Git Bash on Windows: bash 5.2.37 (MSYS), git 2.53.0.windows.2, GNU grep 3.0, findutils 4.10.0, curl 8.18.0, Node 24.14.1. Your versions will differ, and the whole point of the piece is that you should check rather than trust mine.

Two I've written up before, so one sentence each. Under MSYS, any argument token that starts with / is rewritten to a Windows path before a native executable sees it, so git grep 'href="/blog/' actually searches for href="C:/Program Files/Git/blog/, prints nothing and exits 1 — exactly what a real no-match does, so a converted pattern and a true negative are indistinguishable by exit code as well as by output, and MSYS_NO_PATHCONV=1 is the fix (hold that thought). And xargs -0 LC_ALL=C grep tries to execute a program called LC_ALL=C: on findutils 4.10.0 that is loud — stderr says xargs: LC_ALL=C: No such file or directory and the exit code is 127 — and it becomes a clean zero only when the pipeline continues past xargs or stderr is dropped, which is how it once reported zero across a repo holding 218 matches. Both are in the earlier piece.

git log -G with a Perl-style pattern. -G takes a POSIX extended regular expression. \d, \w and \s are not part of it, and neither is the basic-regex habit of escaping | and {}. Six patterns against one file in a repository where the right pattern lists 76 commits, each run as git log --oneline -G '' -- sitemap.xml | wc -l:

2026-\d\d 0 # \d is not ERE
2026-[0-9]{2} 0 # BRE interval, wrong flavour
ogImage|lastmod 0 # BRE alternation, wrong flavour (run over sitemap.xml and posts/)
2026-[0-9]{2} 76
2026-[[:digit:]]{2} 76
ogImage|lastmod 77 # ERE alternation (same two paths)
The fix I first reached for, --perl-regexp, does nothing: the manual says it governs the "limiting patterns" — --grep, --author — not -G, and git log --perl-regexp -G '2026-\d\d' still returns 0 here. --pickaxe-regex is for -S and refuses to combine with -G at all. Write the extended regex:

0 — \s and \d are not ERE

git log --oneline -G '"date":\s*"\d+' -- posts | wc -l

39

git log --oneline -G '"date":[[:space:]]*"[0-9]+' -- posts | wc -l

This one is nastier than it looks because the same \d works in grep -P two lines earlier in the same script, so you carry a mental model that has already been validated.

node --check as a verification step. It parses. It does not evaluate. A file with a temporal-dead-zone violation — a const referenced before its declaration is reached — parses cleanly and exits 0, then throws the moment it actually runs.

// tdz.js
const items = ["a", "b"];
items.forEach(x => LABELS.push(x));
const LABELS = [];
node --check tdz.js # exit 0
node -e "require('./tdz.js')" # ReferenceError: Cannot access 'LABELS' before initialization, exit 1
I used node --check as a gate on generated code for weeks. It catches a missing operand (const x = ; fails it, I checked). It catches nothing about whether the file works.

Line-ending counts. grep -c $'\r$' is the folk way to count CRLF lines. On GNU grep 3.0 under MSYS it returns 0 for a file a byte scan shows to have 1,585 CRLF endings and no bare LF — this grep strips the CR from each line before matching, so the pattern can never fire. It also returns 0 on a pure-LF file. Same output, opposite files. -U keeps the bytes:

grep -c $'\r$' index.html # 0 (file has 1,585 CRLF lines)
grep -U -c $'\r$' index.html # 1585 (-U: binary mode, CR preserved)
grep -U -c $'\r$' blog/index.html # 0 (pure LF — the negative control)
sed strips the CR too: sed -n 1p index.html | od -c ends in a bare \n on that same CRLF file, so a sed | od pipeline reports LF for everything.

Read the bytes directly, or use -U.

grep -P on this locale. With LANG unset, grep -P refuses every pattern, not just exotic ones:

grep -c -P 'html' index.html

grep: -P supports only unibyte and UTF-8 locales (stderr, exit 2, nothing on stdout)

LC_ALL=C.UTF-8 grep -c -P 'html' index.html # 8
Redirect stderr, or pipe the result into wc -l, and it is a clean zero.

od | grep -o '0d 0a'. A tempting byte-level check for CRLF: dump hex, count the pairs. od emits sixteen bytes per output line, so any 0d 0a pair that straddles a line boundary never matches. On the same 1,585-line file:

od -An -tx1 index.html | grep -o '0d 0a' | wc -l # 1487
od -An -tx1 -w1 index.html | tr -d ' ' | tr '\n' ' ' | grep -o '0d 0a' | wc -l # 1585

Not a zero this time — an undercount of 98, which is worse in one way: it looks like a measurement.

grep -c '\r'. In a basic regular expression \r is the letter r. On a pure-LF, 401-line file it returned 317: every line containing an r. This is the saturated failure — the detector that fires on everything — and it is why the discipline below has a negative control as well as a positive one.

git show HEAD:file as a baseline. Under core.autocrlf=true the blob is stored LF and the working tree is CRLF. git show HEAD:index.html | wc -c gives 135376; wc -c < index.html gives 136961. The delta is 1,585 — exactly the line count. A byte comparison against the blob therefore reports every CRLF file as changed, and a "14-byte difference" on a block with fourteen newlines is not a difference at all. Compare LF-normalised content.

The fix that caused the next one

**
This is the best case on the list, and my first draft had it wrong.

The git grep fix above is MSYS_NO_PATHCONV=1: stop the shell translating Unix-looking arguments before they reach a native executable. I exported it for every session that grepped HTML or JSON. Some weeks later a search-engine submission silently never ran, and it took a while to connect the two.

Path conversion is also what turns /dev/null into nul for native programs. With the variable set, curl.exe receives the literal string /dev/null, cannot open it as a Windows path, and exits 23 — write error — after a complete, successful fetch. -s hides the message. -w prints the 200. And && short-circuits.

MSYS_NO_PATHCONV=1 curl -s -o /dev/null -w 'HTTP %{http_code}\n' https://www.claudecertifiedarchitects.com/sitemap.xml && echo "NEXT COMMAND RAN"

HTTP 200

(nothing else — $? is 23)

MSYS_NO_PATHCONV=1 curl -sS -o /dev/null https://www.claudecertifiedarchitects.com/sitemap.xml

curl: (23) client returned ERROR on write of 8268 bytes

curl -s -o /dev/null -w 'HTTP %{http_code}\n' https://www.claudecertifiedarchitects.com/sitemap.xml && echo "NEXT COMMAND RAN"

HTTP 200

NEXT COMMAND RAN

Writing to NUL or to a real file works with the variable set; I ran both. So the fix for one false zero manufactured another, in a different tool, weeks later, with the visible output — an HTTP 200 — actively reassuring. A list of tools that lie is not a list of independent facts. The entries interact, and the fix column is where they do it.

The same shape in code

**
The shell cases are easier to spot once you know them. The ones that live in application code have cost me far more.

A lookup with a fallback. This one ran for eleven weeks in an email template.

const tip = own(STUDY_TIPS, domain) || STUDY_TIPS['Agentic Architecture'];
STUDY_TIPS was keyed on 'Claude Code Configuration'. The value stored against every affected record was 'Claude Code Configuration & Workflows' — the display label, not the key. The lookup missed, the || supplied a default, and every consumer downstream received a valid, well-formed, entirely wrong tip.

167 emails went out that way: 85 carrying a study tip from the wrong domain, 82 carrying a sample question from the wrong domain, each under a heading naming the domain the reader had actually asked about. Nobody complained. The content was correct advice about something, and no recipient had any way to know what they were supposed to have received.

|| on a lookup converts a miss into a value. If the key is expected to exist, the miss is a bug and needs to be loud:

const tip = own(STUDY_TIPS, domain);
if (!tip) throw new Error(no tip for domain: ${domain});

A wrapper that catches and returns []. The agentic version of the same thing — a subagent fails, the wrapper logs it and returns an empty array, and the orchestrator receives [] and treats it as a fact about the world — which I wrote up last week and won't repeat, beyond noting that it survives code review because the code looks defensive.

**A script that fabricates a readout. **The worst one I've written. An audit script was supposed to report stored state. It didn't merely always answer yes — it compared its input to itself and printed a plausible, well-formatted readout of state it had never read. Everything downstream consumed the readout as the check.

If you want to see how this reads as an exam problem rather than an essay, we write scenario questions on exactly this in the practice bank. It's independent preparation material. We're not affiliated with Anthropic, and we neither sell nor administer the exam.

The discipline

**
One rule, and it is not "be careful."

Never accept a zero you have not proved with a known-positive control.

Before you believe a search returned nothing, run the same detector against something you know it should find. If the control doesn't fire, the zero is meaningless and you have learned that instead — which is a result, and a cheap one.

the question: does git grep find the link?

git grep -c 'href="/blog/' -- blog/index.html # (nothing), exit 1

the control: the MSYS grep binary, same file, same pattern

grep -c 'href="/blog/' blog/index.html # 47

the question again, with the fix

MSYS_NO_PATHCONV=1 git grep -c 'href="/blog/' -- blog/index.html # blog/index.html:47

Two controls are better than one: a positive that must fire and a negative that must miss. The second catches detectors that match everything — grep -c '\r' above — which is the failure mode the first one can't see.

The second half of the rule matters just as much, and it's the one I'm still bad at.

State the property your detector tests, then check that the detector tests that property — not the instance that made you look. When I found the updatedOutput error, I fixed the four places that carried it. I did not ask what else I'd written from the same guessed name on the same day. Closing an instance feels like closing a class, and the difference surfaces weeks later, by accident, usually in production.

For the email lookup, the detector that would have caught it in June is, in outline, three lines: call the real render function once for each distinct value actually present in the datastore, and read the output.

for (const domain of await distinctStoredDomains()) {
console.log(domain, '→', buildEmail1({ weakestDomain: domain }).subject);
}
That check now exists.

Where this costs more than it's worth

**
Controls are not free, and I don't run them on everything.

If a zero is cheap to be wrong about — you're looking for a string you half-remember in a file you're about to read anyway — the control is ceremony. If a zero is loud when wrong — the build fails, the tests go red, a human sees the empty page — the environment is already your control.

The cases worth the discipline are the ones where a wrong zero is quiet and durable: an audit result written into documentation, a class-closure claim, an enum lookup with a fallback, anything an autonomous process consumes without a human between the query and the conclusion.

There's an inverse failure worth mentioning too, since it cost me an hour last week. I compared two spreadsheet files cell by cell using a library's style objects, and every cell came back as different — including the empty ones — because those objects don't compare equal across two workbook instances. A detector that fires on everything is as useless as one that fires on nothing, and the negative control is what catches it.

Why this got worse, and what happened while this was being checked

**
All of the above predates LLM agents. What changed is who reads the zero.

A human who gets an empty result brings context: they know roughly how many results to expect, they remember that this search worked yesterday, and they have the option of asking someone. A model has your string and nothing else. Hand it [] and it will report, fluently and confidently, that nothing matched — and then act on that.

It happened during the fact-check for this article. To confirm the opening example, the hooks documentation was fetched through a tool that hands the page to a small model and asks it a question. Asked how many times updatedToolOutput appears, it answered: zero. It added, helpfully, that the page does not describe the hook modifying output. A curl of the same URL and a grep of the bytes: seven occurrences, including the table row that defines the field, with the control string PostToolUse at 58. The summariser had read part of the page and reported its absence as the page's. The false zero at the top of this piece was reproduced, by an agent, inside the session checking whether the piece was true, on the exact field name the piece is about.

So in an agentic system, "nothing found" and "the search did not run" have to be told apart in the value that comes back — not in a log, not in an exit code the model never sees, and not by a reader who was not there.

{ "results": [], "status": "ok" }
{ "results": [], "status": "error", "error": "upstream_timeout", "retryable": true }

Two different facts about the world. If your tool returns the first for both, every consumer downstream will eventually treat the second as the first, and the one reading it hardest is the one least equipped to notice.