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.
Top comments (0)